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, which supports giving a "fallback body" that will be used for backends that do not have the intrinsic implemented:

#[rustc_intrinsic]
#[rustc_intrinsic_must_be_overridden]
unsafe fn unreachable() -> ! { unreachable!() }

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

1. 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.
2. Port the uses of extern "rust-intrinsic" in src/tools/miri and tests/ui/simd to the new style. In fact, these can use the even newer style (which can't be used in library yet because of bootstraping):

#[rustc_intrinsic]
unsafe fn unreachable();

3. Remove support for extern "rust-intrinsic" blocks from the compiler -- in particular, remove this. AFAIK these are also the only extern blocks that support generics, so there might be more things that can be cleaned up here. (@compiler-errors or @oli-obk might know more about that.) 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.

[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]

The current status for this issue is that many but not all of the intrinsics in library have been ported to the new style.

@BLANKatGITHUB do you plan to continue this, porting the remaining intrinsics in library?

[BLANKatGITHUB]

Sorry I am currently busy with my exams, but I will get to it as soon I get the time

[RalfJung]

No worries. :) Focus on your exams first!

[RalfJung]

Note that uses outside library can use an even newer style now, but it will take 6 weeks before we can use that style in library/:

#[rustc_intrinsic]
unsafe fn unreachable();

rustc_intrinsic_must_be_overridden should not be used outside library.

[BLANKatGITHUB]

Thanks for understanding I will be free again around 20 January, I will contact you then for more information.

[vayunbiyani]

Thanks for understanding I will be free again around 20 January, I will contact you then for more information.

Hi @BLANKatGITHUB , I hope your exams went well! While you were away, I made some progress on the issue. Let me know if there's anything else I can assist you with regarding its resolution.

[BLANKatGITHUB]

@vayunbiyani thanks I saw you change quite a few files in one pr , I am not quite sure if every file in compiler and all the tests are ported , I hope you can provide more info on that as I was busy with exams currently I am working on /home/blanky/projects/opensource/rust/library/core/src/intrinsics/mod.rs .

[BLANKatGITHUB]

@RalfJung I don't see ./library/core/src/ffi/va_list.rs are they ported? and can you provide more info on new style we can't use it inside the library though, right?

[RalfJung]

What do you mean you don't see it? It's right there.

And yes the "even newer" style without a body cannot be used in the library. The issue documentation says that.

[vayunbiyani]

I am not quite sure if every file in compiler and all the tests are ported

@BLANKatGITHUB You’re correct, not every file has been updated. I’ve only ported some of the more obvious ones. I’m a bit uncertain about how to handle porting the test cases while adhering to best practices. What do you think about jumping on Zulip to figure this out?

[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