Add a macro for defining intrinsics with the Rust ABI

[tgross35]

Migrating intrinsics at this time seems to come with a lot of boilerplate in the form of attributes and empty bodies (see #127337 for an example). Add a macro that simplifies this, and makes the transition from extern "rust-intrinsic" intrinsics much cleaner, and then make use of it.

Cc #93145

r? @oli-obk

[tgross35]

There are a couple unfortunate things here:

• It doesn't seem to be possible to forward $foo:item fragment specifiers to $(tt:tt)* or exact tokens, and capturing optional specific keywords isn't great (more reason for [RFC] Named macro capture groups rfcs#3649 yay), so I can't figure out any way to allow mixing fn with const fn, const unsafe fn, etc in the same macro invocation. Maybe there is a better way to do this, I need to think on it for a bit.
• Something is weird with generics - for any function that has them, it complains about having the wrong count (e.g. expected 0 but got 1), even though the function appears to expand properly (just quickly checking via cargo expand). Any ideas here?
• I thought some of the goal with the migration is to allow e.g. clif or gcc to not override some intrinsics and just let them panic with unimplemented!. This seems contrary to what rustc_intrinsic_must_be_overridden sounds like - what is the exact intent here? Or does this just mean that it must be overridden only iff the compiler recognizes it as an intrinsic.

This isn't 100% complete, e.g. generics with ? don't yet match, and there might be something better for repetition mixing const/unsafe/default. Just wanted to get some feedback before getting too into it.

[tgross35]

I think these float intrinsics could probably just be safe if there are no preconditions, not as part of this PR though.

[tgross35]

The macro could probably also be tweaked to allow specifying the fallback body

[bors]

☔ The latest upstream changes (presumably #127865) made this pull request unmergeable. Please resolve the merge conflicts.

[oli-obk]

• and just let them panic with unimplemented!

the point was to have a meaningful body that emulates the behaviour with potentially more expensive operations.

[oli-obk]

I am not sure about this change.

I would prefer to just use item fragments and add the unreachable bodies and the must_be_overridden attribute to all intrinsics.

[tgross35]

If rustc_intrinsic and rustc_intrinsic_must_be_overridden almost always go together, could they maybe just be combined in the compiler such that one implies the other?

I am not sure about this change.

I would prefer to just use item fragments and add the unreachable bodies and the must_be_overridden attribute to all intrinsics.

As in, $( $fn_sig:item );+ that matches

foo();
bar();

?

Unfortunately macro parsing is pretty insistent that the ; is part of the item, and item can't be forwarded to token trees or exact tokens so it's not possible to extract it in a separate pattern.

I might be able to improve something here, just need to fight with the macro system a bit.

[oli-obk]

could they maybe just be combined in the compiler such that one implies the other?

the macro can just add the #[rustc_intrinsic] attribute and let the must_be_overridden be added at each site, together with { unreachable!() } instead of ;

[oli-obk]

r? libs I'm going on leave for 4 months

[workingjubilee]

Something in the direction of oli's review seems correct to me. Basically "please make the macro less clever".

[tgross35]

From the discussion on Zulip it sounds like we are heading toward what I was trying to achieve (unimplemented!() bodies with less boilerplate) by adjusting thing from the compiler side, so I don't think this is needed anymore.