Remove support for extern "rust-intrinsic" blocks

[RalfJung]

We currently have two ways to declare symbols that are invoked as intrinsics. The old way:

extern "rust-intrinsic" {
    fn unreachable() -> !;
}

The new way:

#[rustc_intrinsic]
unsafe fn unreachable() -> !;

The goal of this issue is to remove support for the old style, and consistently use the new style.

• Port the remaining extern "rust-intrinsic" intrinsics in library to the new style, updating them using the pattern described above. This can be a PR on its own. (Implemented in Change intrinsic declarations to new style #132907, changes old intrinsic declaration to new declaration #133106, ports last few library files to new intrinsic style #136005)
• Port the uses of extern "rust-intrinsic" in src/tools/miri and tests/ui/simd to the new style.
  This is implemented in Partial progress on #132735: Replace extern "rust-intrinsic" with #[rustc_intrinsic] across the codebase #135333, Port ui/simd tests to use the intrinsic macro #136022.
• Similarly port the extern "rust-intrinsic" in this file (note that this is a separate repository)
• Remove support for extern "rust-intrinsic" blocks from the compiler -- in particular, remove this. A bunch of tests will still need updating; you can grep for rust-intrinsic to find them all. They should all be ported to the new style, similar to the PR in step 2.
• Determine whether there is more cleanup that can be done. For instance, this can be removed. Maybe we can get rid of Abi::RustIntrinsic entirely?

[compiler-errors]

I do wonder if there's some way we could have body-less free function items when users write #[rustc_intrinsic_must_be_overridden]. Having all these dummy bodies like loop {} and unreachable {} seem kinda meh.

[RalfJung]

Yeah that would be nice. But I guess the parser will reject body-less fn items (with ";" instead of a block) pretty early?

[compiler-errors]

We actually reject them after expansion but before ast lowering.

We could perhaps intercept these bodyless functions during ast lowering and fill them with a dummy body like loop {} or something that diverges rather than having it be manually written on each function.

[compiler-errors]

Obviously only intercepting them if they're marked with rustc_intrinsic_must_be_overridden; if it's a regular function we'd issue the regular error for a bodyless free function, and if it's rustc_intrinsic we could tell the user that it needs to be marked with rustc_intrinsic_must_be_overridden.

[RalfJung]

That's way beyond my knowledge of those parts of the compiler. ;) So sure, sounds great. :D

Cc @petrochenkov

Obviously only intercepting them if they're marked with rustc_intrinsic_must_be_overridden

I was actually going to suggest that a #[rustc_intrinsic] not having a body should replace the rustc_intrinsic_must_be_overridden attribute.

[compiler-errors]

Oh, that works too.

[workingjubilee]

hmm do we have the notion of a builtin attribute macro...?

[compiler-errors]

@workingjubilee: Yes

[BLANKatGITHUB]

@rustbot claim

[BLANKatGITHUB]

Ok so basically I tried porting the first block of extern "rust-intrinsic" in library/core/src/intrinsics/mod.rs
and it gave the errors

`error[E0308]: intrinsic has wrong type
core/src/intrinsics/mod.rs:1277:26

pub fn prefetch_read_data<T>(data: *const T, locality: i32) {
                                                ^^^ expected unsafe fn, found safe fn
 
 note: expected signature `unsafe fn(_, _)`
            found signature `fn(_, _)` 

and

``
error: intrinsic safety mismatch between list of intrinsics within the compiler and core library intrinsics for intrinsic prefetch_write_data
core/src/intrinsics/mod.rs:1292:1

pub fn prefetch_write_data(data: *const T, locality: i32) {

``

[RalfJung]

Yes, the intrinsics need to be marked as unsafe fn. Sorry I forgot that when writing up the issue.

[RalfJung]

I do wonder if there's some way we could have body-less free function items when users write #[rustc_intrinsic_must_be_overridden]. Having all these dummy bodies like loop {} and unreachable {} seem kinda meh.

#135031 implements that.

[RalfJung]

tests/ui/simd has a bunch of test cases that need porting, I would suggest those be ported in a separate PR before we do the final big PR that removes support for this ABI from the compiler entirely.

[BLANKatGITHUB]

@vayunbiyani sure drop the link

[vayunbiyani]

@vayunbiyani sure drop the link

You can find me here as Vayun Biyani

[RalfJung]

Okay I think all the preparation is done now. :) There are fairly few such intrinsic blocks still left in the test suite; this is probably best done together with the actual removal.

[RalfJung]

@BLANKatGITHUB do you still plan to work on the next step for this issue, or should the issue assignment be released?

[BLANKatGITHUB]

@RalfJung sorry I was a little busy with college , I just used grep on rust repo and found several files which uses old declaration , I am not sure where to start many are in tests and some in compiler

[RalfJung]

As I said above, the next step is to actually remove the "rust-intrinsic" ABI string from the compiler. The remaining uses of the old style can be fixed as part of that PR, there's not so many of them. The PR description even points to the line of code you have to change for that.

[RalfJung]

Ah, never mind, there's one bit of cleanup that has to happen before -- there's two uses in library/stdarch/crates/core_arch/src/powerpc/altivec.rs that need to be updated via a separate PR in https://github.com/rust-lang/stdarch/.

[BLANKatGITHUB]

hey @RalfJung I was wondering as mentioned in issue the removal of this well I couldn't find this file on main branch am I supposed to change it on master branch or a particular one?

[RalfJung]

Seems like the file got renamed, grep for enum ExternAbi to find the current location.

Also, rust-lang/stdarch#1722 has to be synced to the rustc repo before you can proceed. I am hoping to include another PR in that sync before I will try a sync myself, though someone else might also do a sync in the mean time.

[RalfJung]

Blocked on #136831

[RalfJung]

@BLANKatGITHUB the stdarch update landed, so this is ready for the next step :)