compiler: Allow extern "interrupt" fn() -> !

[workingjubilee]

While reviewing #142633 I overlooked a few details because I was kind of excited.

Fixes #143072

[rustbot]

r? @BoxyUwU

rustbot has assigned @BoxyUwU.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

This PR modifies tests/auxiliary/minicore.rs.

cc @jieyouxu

[folkertdev]

Now that the rules get more complex, I think the error on the return type should probably move to rustc_hir_typeck. The current implementation cannot reason about type aliases, so

type Unit = ();

#[cfg(any(x64, i686))]
extern "x86-interrupt" fn x86_ret_unit() -> Unit {
    unsafe { hint::unreachable_unchecked() }
}

gives

error: invalid signature for `extern "x86-interrupt"` function
  --> /home/folkertdev/rust/rust/tests/ui/abi/interrupt-returns-never-or-unit.rs:86:45
   |
LL | extern "x86-interrupt" fn x86_ret_unit() -> Unit {
   |                                             ^^^^
   |
   = note: functions with the "x86-interrupt" ABI cannot have a return type
help: remove the return type
  --> /home/folkertdev/rust/rust/tests/ui/abi/interrupt-returns-never-or-unit.rs:86:45
   |
LL | extern "x86-interrupt" fn x86_ret_unit() -> Unit {
   |                                             ^^^^

error: aborting due to 1 previous error

The error message is also incorrect now: the function can have a return type (so long as it's black () or !)

[workingjubilee]

I mean if I really want to get it right it should probably be even deeper, so we can check the actual layout.

[workingjubilee]

I don't think I want to do that level of correctness before we decide we actually want these interrupt ABIs, though, and I, at least, am not sold on them.

[folkertdev]

Fair enough. Then the error message should at least be correct though right? (so, there can be a return type, just literally () and ! are allowed).

before we decide we actually want these interrupt ABIs, though, and I, at least, am not sold on them.

The x86 one gets a surprising (to me) amount of use https://github.com/search?q=extern+%22x86-interrupt%22&type=code. But in theory those could now use naked functions and compile on stable.

[workingjubilee]

@andrewoffenden what.

[workingjubilee]

Fair enough. Then the error message should at least be correct though right? (so, there can be a return type, just literally () and ! are allowed).

before we decide we actually want these interrupt ABIs, though, and I, at least, am not sold on them.

The x86 one gets a surprising (to me) amount of use https://github.com/search?q=extern+%22x86-interrupt%22&type=code. But in theory those could now use naked functions and compile on stable.

Yes, Phil Opp espoused using them, so they gained some popularity. But they should not be used by a real OS, because an OS cannot support any debugger APIs if it uses them.