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

[Urgau]

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

[Urgau]

It seems like there's still an open comment asking for T-lang feedback here? It's from august, did that ever happen? Not here at least it seems.

Not yet. That will be a question for the T-lang nomination, which will be after the logic in this PR is checked to be correct-ish.

[jdonszelmann]

Hmm, okay. I'll give it one more look but I'm reasonably confident this now at least implements the logic from the linked comment.

[jdonszelmann]

you could add an underscore to the pattern to represent the !is_empty

[Urgau]

I'm not following. _ mean "exactly one", but we want "one or more" so end @ _ won't work, and since we need to keep the .. (to get a slice) I don't see another way but to use !adjs.is_empty().

[jdonszelmann]

apart from that, the logic looks about right to me! let's ask for T-lang?

[Urgau]

Dear @rust-lang/lang (and @rust-lang/lang-advisors), this PR is implementing a lint dangerous_implicit_autorefs for linting against implicit autoref of raw pointer dereference (as deny-by-default), it is based on #103735 with suggestion and improvements from #103735 (comment) which result in a more restricted version (as asked).

Examples and algorithm: #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)
}

#103735 (the previous attempt) already went through you 2 times (#103735 (comment) and #103735 (comment)) which prompted this summary and suggestions from @JakobDegen which is what this PR implements.

You can see in tests/ui/lint/implicit_autorefs.rs the cases the lint would lint on.

One difference from Jakob suggestion is that this PR suggestion is to add explicit & references instead of suggesting to #[allow(dangerous_implicit_autorefs)] the lint. Which suggestion to use is left in your hands.

@rustbot labels +I-lang-nominated +S-waiting-on-team -S-waiting-on-review -T-libs -T-compiler

[traviscross]

Surely we shouldn't be suggesting to people to turn on nightly features as a replacement for what we're linting against.

[Urgau]

Switch this example to slice::from_raw_parts_mut, but more generally we don't always have a great story around raw pointers (as can be seen by the slice_ptr_get feature being nightly-only).