Signature of bkpt() function

[therealprof]

I was just looking at ways to cheaply and clippy happy "terminate" an #[entry] function and was looking at the cortex_m::asm:bkpt() function noticing that it has a signature of pub fn bkpt(). My expectation would have been that this function has a signature of pub fn bkpt() -> ! instead which would qualify it as a terminating statement in #[entry].

Is there a reason for bkpt() not returning never?

[adamgreig]

After the breakpoint is triggered, the debugger can just continue and execution continues after the function, right?

[therealprof]

Or something completely different can happen because the debugger could completely rewrite the state, or the MCU could go into a Fault state because no debugger is attached. I thought that is exactly what the never type is representing?

[adamgreig]

But the code after the bkpt() call could be run (and quite often will be!), whereas I thought ! tells the compiler nothing after here will execute; I believe I've seen it generate trap instructions after a ! function to ensure just that (but haven't tested specifically...).

[therealprof]

I thought the never type was used to express "no value" or uncertainty of program flow and bpkt() would qualify.

Do you have any other idea how to produce a never value for #[entry] that does not produce overhead (like panic!()) or is frowned upon by clippy (like loop {})?

[therealprof]

This related issue just in: rust-embedded/cortex-m-rt#139

[adamgreig]

The never type ! as a function return type means "never returns" which isn't true of bkpt(). I usually do something like loop { cortex_m::asm::wfi() } or nop().

Re that c-m-rt issue, that's sort of correct behaviour as far as "It seems that all divergent functions (fn(..) -> !) are given the noreturn attribute" goes. Annoying that trashing LR screws with debugging of course...

[therealprof]

I'm still not convinced bpkt() doesn't count as a diverging function because it is not guaranteed that program flow will ever continue after it; it's totally up to the debugger (if connected) to decide whether and how to continue after that point.

However reading the book about the never type I actually found a good, cheap and clippy happy solution to my problem:

loop {
     continue;
}