Tracking issue for stmt_expr_attributes: Add attributes to expressions, etc.

[brson]

Tracking RFC:

• RFC for attributes on statements and blocks. rfcs#16

Related

• Decide on path forward for attributes on expressions #127436

[brson]

cc @huonw

[liigo]

ping. will this be implemented before 1.0?

[kmcallister]

The RFC suggests

The sort of things one could do with other arbitrary annotations are

#[allowed_unsafe_actions(ffi)]
#[audited="2014-04-22"]
unsafe { ... }

and then have an external tool that checks that that unsafe block's only unsafe actions are FFI, or a tool that lists blocks that have been changed since the last audit or haven't been audited ever.

which inspired me to make a plugin for cryptographically signing unsafe blocks. It would be great to put those signatures on the blocks themselves rather than the enclosing function.

[jonas-schievink]

The RFC says:

Attributes bind tighter than any operator, that is #[attr] x op y is always parsed as (#[attr] x) op y.

Does this mean that #[attr] x.f() should be parsed as (#[attr] x).f()? And should #[a] f() be the same as (#[a] f)()?

And what happens if an attribute is applied to a syntax sugar construct that is later expanded, for example #[attr] in <place> { <expr> }? There isn't really an obvious place for the attribute in the desugared form, so not allowing them seems more sensible.

[Kimundi]

Just a heads up that I'm currently in the process of implementing this RFC.

[dgrunwald]

I think the obvious choice is to give attributes the same operator precedence as unary operators.
So #[attr] x.f() would be parsed as #[attr] (x.f()), but #[attr] x + f will be (#[attr] x) + f.

[Kimundi]

Yeah, thats how I'm doing it in my WIP branch right now.

[huonw]

@Kimundi, is there a reason that #29850 doesn't close this?

[Kimundi]

Not as far as I can rember, probably just forgot about it. :)

[comex]

FYI, the stmt_expr_attributes feature gate still mentions this issue number.

[bluss]

Tracking issues are open until the feature is stable, aren't they?

[msjyoo]

By what Rust version will this feature gate be allowed on the stable channel? I couldn't find any chart / matrix with the list of them.

[WaffleLapkin]

From what I understand the issue blocking this is ambiguity -- even if the RFC specifies what #[meow] 1 + 1 means, it's still not very readable. I think the path forward is to cut this feature to only allow attributes on things that are unambiguous, such as:

• All kinds of braces: #[meow] (1 + 1), #[uwu] [1, 2, 3], #[purr] {} (parethesis/grouping expr, tuples, arrays, blocks)
• Closures: #[kwncjhn] || 2
• Expressions starting with a keyword: #[meow] if x {}, #[attr] loop { break 'rust; }, #[kva] while false {}, ...
• etc

Then we can provide a suggestion to add parenthesis around the expression, if it is not supported:

error: meow meow meow ambiguous attribute
 --> src/main.rs:LL:CC
   |
LL |     let x = #[meow] 1 + 1;
   |
help: wrap the expression in parenthesis
   |
LL |     let x = #[meow] (1 + 1);
   |                     +     +
help: wrap the expression in parenthesis (alternative
   |
LL |     let x = (#[meow] 1) + 1;
   |             +         +

(writing this down here because I have no capacity to work on this)

[nikomatsakis]

I agree with @WaffleLapkin on that path forward

[workingjubilee]

It would be especially good to move forward with making this available for closures, seeing as only one of these closures fires the feature(stmt_expr_attributes) gate, and unless you particularly enjoy this kind of trivia, it's probably not the one you think:

fn main() {
    let _blocked_closure = {
        #[warn(nonsense)]
        || todo!()
    };
    
    let _closure_blocked = #[warn(nonsense)] || { todo!() };
}