Implement a lint for implicit autoref of raw pointer dereference - take 2

[Urgau]

t-lang nomination comment

This PR aims at implementing a lint for implicit autoref of raw pointer dereference, it is based on #103735 with suggestion and improvements from #103735 (comment).

The goal is to catch cases like this, where the user probably doesn't realise it just created a reference.

pub struct Test {
    data: [u8],
}

pub fn test_len(t: *const Test) -> usize {
    unsafe { (*t).data.len() }  // this calls <[T]>::len(&self)
}

Since #103735 already went 2 times through T-lang, where they T-lang ended-up asking for a more restricted version (which is what this PR does), I would prefer this PR to be reviewed first before re-nominating it for T-lang.

---

Compared to the PR it is as based on, this PR adds 3 restrictions on the outer most expression, which must either be:

1. A deref followed by any non-deref place projection (that intermediate deref will typically be auto-inserted)
2. A method call annotated with #[rustc_no_implicit_refs].
3. A deref followed by a addr_of! or addr_of_mut!. See bottom of post for details.

There are several points that are not 100% clear to me when implementing the modifications:

• "4. Any number of automatically inserted deref/derefmut calls." I as never able to trigger this. Am I missing something? Fixed
• Are "index" and "field" enough?

---

cc @JakobDegen @WaffleLapkin
r? @RalfJung

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[RalfJung]

Sorry, I can't take on more reviews currently.
r? compiler
(or feel free to pick someone specific who's suited)

[Dylan-DPC]

@Urgau if you can rebase the latest conflicts we can push this forward and maybe get it reviewed by another reviewer

[Urgau]

@Dylan-DPC rebased.

@rustbot review

[WaffleLapkin]

Is this still blocked on lang?

[RalfJung]

Yes I think it is.

[scottmcm]

I agree that I don't like rustc lints that suggest suppressing them, so the change the suggest adding explicit &s if they're ok makes sense to me.

Let's do this. The addr_of!((*ptr)[..16]) example is a really nice one, since [16] and [..16] sure look like they might be the same related to this, but they're not.

@rfcbot fcp merge

[rfcbot]

Team member @scottmcm 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]

Sounds right. Thanks to @Urgau for pushing this forward and answering some of my earlier questions on it. Thanks to @JakobDegen for putting together the algorithm for this.

@rfcbot reviewed

[rfcbot]

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

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

This will be merged soon.

[traviscross]

Some nits mostly.

[traviscross]

With the nits above resolved, this looks right to me, so, @jdonszelmann, r=me along with your own review.

[jdonszelmann]

I'll give a final review soon, hopefully tomorrow and then this should be ok 🎉