`dangerous_implicit_autorefs` lint suggestion still triggers `clippy::needless_borrow`

[viliml]

Summary

Continuation of #14743

If the reference is not of the pointer directly but of a field of the pointed-to structure, the clippy::needless_borrow lint still triggers.

Lint Name

needless_borrow

Reproducer

If we modify the original reproducer like this:

unsafe fn repro<T>(slice: *const (i32, [T])) -> usize {
    unsafe { (*slice).1.len() }
}

that triggers roughly the same rustc lint as in the original reproducer:

error: implicit autoref creates a reference to the dereference of a raw pointer
   --> lib.rs:2:14
    |
  2 |     unsafe { (*slice).1.len() }
    |              ^^-----^^^^^^^^^
    |                |
    |                this raw pointer has type `*const (i32, [T])`       
    |
    = note: creating a reference requires the pointer target to be valid and imposes aliasing requirements
note: autoref is being applied to this expression, resulting in: `&[T]`  
   --> lib.rs:2:14
    |
  2 |     unsafe { (*slice).1.len() }
    |              ^^^^^^^^^^
    |
116 |     pub const fn len(&self) -> usize {
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    = note: `#[deny(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).1).len() }
    |              ++          +

If the suggestion is applied, then clippy complains:

warning: this expression borrows a value the compiler would automatically borrow
 --> lib.rs:2:14
  |
2 |     unsafe { (&(*slice).1).len() }
  |              ^^^^^^^^^^^^^ help: change this to: `(*slice).1`
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_borrow
  = note: `#[warn(clippy::needless_borrow)]` on by default

Version

rustc 1.99.0-nightly (be8e82435 2026-07-11)
binary: rustc
commit-hash: be8e82435eb04fbe75ed5286b52735366e160bed
commit-date: 2026-07-11
host: x86_64-pc-windows-msvc
release: 1.99.0-nightly
LLVM version: 22.1.8

Additional Labels

No response

[skiefucker]

Hello, I'm new here but I'd like to help out with this issue.

After testing, I found that if I apply the suggestion from the error message and change the code to:

unsafe fn repro<T>(slice: *const (i32, [T])) -> usize {
    unsafe { (&(*slice).1).len() }
}

It does compile successfully and no warning. Would you be able to provide a bit more detailed context or a more complete code example for this case?

For reference, I'm using rustc 1.99.0-nightly (77cf889bc 2026-07-12).

Thank you for your time!

Edit:
Sorry, cargo clippy will trigger this, not cargo run !

[skiefucker]

@rustbot claim

[skiefucker]

Overview

clippy_lints::dereference.rs:needless_borrow and rustc_lint::autoref.rs:DANGEROUS_IMPLICIT_AUTOREFS are deeply intertwined.

Below I will analyze both lints, share my progress, and outline some remaining questions.
This might not be fully rigorous – corrections are very welcome!

---

autoref.rs

Here is the flow I have deduced:

1. When a method is called, check whether the receiver has an Adjustment that corresponds to an automatic reference.
2. Unwrap nested Index/Field operations on the receiver. If one level deeper is a dereference, check whether it is a dereference of a raw pointer.
3. Inspect the called method’s attributes to see if it carries #[rustc_no_implicit_autorefs] (shortened to attr_no_auto below).
4. If all the above conditions are met, it indicates that the raw pointer has been implicitly autorefed, and the lint warns about DANGEROUS_IMPLICIT_AUTOREFS.
5. Btw, There are other cases of implicit autoref as well, and autoref.rs does not reject them upfront – which I find somewhat puzzling.

---

dereference.rs

When I tried to adapt a similar approach to modify dereference.rs, I found it was not so straightforward.

The current logic in dereference.rs:

1. To decide whether an explicit borrow can be simplified, it first checks whether the current expression is a reference type (e.g., &/*). Only then does it proceed.
2. It examines how the current expression is used. If the Adjustment includes an automatic reference, it counts that.
3. Based on the usage, it determines whether automatic referencing is possible. (This is also the part I aim to fix, as mentioned later.)
4. If automatic referencing is possible, it initializes a state.
5. Finally, it emits a warning based on the state. (This is where the fix for Issue dangerous_implicit_autorefs lint suggestion triggers clippy::needless_borrow #14743 was applied: it checks whether the immediate sub‑expression of the borrow is a dereference of a raw pointer, and if so, returns early without warning.)

---

Progress

Take the following code as an example:

unsafe {
    let data_addr = &(42_i32, (43_i32, [1_usize, 2, 3])) as *const _ as *const ();
    let nested_tuple: *const (i32, (i32, [usize])) = ptr::from_raw_parts(data_addr, 3);
    // let _ = (*nested_tuple).1.1.len(); // Stmt1. compile fail
    let _ = (&*nested_tuple).1.1.len(); // Stmt2. compile success
    let _ = (&(*nested_tuple).1).1.len(); // Stmt3. compile success
    let _ = (&(*nested_tuple).1.1).len(); // Stmt4. compile success
}

1. autoref.rs can easily catch the issue via the .len() call: if the receiver dereferences a raw pointer and there is no explicit borrow, it warns correctly.
2. After the fix for dangerous_implicit_autorefs lint suggestion triggers clippy::needless_borrow #14743, Clippy correctly recognises Stmt2 (because & is immediately followed by *). However, it still warns about Stmt3 and Stmt4 as having unnecessary explicit borrows.
3. How to fix further? My idea was: when the borrow is the receiver of a method call, check whether the innermost level of the borrow is a dereference of a raw pointer, and whether the method is annotated with attr_no_auto. After implementing this approach and testing, the specific case mentioned in this issue – *const (i32, [usize]) – was perfectly resolved.
4. However, when I tested the example above, I ran into a problem: my fix only handled Stmt4; Stmt2 and Stmt3 still triggered false warnings. (The previous fix handled only Stmt2, but not Stmt3 and Stmt4.)
5. In other words, the earlier fix only covered &*raw_pointer, whereas my fix only covered (&(...*raw_pointer...)).no_auto_method().

---

Solutions

1. Abandon this lint entirely inside unsafe blocks. (This may not be trivial to implement, but the logic is clear.)
2. Determine whether the innermost expression of the borrow is a dereference of a raw pointer, and whether the borrow, after multiple Index/Field operations, is used to call a method with attr_no_auto. If so, skip the lint. (I will strive to implement this approach.)
3. A simpler alternative: just check whether the innermost expression of the borrow is a dereference of a raw pointer, and return immediately without inspecting subsequent operations. Because avoiding analyzing following operations, it would make the code simpler and improve performance. However, it may also skip some cases where the lint would be legitimate, so there is a trade‑off.

---

Open Questions

Although I have a rough implementation goal, a few issues remain unclear to me:

1. In Stmt3, an automatic reference also seems to occur, but rustc_lint does not detect it – or is my understanding wrong?

(&(*nested_tuple).1).1.len();
 ^^^^^^^^^^^^^^^^^^ref
                      ^^^^^^method, need &self
^^^^^^^^^^^^^^^^^^^^^^field, type [usize], will autoref

2. Difference between .len() on a slice vs. an array: why does (*b).len() compile successfully?

let a = [1, 2, 3];
let b: *const [i32; 3] = &raw const a;
let _ = (*b).len(); // success    ???Should fail???
let _ = (&*b).len(); // success

3. The Index trait and index() method

The [] indexing operation works directly on a dereferenced raw pointer to a slice/array, but does not work for a custom struct – this might be due to compiler optimisation. I will revisit this once the above is completed.

4. Readability of dereference.rs is not very high, for instance, the function check_expr has over 400 lines, which can be confusing to follow. Some refactoring might be beneficial, but this is not the primary focus of this issue. I plan to fix the bug first and then explore potential improvements separately in more detail.

---

Thank you for taking the time to read through my analysis. I would greatly appreciate any feedback, corrections, or suggestions you might have. Please let me know if I can clarify anything further.