Cleanup: Use `#[rust_intrinsic]` and nix `rust-intrinsic` et. al

[Centril]

Per @eddyb's suggestion (rust-lang/reference#652 (comment)):

Not sure these should be documented, we've been meaning to remove all 3 for years...
cc @oli-obk at least for intrinsics we could maybe have an intermediary stage where we do #[rustc_intrinsic] extern "Rust" {...} instead of extern "rust-intrinsic" {...}?

I would maybe call them "pseudo-ABIs", in that they use the ABI string to indicate something special not purporting to the ABI, but are otherwise the "Rust" ABI.

cc @oli-obk, @nagisa, and @nikomatsakis

[eddyb]

Ideally these would be regular declarations (empty or self-calling, if we want to get clever about it), marked with some attribute (like lang items), without extern { ... } blocks at all.

But we've been waiting on that for years, so maybe splitting it into steps will help.

[fstirlitz]

'Not purporting to the ABI' may be an overstatement. The mechanism by which a compiler realises function calls is usually called an ABI after all (or a 'calling convention'). For regular functions this means mangling the name and putting a call instruction into the caller's body; whereas for intrinsics it means looking up the intrinsic in a table built into the compiler and putting some operations associated with it into the caller's body (which may not be otherwise expressible in surface syntax). I don't see what the problem is in calling both mechanisms 'ABIs'.

(And yes, that means inlining is an alternative calling convention as well. The way inlining is usually implemented in programming languages is just a matter of convenience; if instead of an attribute like #[inline], we had extern "inline" and no ability to form pointers to such functions, they would be much less expedient. But I doubt this is ever an issue with intrinsics.)

[eddyb]

@fstirlitz In all other situations, the "ABI string" (after the extern keyword) controls the transfer of values to and from (i.e. arguments and return value) the callee, but not how the function is found.

You mention mangling: mangling is not affected in any way by that "ABI string".
(extern "ABI" shouldn't have been the syntax, because AFAIK all it controls in C++ is mangling...)

[nagisa]

Agreed that we want intrinsics to be plain function definitions with an attribute.

#[rustc_intrinsic]
fn foobar(...) -> ... { 
    /* whatever works, body does not matter, empty `loop {}` or self-call all work */
}

It is perhaps a nice thing to make function pointers to intrinsics work; having intrinsics to be function definitions that self-call would make it "just work", solving a long-standing ICE with intrinsics.

[Centril]

Would be good to note what gains we expect from this other than making function pointers to intrinsics work (why is that important anyways?...).

[eddyb]

@Centril using FFI imports causes all sorts of undesireable behavior, such as all intrinsics being unsafe and their const fn-ness being a complete hack.

There are situations where we have a safe wrapper (or several, in the case of generic intrinsics, especially those generic over integer/float primitives) around an unsafe intrinsic, and we would prefer to mark that wrapper as the intrinsic.

Bonus: we can get rid of some post-monomorphization errors/ICEs if all of the intrinsics generic over a finite set of types (e.g. wrapping_add only works with iN and uN types) are instead defined non-generically and thus can be type-checked early.