-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking issue for stmt_expr_attributes: Add attributes to expressions, etc. #15701
Comments
cc @huonw |
ping. will this be implemented before 1.0? |
The RFC suggests
which inspired me to make a plugin for cryptographically signing |
The RFC says:
Does this mean that And what happens if an attribute is applied to a syntax sugar construct that is later expanded, for example |
Just a heads up that I'm currently in the process of implementing this RFC. |
I think the obvious choice is to give attributes the same operator precedence as unary operators. |
Yeah, thats how I'm doing it in my WIP branch right now. |
…kfelix See rust-lang/rfcs#16 and #15701 - Added syntax support for attributes on expressions and all syntax nodes in statement position. - Extended `#[cfg]` folder to allow removal of statements, and of expressions in optional positions like expression lists and trailing block expressions. - Extended lint checker to recognize lint levels on expressions and locals. - As per RFC, attributes are not yet accepted on `if` expressions. Examples: ```rust let x = y; { ... } assert_eq!((1, #[cfg(unset)] 2, 3), (1, 3)); let FOO = 0; ``` Implementation wise, there are a few rough corners and open questions: - The parser work ended up a bit ugly. - The pretty printer change was based mostly on guessing. - Similar to the `if` case, there are some places in the grammar where a new `Expr` node starts, but where it seemed weird to accept attributes and hence the parser doesn't. This includes: - const expressions in patterns - in the middle of an postfix operator chain (that is, after `.`, before indexing, before calls) - on range expressions, since `#[attr] x .. y` parses as `(#[attr] x) .. y`, which is inconsistent with `#[attr] .. y` which would parse as `#[attr] (.. y)` - Attributes are added as additional `Option<Box<Vec<Attribute>>>` fields in expressions and locals. - Memory impact has not been measured yet. - A cfg-away trailing expression in a block does not currently promote the previous `StmtExpr` in a block to a new trailing expr. That is to say, this won't work: ```rust let x = { #[cfg(foo)] Foo { data: x } #[cfg(not(foo))] Foo { data: y } }; ``` - One-element tuples can have their inner expression removed to become Unit, but just Parenthesis can't. Eg, `(#[cfg(unset)] x,) == ()` but `(#[cfg(unset)] x) == error`. This seemed reasonable to me since tuples and unit are type constructors, but could probably be argued either way. - Attributes on macro nodes are currently unconditionally dropped during macro expansion, which seemed fine since macro disappear at that point? - Attributes on `ast::ExprParens` will be prepend-ed to the inner expression in the hir folder. - The work on pretty printer tests for this did trigger, but not fix errors regarding macros: - expression `foo![]` prints as `foo!()` - expression `foo!{}` prints as `foo!()` - statement `foo![];` prints as `foo!();` - statement `foo!{};` prints as `foo!();` - statement `foo!{}` triggers a `None` unwrap ICE.
Not as far as I can rember, probably just forgot about it. :) |
FYI, the |
Tracking issues are open until the feature is stable, aren't they? |
Not stable, but used in the compiler. Tracking issue: rust-lang/rust#15701
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. |
warning: unused import: `std::process::Command` --> src/bin/maprando-web.rs:2:5 warning: unused variable: `notable_strats` --> src/bin/maprando-web.rs:308:5 warning: field `start_addr` is never read --> src/customize/room_palettes.rs:198:5 warning: unused variable: `area_idx` --> src/game_data.rs:2484:14 warning: unused variable: `door` --> src/patch.rs:1642:21 warning: variable does not need to be mutable --> src/patch.rs:1642:17 NOTE: Line 1641 changed from `for door` to `for _door` as well warning: variable does not need to be mutable --> src/patch.rs:1013:21 NOTE: Commented out code below this would require `mut` if reinstated unless folded into initialization ternary-style e.g. `let new_song = if room.name != "Landing Site" { area_music[area][subarea] } else { 0x0606 };` warning: unused import: `Path` --> src/web/logic.rs:1:17 warning: unused variable: `name_no_space` --> /rust/target/release/build/sailfish-compiler-4c1b9b72b1c17739/out/templates/room-eb0b5fdf3a787627:1:10114 NOTE: Root cause was in `templates/logic/room.stpl`: Removed line 41 `let name_no_space = &difficulty.replace(" ", "");` NOTE: There are 6 "unused variable" warnings left in src/web/logic.rs Most of these are "used" in the sense that they are cloned, however it seems that rust doesn't count that as a "use" Adding `#[allow(unused_variables)]` before the properties does not work, and from what i can tell they're still working on fully implementing attributes for expressions/structs/etc (rust-lang/rust#15701) Adding the `#![allow(unused_variables)]` attribute to the top of the file silences these, but it's too broad as it covers the whole file
warning: unused import: `std::process::Command` --> src/bin/maprando-web.rs:2:5 warning: unused variable: `notable_strats` --> src/bin/maprando-web.rs:308:5 warning: field `start_addr` is never read --> src/customize/room_palettes.rs:198:5 warning: unused variable: `area_idx` --> src/game_data.rs:2484:14 warning: unused variable: `door` --> src/patch.rs:1642:21 warning: variable does not need to be mutable --> src/patch.rs:1642:17 NOTE: Line 1641 changed from `for door` to `for _door` as well warning: variable does not need to be mutable --> src/patch.rs:1013:21 NOTE: Commented out code below this would require `mut` if reinstated unless folded into initialization ternary-style e.g. `let new_song = if room.name != "Landing Site" { area_music[area][subarea] } else { 0x0606 };` warning: unused import: `Path` --> src/web/logic.rs:1:17 warning: unused variable: `name_no_space` --> /rust/target/release/build/sailfish-compiler-4c1b9b72b1c17739/out/templates/room-eb0b5fdf3a787627:1:10114 NOTE: Root cause was in `templates/logic/room.stpl`: Removed line 41 `let name_no_space = &difficulty.replace(" ", "");` NOTE: There are 6 "unused variable" warnings left in src/web/logic.rs Most of these are "used" in the sense that they are cloned, however it seems that rust doesn't count that as a "use" Adding `#[allow(unused_variables)]` before the properties does not work, and from what i can tell they're still working on fully implementing attributes for expressions/structs/etc (rust-lang/rust#15701) Adding the `#![allow(unused_variables)]` attribute to the top of the file silences these, but it's too broad as it covers the whole file Co-authored-by: Starson Hochschild <starsonh@gmail.com>
…ge2, r=lnicola fix: strip base prefix in `layout_scalar_valid_range` CC https://github.com/rust-lang/rust-analyzer/pull/15688/files#r1342311078
From what I understand the issue blocking this is ambiguity -- even if the RFC specifies what
Then we can provide a suggestion to add parenthesis around the expression, if it is not supported:
(writing this down here because I have no capacity to work on this) |
The error mentions `///`, when it's actually `//!`: error[E0658]: attributes on expressions are experimental --> test.rs:4:9 | 4 | //! wah | ^^^^^^^ | = note: see issue rust-lang#15701 <rust-lang#15701> for more information = help: add `#![feature(stmt_expr_attributes)]` to the crate attributes to enable = help: `///` is for documentation comments. For a plain comment, use `//`.
The error mentions `///`, when it's actually `//!`: error[E0658]: attributes on expressions are experimental --> test.rs:4:9 | 4 | //! wah | ^^^^^^^ | = note: see issue rust-lang#15701 <rust-lang#15701> for more information = help: add `#![feature(stmt_expr_attributes)]` to the crate attributes to enable = help: `///` is for documentation comments. For a plain comment, use `//`.
The error mentions `///`, when it's actually `//!`: error[E0658]: attributes on expressions are experimental --> test.rs:4:9 | 4 | //! wah | ^^^^^^^ | = note: see issue rust-lang#15701 <rust-lang#15701> for more information = help: add `#![feature(stmt_expr_attributes)]` to the crate attributes to enable = help: `///` is for documentation comments. For a plain comment, use `//`.
The error mentions `///`, when it's actually `//!`: error[E0658]: attributes on expressions are experimental --> test.rs:4:9 | 4 | //! wah | ^^^^^^^ | = note: see issue rust-lang#15701 <rust-lang#15701> for more information = help: add `#![feature(stmt_expr_attributes)]` to the crate attributes to enable = help: `///` is for documentation comments. For a plain comment, use `//`.
The error mentions `///`, when it's actually `//!`: error[E0658]: attributes on expressions are experimental --> test.rs:4:9 | 4 | //! wah | ^^^^^^^ | = note: see issue rust-lang#15701 <rust-lang#15701> for more information = help: add `#![feature(stmt_expr_attributes)]` to the crate attributes to enable = help: `///` is for documentation comments. For a plain comment, use `//`.
…s, r=davidtwco Disallow ambiguous attributes on expressions This implements the suggestion in [rust-lang#15701](rust-lang#15701 (comment)) to disallow ambiguous outer attributes on expressions. This should resolve one of the concerns blocking the stabilization of `stmt_expr_attributes`.
Rollup merge of rust-lang#124099 - voidc:disallow-ambiguous-expr-attrs, r=davidtwco Disallow ambiguous attributes on expressions This implements the suggestion in [rust-lang#15701](rust-lang#15701 (comment)) to disallow ambiguous outer attributes on expressions. This should resolve one of the concerns blocking the stabilization of `stmt_expr_attributes`.
I agree with @WaffleLapkin on that path forward |
It would be especially good to move forward with making this available for closures, seeing as only one of these closures fires the
|
The error mentions `///`, when it's actually `//!`: error[E0658]: attributes on expressions are experimental --> test.rs:4:9 | 4 | //! wah | ^^^^^^^ | = note: see issue rust-lang#15701 <rust-lang#15701> for more information = help: add `#![feature(stmt_expr_attributes)]` to the crate attributes to enable = help: `///` is for documentation comments. For a plain comment, use `//`.
…dtwco Disallow ambiguous attributes on expressions This implements the suggestion in [#15701](rust-lang/rust#15701 (comment)) to disallow ambiguous outer attributes on expressions. This should resolve one of the concerns blocking the stabilization of `stmt_expr_attributes`.
…er-errors expand: fix minor diagnostics bug The error mentions `///`, when it's actually `//!`: ``` error[E0658]: attributes on expressions are experimental --> test.rs:4:9 | 4 | //! wah | ^^^^^^^ | = note: see issue rust-lang#15701 <rust-lang#15701> for more information = help: add `#![feature(stmt_expr_attributes)]` to the crate attributes to enable = help: `///` is for documentation comments. For a plain comment, use `//`. ```
…iler-errors expand: fix minor diagnostics bug The error mentions `///`, when it's actually `//!`: ``` error[E0658]: attributes on expressions are experimental --> test.rs:4:9 | 4 | //! wah | ^^^^^^^ | = note: see issue rust-lang#15701 <rust-lang#15701> for more information = help: add `#![feature(stmt_expr_attributes)]` to the crate attributes to enable = help: `///` is for documentation comments. For a plain comment, use `//`. ```
Rollup merge of rust-lang#123694 - Xiretza:expand-diagnostics, r=compiler-errors expand: fix minor diagnostics bug The error mentions `///`, when it's actually `//!`: ``` error[E0658]: attributes on expressions are experimental --> test.rs:4:9 | 4 | //! wah | ^^^^^^^ | = note: see issue rust-lang#15701 <rust-lang#15701> for more information = help: add `#![feature(stmt_expr_attributes)]` to the crate attributes to enable = help: `///` is for documentation comments. For a plain comment, use `//`. ```
…dtwco Disallow ambiguous attributes on expressions This implements the suggestion in [#15701](rust-lang/rust#15701 (comment)) to disallow ambiguous outer attributes on expressions. This should resolve one of the concerns blocking the stabilization of `stmt_expr_attributes`.
Tracking RFC:
Related
The text was updated successfully, but these errors were encountered: