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.

[Freax13]

I think there are valid use-cases for the "x86-interrupt" ABI even in a "real OS". Sometimes you don't need to look at the registers of the interrupted thread, and in that case, using "x86-interrupt" is completely fine and can even result in better code than a hand-written interrupt handler. For example, I use it for handling timer interrupts that happen while the kernel is executing in ring 0. That said, there are, of course, also use cases where this absolutely will not work: If you're going to write an int 0x80 handler, you'll very likely need to hand roll your own assembly.

[phil-opp]

Apart from convenience, my main motivation for using the x86-interrupt calling convention was that it generates better code than you can write manually for short interrupt handlers. It backups only the registers that are used by the handler implementation. With manual inline assembly, you have to always backup all caller-saved registers.

That being said, I also agree that the x86-interrupt calling convention is a burden to maintain. The LLVM implementation is not really used by many people, so it's not properly tested and breaks relatively often. It's also quite a complex calling convention because of how the x86 architecture is designed (e.g. for some exceptions, an additional error code is pushed to stack). So I would fully understand if we don't want to have this complexity inside rustc.

Thanks a lot for this PR by the way! I appreciate it that you try to avoid breakage, even though it's a nightly feature!

[phil-opp]

(Not directly related to this PR, but to discussion about whether we want to keep the x86-interrupt calling convention or not:

I think if we had support for LLVM's PreserveAll or PreserveMost calling conventions, we could use that instead of x86-interrupt (in combination with a naked wrapper function). This way, we could keep the complexity of the x86 interrupt stack frame out of rustc, bit still have the performance advantage of saving only the registers that will be overwritten.)

[workingjubilee]

We do support PreserveMost already as extern "rust-cold", but I don't know if it works the way you need it to, @phil-opp. We can add a full-on "rust-save" though.

I agree that we really do need that as a prerequisite to any alternatives. That way any assembly can be a minimal shim sufficient to do whatever operations are needed between the machine and the OS and then jump into the main handler, instead of saving everything in the assembly.