Lint: enable empty_loop for no_std crates

[josephlr]

Right now, we have a style lint against the following code:

loop {}

Note that this is no longer undefined behavior (since rust-lang/rust#77972).

Currently, there is no way to have a no_std binary or library use the empty_loop lint.
Even adding #![deny(clippy::empty_loop)] to a crate does nothing. This is because #5086 (fixing #3746), made the lint essentially not exist for no_std crates.

Furthermore, even in no_std crates, using a "hot" deadloop is almost always not what you want (as it burns a bunch of CPU, and can cause crashes). Even on a no_std target, a user should either:

• Panic
• Call a platform-specific halt or pause intrinsic.

Note, core::sync::atomic::spin_loop_hint is not a good recommendation here, as pause isn't meant for dead-loops (it's designed for spin-locks). See rust-lang/rust#77924

In my opinion, we should:

• Reenable the empty_loop lint for no_std crates.
• Have a no_std specific help message.
• Disable this lint automatically in #[panic_handler]s
  • As an alternative, we could just disable this lint for no_std binaries (while keeping it on for no_std libraries).
  • The only uses of deadloops in the Rustonomicon are inside of #[panic_handler].

Our documentation for fixing this (on std and no_std) is part of #6162

CC (people involved with this change last time): @therealprof, @oli-obk, @eddyp, @Areredify, @phansch

[jonas-schievink]

core::sync::atomic::spin_loop_hint does not help here, it is a no-op on most embedded platforms and never causes side-effects

[josephlr]

core::sync::atomic::spin_loop_hint does not help here, it is a no-op on most embedded platforms and never causes side-effects

Agreed that this doesn't completely fix the issue. That hint currently only does something on:

• x86/x86_64 with SSE2
• ARM V6 and later (including Aarch64)

It would be nice if that hint did fix the issue. I'll see about filing an issue upstream to make it so core::sync::atomic::spin_loop_hint always does some sort of side-effect.

[jonas-schievink]

IMO we should just fix the LLVM bugs instead. spin_loop_hint is not meant to do anything here, it's not meant to have a side-effect, it's just a hint to schedule another hyperthread.

[josephlr]

@jonas-schievink I talk a bit in rust-lang/rust#77924 about why we might want spin_loop_hint to have a side-effect on all platforms. Basically, it makes our recommendations to users better, and makes the behavior more consistent across targets (as spin_loop_hint is a side-effect on x86 and (most) ARM targets).

[jonas-schievink]

It does not have side effects on any target. LLVM might treat it as such, but really it doesn't.

[josephlr]

It does not have side effects on any target. LLVM might treat it as such, but really it doesn't.

I guess I'm confused, for the current implementation on x86, the hint alls the pause instruction, which is a side-effect for the purposes of optimization and the like.