Reduce precedence of expressions that have an outer attr

[dtolnay]

Previously, -Zunpretty=expanded would expand this program as follows:

#![feature(stmt_expr_attributes)]

macro_rules! repro {
    ($e:expr) => {
        #[allow(deprecated)] $e
    };
}

#[derive(Default)]
struct Thing {
    #[deprecated]
    field: i32,
}

fn main() {
    let thing = Thing::default();
    let _ = repro!(thing).field;
}

#![feature(prelude_import)]
#![feature(stmt_expr_attributes)]
#[prelude_import]
use std::prelude::rust_2021::*;
#[macro_use]
extern crate std;

struct Thing {
    #[deprecated]
    field: i32,
}

#[automatically_derived]
impl ::core::default::Default for Thing {
    #[inline]
    fn default() -> Thing {
        Thing { field: ::core::default::Default::default() }
    }
}

fn main() {
    let thing = Thing::default();
    let _ = #[allow(deprecated)] thing.field;
}

This is not the correct expansion. The correct output would have (#[allow(deprecated)] thing).field with the attribute applying only to thing, not to thing.field.

[rustbot]

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[fee1-dead]

r? compiler

[bors]

☔ The latest upstream changes (presumably #134788) made this pull request unmergeable. Please resolve the merge conflicts.

[dtolnay]

Rebased to resolve conflict.

[fmease]

I'm going to look at this in a few hours.

[fmease]

I think ExprPrecedence::Prefix isn't low enough. Consider the following cases involving binops:

#![feature(stmt_expr_attributes)]

macro_rules! group { ($e:expr) => { $e } }
macro_rules! extra { ($e:expr) => { #[allow()] $e } }

fn main() {                             // `-Zunpretty=expanded` on master & prefixattr:

    let _ = #[allow()] 1 + 1;           // let _ = #[allow()] 1 + 1;
    let _ = group!(#[allow()] 1) + 1;   // let _ = #[allow()] 1 + 1;
    let _ = 1 + group!(#[allow()] 1);   // let _ = 1 + #[allow()] 1;

    let _ = extra!({ 0 }) + 1;          // let _ = #[allow()] { 0 } + 1;
    let _ = extra!({ 0 } + 1);          // let _ = #[allow()] { 0 } + 1;
}

I haven't given it that much thought yet, so I don't know which specific precedence level(s) would make sense instead.

And indeed, this example is heavily inspired by the ones found in #15701 / #127436. So maybe answering this pretty-printing question is partially blocked by the open design question (meaning we can ignore it for now).

[dtolnay]

I think that bug is orthogonal to this one.

The bug fixed by this PR is about when an outer expression A contains a subexpression B where B contains an attribute, and in the prettyprinter-produced code the attribute ended up applying to parts of A instead of only to B. This is fixed by having A observe a different effective precedence for its subexpression B, making A generate parentheses around the subexpression containing the attribute, i.e. the attribute will end up inside the parentheses.

In contrast, the bug you have identified is about an outer expression A that has an attribute, and a subexpression B that has no attribute. In this case when parentheses are inserted, the attribute will end up outside the parentheses.

I will fix that as well but I expect it will involve unrelated code.

[dtolnay]

Fix: #142476

[bors]

☔ The latest upstream changes (presumably #137235) made this pull request unmergeable. Please resolve the merge conflicts.

[wesleywiser]

Hi @fmease, it looks like you marked this as waiting on review recently. Is this actually waiting on review or for the author to respond to your previous review comment?

[dtolnay]

Rebased to resolve conflicts with:

• Move methods from Map to TyCtxt, part 4. #137504
• ast: Remove token visiting from AST visitor #140450
• deduplicate the rest of AST walker functions #142240

[dtolnay]

@bors r=fmease

[bors]

📌 Commit 2171f89 has been approved by fmease

It is now in the queue for this repository.

[matthiaskrgr]

@bors r-
#142522 (comment)

[dtolnay]

I think that is misattributed. That exact same failure also appears in #142533 which does not include this PR.

@bors r=fmease

[bors]

📌 Commit 2171f89 has been approved by fmease

It is now in the queue for this repository.