Repository navigation
dangerous_implicit_autorefs suggestion is wrong #140721
Description
The following code:
unsafe fn slice_ptr_len_because_of_msrv<T>(slice: *const [T]) -> usize {
unsafe { (*slice)[..].len() }
}gives the two following warnings
warning: implicit autoref creates a reference to the dereference of a raw pointer
--> src/main.rs:2:14
|
2 | unsafe { (*slice)[..].len() }
| ^^^^^^^^^^^^^^^^^^
|
= note: creating a reference requires the pointer target to be valid and imposes aliasing requirements
= note: `#[warn(dangerous_implicit_autorefs)]` on by default
help: try using a raw pointer method instead; or if this reference is intentional, make it explicit
|
2 | unsafe { (&(*slice)[..]).len() }
| ++ +
warning: implicit autoref creates a reference to the dereference of a raw pointer
--> src/main.rs:2:14
|
2 | unsafe { (*slice)[..].len() }
| ^^^^^^^^^^^^
|
= note: creating a reference requires the pointer target to be valid and imposes aliasing requirements
help: try using a raw pointer method instead; or if this reference is intentional, make it explicit
|
2 | unsafe { (&(*slice))[..].len() }
| ++ +
I the first warning is quite a duplicate of the second one, and its suggestion is also wrong, as (&(*slice)[..]).len() would still trigger the warning.
See also:
Activity
Urgau commentedon May 7, 2025
The two warnings are not duplicated. They warn on two different part of the expression.
Applying both suggestions make the warnings disappear.
wyfo commentedon May 7, 2025
I may be wrong, but the way I understand the first warning is that it indicates that the autoref happens between
(*slice)[..]and.len()(hence the fix with(&(*slice)[..]).len()), which is wrong.There is only one place where the autoref happens in the expression, so I think there should be only one warning.
By the way, you can as much additional warning that you want by adding
[..].Jarcho commentedon May 7, 2025
The autoref actually happens on the slice operation
(*slice)[..]. This is a call to<[T] as Index<RangeFull>>::indexwhich takes&[T]. The compiler warning twice is definitely wrong since the call tolenhappens on the result of*Index::index(..)which is a deref of a reference.Urgau commentedon May 7, 2025
For the compiler,
*Index::index(..)does not exist, more precisely in the HIR the output type of(*slice)[..]is[T], there is no implicit or explicit deref.And because the
lenfunction is marked with#[rustc_no_implicit_refs](and we peel the[..], rule 2. peel place expressions) we then see the deref of a raw pointer and lint on it.It's unclear to me if it's a bug.
cc @traviscross
Rollup merge of rust-lang#140768 - Urgau:improv_autorefs-lint, r=fmease
Rollup merge of rust-lang#140768 - Urgau:improv_autorefs-lint, r=fmease
Rollup merge of rust-lang#140768 - Urgau:improv_autorefs-lint, r=fmease
Unrolled build for rust-lang#140768
traviscross commentedon Oct 15, 2025
We talked about this in a lang meeting. Interesting question. Similar to @Urgau, and for the same reasons, it wasn't clear to us that this is a bug.
At the same time, we're always interested in making diagnostics better and more clear when we can do that without them being any less correct, so if someone has a particular proposal here, in the form of a PR, please nominate that for us along with a detailed analysis, in the context of the rules described in #103735 (comment), about why the change would be correct.
tmandry commentedon Oct 15, 2025
Is it correct that the compiler still warns on
(*slice)[..]then? (I think the answer is yes.)But it's reasonable to say that the compiler doesn't need to lint on both of these expressions at once. As long as it lints on at least one of the expressions as well as both
(*slice)[..]and(*slice).len()on their own, the presentation of one or multiple warnings isn't important.It's motivating that you only need to apply one of the suggestions; from a UI perspective that indicates that combining the lints would be preferable.
tmandry commentedon Oct 15, 2025
In summary, I think there is a potential for improvement here. Since much of the commentary on this issue has been responding to the framing of the suggestion as "wrong", I suggest opening a new issue framed in terms of improving the suggestion(s) and presentation of the lint.