Fix unused_unsafe label with unsafe_block_in_unsafe_fn

[LeSeulArtichaut]

Previously, the following code:

#![feature(unsafe_block_in_unsafe_fn)]

unsafe fn foo() {
    unsafe { unsf() }
}

unsafe fn unsf() {}

Would give the following warning:

warning: unnecessary `unsafe` block
 --> src/lib.rs:4:5
  |
4 |     unsafe { unsf() }
  |     ^^^^^^ unnecessary `unsafe` block
  |
  = note: `#[warn(unused_unsafe)]` on by default

which doesn't point out that the block is in an unsafe fn.

Tracking issue: #71668
cc #79208

[rust-highfive]

r? @lcnr

(rust-highfive has picked a reviewer for you, use r? to override)

[RalfJung]

I don't see the problem here? What you describe in the OP is intended behavior!

unused_unsafe should be "in effect" unless the unsafe_block_in_unsafe_fn lint was enabled. feature(unsafe_block_in_unsafe_fn) doesn't enable the lint; warn(unsafe_block_in_unsafe_fn) does.

[RalfJung]

IOW, the feature gate itself should not change anything (as is common for feature gates). The feature gate merely unlocks the ability to use some other syntax to change something; in this case, that other syntax is warn(unsafe_block_in_unsafe_fn).

[RalfJung]

Oh, wait, I misunderstood... I thought you wanted to not show the warning, but instead you want to show more information with the warning? I have no idea why that has anything to do with the feature flag though...

[RalfJung]

FWIW, this error is kind of confusing because the "because" comes before the thing it is justifying. I guess there's also the error 'title' thing "unnecessary unsafe block", so it's probably okay, but just reading the spans things are in the wrong order... not sure how we usually handle situations where code order and "justification order" disagree.

[LeSeulArtichaut]

This is how the warning is emitted today (without unsafe_block_in_unsafe_fn). I guess any improvement here should be made in another PR

[LeSeulArtichaut]

Right, sorry, I was probably not clear enough in the OP. This PR "restores" the "because it's nested under this unsafe fn" label in the warning when the lint is allowed, to match the behavior when the feature gate is not present.

[RalfJung]

And as a drive-by fix it replaces a String by &'static str (I first thought that was somehow related but it seems not).

[lcnr]

@RalfJung do you intend to fully review this PR?

[RalfJung]

I guess at this point I just as well might.^^
r? @RalfJung

[LeSeulArtichaut]

@RalfJung This should be ready for another review

[RalfJung]

Looking good, thanks!
@bors r+

[bors]

📌 Commit 2136a5c has been approved by RalfJung

[bors]

⌛ Testing commit 2136a5c with merge 47121d6...

[bors]

☀️ Test successful - checks-actions
Approved by: RalfJung
Pushing 47121d6 to master...