`unused_parens` does not lint parentheses around method receiver

[theemathas]

Code

struct Thing;
impl Thing {
    fn method(self) {}
}

fn main() {
    let x = Thing;
    (x).method();
}

Current output

No warnings

Desired output

Warn about the unused parentheses around x

Rationale and extra context

No response

Other cases

Rust Version

Reproducible on the playground with version 1.95.0-nightly (2026-01-30 a293cc4af8b26701c427)

Anything else?

No response

[chenyukang]

do you think we should keep parens for this code?

warning: unnecessary parentheses around method receiver
   --> library/coretests/tests/floats/mod.rs:779:13
    |
779 |             (Float::MIN_POSITIVE).midpoint(Float::MIN_POSITIVE),
    |             ^                   ^

seems a bit clearer if we keep parens.

[dianne]

This might need a T-lang FCP, given that it's a significant change to the lint (and I think lints are within T-lang's purview?). Judging by how many instances of this PR CI has turned up, I imagine this will introduce lots of new warnings.

I tried checking the lint documentation to see whether this is aligned with it, but it's out of date even with regard to how the lint currently functions: https://doc.rust-lang.org/nightly/rustc/lints/listing/warn-by-default.html#unused-parens describes the lint as being for if, match, while and return, but there's lots of other places where it fires currently, like function arguments and let initializers.

I'll nominate this for discussion.

[scottmcm]

Initial thoughts: treat this like we do in expressions, where we do lint x + (y) and x + ((y * z)) but don't lint x + (y *z) even though the latter's parens are also "unused". Basically say that if you want to emphasize the grouping even though :: is already higher-precedence than . that seems fine, but if there's no "operator" there then linting would be consistent.