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

[brson]

Tracking RFC 40: rust-lang/rfcs#16

[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.

[nagisa]

Relevant issue #43494

I still think it is a good idea to work on stabilising different groups of expressions, starting with the most trivial and useful of all -- blocks, so e.g. { #![cfg(...)] ... } could be used.

We can then think how and if we want to stabilise the other sort of statement/expression attributes.

@liigo that’s just a

#[foo] {
    exprs/stmts/blocks
}
// or
{ #![foo] 
    exprs/stmts/blocks
}

[solson]

I still think it is a good idea to work on stabilising different groups of expressions, starting with the most trivial and useful of all -- blocks, so e.g. { #![cfg(...)] ... } could be used.

This form is already stable:

• example with #![]
• example with #[]

We can also already use #[] directly on statements. Only expression attributes remain unstable and undecided.

[nagisa]

@solson It is only stable for blocks in statement position.

[solson]

Ah, fair point. In that case, I would think it an odd decision to stabilize just blocks in expression position next, instead of all expressions. I think we already came up with reasonable rules for parsing above, and we should have an FCP about implementing and stabilizing for all expressions if there are no major objections.

[jonhoo]

To make this easier to find for others, this issue (afaict) is why we can't have cfg attributes on if statements:

#[cfg(test)]
if true {
    println!("testing");
}

fails to compile with

attributes are not yet allowed on `if` expressions

Perhaps it'd be useful to make that error include a reference to this issue?

[xftroxgpx]

This seems to be the proper place to raise this: (if not, let me know)

Why is the {} block necessary for cfg attributes on macro calls ?

and I'm generalizing that based on only this one example using the println! macro and this clippy lint print_stdout so, I might be wrong in my loaded question assumptions. (in which case, please correct me)

#![feature(plugin)]
#![plugin(clippy)]

#![deny(print_stdout)]

fn main() {

    #[allow(print_stdout)] {
        println!("Hello, world!"); // all good now
    }

    {
        #![allow(print_stdout)]
        println!("Hello, world!"); // all good
    }

    #[allow(print_stdout)]
    println!("Hello, world!"); //error: use of `println!`
}

It feels like there's a multi-line behind-the-scenes expansion of println!. Or is there something clippy does wrong? (I tried asking on IRC...)

What is actually happening and will this be supported when this issue is closed?

1. $ cargo new --bin proj1
2. Add line in Cargo.toml for clippy

[dependencies]
clippy = "*"

3. replace src/main.rs contents with the above example
4. $ cargo build

error: use of `println!`
  --> /tmp/proj1/src/main.rs:18:5
   |
18 |     println!("Hello, world!"); //error: use of `println!`
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
note: lint level defined here
  --> /tmp/proj1/src/main.rs:4:9
   |
4  | #![deny(print_stdout)]
   |         ^^^^^^^^^^^^
   = help: for further information visit https://rust-lang-nursery.github.io/rust-clippy/v0.0.187/index.html#print_stdout

error: aborting due to previous error

error: Could not compile `proj1`.

To learn more, run the command again with --verbose.

[eddyb]

Your first two examples are identical, the second one uses #! so it applies to the enclosing block instead of the macro invocation. Maybe you know this already but it tripped me up a bit since I didn't initially notice.

[xftroxgpx]

@eddyb sorry :D I didn't mean to include that one initially, but the first I've seen of it was here in this thread, in these two comments from above:
#15701 (comment)
#15701 (comment)

and I thought it was kinda clever and wanted to have it added, for completion(so to have all known ways to add attrs to macro calls - in my case), though I initially wanted to include only first and third examples only

[eddyb]

Well, neither of the first two examples attach an attribute to the macro invocation, but to a block surrounding it - maybe macro expansion just discards the attribute in the third example?
cc @jseyfried

[goffrie]

Is it expected that attributes on function arguments are allowed?

fn main() {
    drop(#[cfg(never)] 1, #[cfg(not(never))] 2); // compiles fine on stable
}

edit: never mind, I see it was mentioned in #15701 (comment)

[pnkfelix]

@goffrie my theory (which I documented on #32796) is that such attributes were accidentally stabilized.

[bluss]

Same with #[inline] on closures, compiles fine on Rust 1.28 - 1.31 when the closure expression is a function parameter.

[liuchong]

I would like a rust conditional compile block, seems like:

// mod.rs
#[cfg(any(unix))]
{
    pub const MAIN_CMD: &str = "my-app";
    pub const SHELL_CMD: &str = "sh";
}

#[cfg(any(windows))]
{
    pub const MAIN_CMD: &str = "my-app.exe";
    pub const SHELL_CMD: &str = "cmd.exe";
}

say, one "cfg" multiple lines, is this possiable?

[alercah]

There's a separate issue for applying attributes to multiple items.

[alercah]

It's worth noting that in many cases you can work around the lack of expression attribute support by simply wrapping the expression in a block, turning it into a statement.

[topecongiro]

Currently, in the following example, rustc parses the attribute as it belongs to foo, not to the whole assignment:

#![feature(stmt_expr_attributes)]

fn main() {
    let foo;
    #[must_use]
    foo = false;
}

Is this expected? I think the behavior is inconsistent with how rustc parsed the attribute on let.