Unnecessary references lint

[obeis]

View all comments

Close #127724

[rustbot]

r? @Noratrieb

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

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[compiler-errors]

This lint seems really specific to a single kind of expression, and there are plenty of other cases where unnecessary references are created when the user is trying to create a raw pointer. Unless this can be greatly generalized, it doesn't really seem worth adding this.

[compiler-errors]

r? RalfJung

[obeis]

I agree, and my intention is to generalize this lint to cover all unnecessarily created references. Could you please list other cases that you think should be included? I can update this PR to cover them or create an issue to track these cases and mention that they should be added to the unnecessary_refs lint.

[RalfJung]

Sorry, I am swamped. Happy to discuss which cases the lint shoild fire on, but I can't review the implementation. r? compiler

[SparrowLii]

I know little about lints' impls so r? compiler

[RalfJung]

Do we have some people who are our "linting experts"?

[RalfJung]

This lint seems really specific to a single kind of expression, and there are plenty of other cases where unnecessary references are created when the user is trying to create a raw pointer. Unless this can be greatly generalized, it doesn't really seem worth adding this.

Which examples did you have in mind?

A starting point might be to uplift https://rust-lang.github.io/rust-clippy/master/index.html#borrow_as_ptr from cliippy to rustc, as you mention. It is not clear to me what the difference is between that lint and this one.

[traviscross]

Do we have some people who are our "linting experts"?

cc @Urgau

[Urgau]

Happy to take over the review. If @Nadrieril doesn't want to review it of course.

As for the lint it-self, I join @RalfJung that this is lint is currently clippy::borrow_as_ptr, which will need to be dropped from clippy. Look at 1fee1a4 for the changes needed.

As a drive-by, rustc_hir_pretty should not be necessary, a multi-part suggestion should be used instead, with some span manipulation to get the correct spans.

[Nadrieril]

Much appreciated :) r? @Urgau

[bors]

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

[obeis]

My PR is currently blocked because the stdarch bump is waiting on a bootstrap bump, see this.

[Urgau]

@obeis What's the status of this PR? Was the stdarch bump issue resolved?

[obeis]

@Urgau I think stdarch bump issue is resolved. I will update this PR in few next days.

[RalfJung]

It looks like most of this PR is about fixing occurrences of the lint in library. That's mostly done by adding allow, which is not a great fix.

Maybe it'd make sense to land this lint as allow-by-default first, and then only slowly enable it throughout the library by actually removing the unnecessary references? Given the amount of times this triggers on the library, it seems likely to also trigger a lot in the wider ecosystem, so some sort of slow staging starting with allow-by-default might also make sense from that perspective. (We should definitely get t-lang input before landing this.)

[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.

[obeis]

@RalfJung I agree, let's land this as allow-by-default for now.

[traviscross]

Makes sense to me. Thanks @obeis and @RalfJung.

Lint details

This is an allow-by-default lint:

unnecessary-refs

The unnecessary_refs lint checks for unnecessary references.

Example

#![warn(unnecessary_refs)]

fn via_ref(x: *const (i32, i32)) -> *const i32 {
    unsafe { &(*x).0 as *const i32 }
}

fn main() {
    let x = (0, 1);
    let _r = via_ref(&x);
}

This will produce:

warning: creating an intermediate reference implies aliasing requirements even when immediately casting to raw pointers
 --> lint_example.rs:4:14
  |
4 |     unsafe { &(*x).0 as *const i32 }
  |              ^^^^^^^^^^^^^^^^^^^^^
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![warn(unnecessary_refs)]
  |         ^^^^^^^^^^^^^^^^
help: consider using `&raw const` for a safer and more explicit raw pointer
  |
4 -     unsafe { &(*x).0 as *const i32 }
4 +     unsafe { &raw const (*x).0 }
  |

Explanation

Creating unnecessary references is discouraged because it can reduce readability, introduce performance overhead, and lead to undefined behavior if the reference is unaligned or uninitialized. Avoiding them ensures safer and more efficient code.

This lint is proposed at allow-by-default so it can land while we adjust the standard library and gauge effects on the ecosystem.

@rfcbot fcp merge lang

---

In terms of the current implementation, I understand the following to be true.

fn redundant_block(x: u8) {
    let _x = { &x } as *const u8;
}

It doesn't fire for the above, but should.

fn vec_index_deref(x: *mut Vec<u8>) -> *mut u8 {
    unsafe { &mut (*x)[0] as *mut u8 }
}

It fires for this one, but should not, because the place isn't reachable through built-in projections and so a reference is materialized in MIR regardless. After applying the lint's suggestion, the MIR is the same, and the dangerous_implicit_autorefs lint still fires.

fn vec_index(v: &mut Vec<u8>) -> *mut u8 {
    &mut v[0] as *mut u8
}

Similar to the above, the lint fires and applying the suggestion results in code that produces the same MIR. (In this case, though, dangerous_implicit_autorefs doesn't fire.)

[rust-rfcbot]

@traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[traviscross]

Suggested change

	"creating a intermediate reference implies aliasing requirements even when immediately casting to raw pointers"
	"creating an intermediate reference implies aliasing requirements even when immediately casting to raw pointers"

View changes since the review