Implement lint for black_boxing ZSTs

[xonx4l]

Implement a lint for black_boxing ZSTs as discussed in #137658

This PR implements a new lint which warns when std::hint::black_box is called with a Zero-Sized Type (ZST).

Why the lint is needed?
The compiler is currently "silently failing" to do what the user asked. A warning closes the gap between what the user thinks is happening and what is actually happening. Users reach for black_box specifically to prevent optimizations. When passed a ZST black_box effectively does nothing, yet the user receives no feedback, which creates confusion.

Changes:
Added #[rustc_diagnostic_item = "black_box"] to library/core/src/hint.rs.
Implemented a LateLintPass to detect calls to black_box where the argument's layout is a ZST.

Closes: #137658

[rustbot]

r? @eholk

rustbot has assigned @eholk.
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]

tgross35 is currently at their maximum review capacity.
They may take a while to respond.

[eholk]

It'd be cool if we were actually able to suggest a code fix here! But, I don't think that's necessary for this PR, just a nice future improvement.

[xonx4l]

Like? any example or idea?

[eholk]

guess the error message already says to coerce the object to a pointer, but we could also show a suggested code snippet. I think that would also let rust-analyzer make the change automatically. Given an error message like:

error: `black_box` on zero-sized callable `fn(u32, u32) -> u32 {add}` has no effect on call opacity
  --> $DIR/lint-black-box-zst-call.rs:10:18
   |
LL |     let add_bb = black_box(add);
   |                  ^^^^^^^^^^---^
   |                            |
   |                            zero-sized callable passed here
   |
   = note: zero-sized callable values have no runtime representation, so the call still targets the original function directly
   = help: coerce to a function pointer and call `black_box` on that pointer instead

The suggestion would be something like:

    let add_ptr: fn(u32, u32) -> u32 = add;
    let add_bb = black_box(add_ptr);

We have some other errors and warnings that make suggestions like this, so I'd try to look at what they do and see if you can reuse that infrastructure.

[eholk]

@bors r+

[bors]

📌 Commit a02a37f has been approved by eholk

It is now in the queue for this repository.

[RalfJung]

Lints are under the purview of t-lang. This is insta-stable as far as I can see. Has there been a t-lang FCP?

[RalfJung]

@bors r-

[eholk]

Ah, good call! Thanks for stepping in here.

[xonx4l]

Lints are under the purview of t-lang. This is insta-stable as far as I can see. Has there been a t-lang FCP?

Thanks for flagging this. I am happy to follow whatever process is needed.

[tgross35]

r? eholk
@rustbot label +I-lang-nominated

[rustbot]

eholk is currently at their maximum review capacity.
They may take a while to respond.

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[Darksonn]

I don't think the terminology "zero-sized callable" appears anywhere else. Should we be more specific and say "function item" or "closure" here?

[Darksonn]

There is another footgun potential here. For the specific case of closures, using black_box is probably wrong even if the closure's hidden type is has non-zero size.

After all, such use of black_box will apply the black box effect to the values of captured variables, but like here, it has no effect on call opacity.

[xonx4l]

I think if I used "function item" in the message it would look confusing if a user triggered it with black_box(()) as my implementation checks layout.is_zst(). If you like I can update the message to "zero-sized type" to be more readable and accurate.

[xonx4l]

And for the footgun I agree but this PR is scoped to ZSTs so I think to address it in a followup PR.

[Darksonn]

If it's not limited to callables, then yeah this should be reworded.

[xonx4l]

I've updated the error message to zero-sized type making it more readable and accurate. Thanks!

[scottmcm]

TBH I'm -0 on this because black_box is something that really you have to look at assembly if you're using it no matter what, so I don't know that I'd bother with a lint. Generally I just don't find it that persuasive as something into which to put effort.

But I also don't feel a need to try to block it 🤷

[tgross35]

TBH I'm -0 on this because black_box is something that really you have to look at assembly if you're using it no matter what, so I don't know that I'd bother with a lint. Generally I just don't find it that persuasive as something into which to put effort.

I stumbled into this when black-boxing a function for a benchmark (which is why I opened the issue). Of course it's probably ideal practice to do so, but I don't think most benchmark authors look at the assembly every time - I didn't until noticing weird results.

[rust-rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

[rust-log-analyzer]

The job aarch64-gnu-llvm-20-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

    |     ^^^^^^^^^^^^^^^^^^^^^^^--^
    |                            |
    |                            zero-sized value passed here
    |
    = note: zero-sized values have no runtime representation, so the compiler can ignore the call
    = help: if this is a function, coerce it to a function pointer first
    = note: `#[warn(black_box_zst_calls)]` on by default

[RUSTC-TIMING] std test:false 21.026
warning: `std` (lib) generated 1 warning
   Compiling rustc-std-workspace-std v1.99.0 (/checkout/library/rustc-std-workspace-std)
   Compiling proc_macro v0.0.0 (/checkout/library/proc_macro)

[rust-bors]

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