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]

@Skgland you opened #139455. Given that the issue here still has someone assigned, please always ask the assignee (@BLANKatGITHUB) in the issue first before assuming they have stopped working on this!

[BLANKatGITHUB]

Well , I was busy with college, that's quite a big pr though, does this pr finally close the issue? Or there are some more files left

[RalfJung]

No worries. I hope you're fine with someone else taking over. :)

That PR entirely removes "rust-intrinsics" from the compiler so it has to fix all the remaining files. The only thing that's left is the last (5th) checkbox in the issue description.

[BLANKatGITHUB]

No problem

[Skgland]

Besides looking for further cleanup potential, the following things are still to be done

• updating the nomicon Foreign Calling Conventions list in the https://github.com/rust-lang/nomicon repo.
• update the docs at

  rust/library/core/src/intrinsics/mod.rs

  Line 11 in 7dd57f0

  //! //FIXME(#132735) "old" style intrinsics support has been removed

  were I left a fixme as I didn't know how to reword this

And I noticed is that rust-analyser still checks for #[rustc_intrinsic_must_be_overridden] though this has been removed from the compiler as its been superseded by intrinsics functions without bodies.
So the check e.g. at

rust/src/tools/rust-analyzer/crates/hir-ty/src/mir/eval/shim.rs

Line 73 in 7dd57f0

|| attrs.by_key(&sym::rustc_intrinsic_must_be_overridden).exists(),

and symbol defined at

rust/src/tools/rust-analyzer/crates/intern/src/symbol/symbols.rs

Line 445 in 7dd57f0

rustc_intrinsic_must_be_overridden,

can also probably be removed.

[RalfJung]

RA has its own repo so this might be worth an issue there. They usually wait a bit before removing language features since they want to support using a current RA on older versions of Rust, which still use the old features (and even on stable Rust, those features are present in the standard library). So RA is out-of-scope for this issue.

Regarding the nomicon, could you make a PR?

I can reword that comment in intrinsics/mod.rs. EDIT: done as part of #139490.

[Skgland]

They usually wait a bit before removing language features since they want to support using a current RA on older versions of Rust, which still use the old features (and even on stable Rust, those features are present in the standard library).

Uh-oh, then 51b51b5 probably went too far as well and should maybe be reverted until rust-analyzer is ready to remove support for the "rust-intrinsic" ABI.

[Skgland]

Regarding the nomicon, could you make a PR?

Opened rust-lang/nomicon#485