Skip to content
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

Add undocumented outer attributes above StructExpr fields #1150

Merged
merged 3 commits into from
Jan 30, 2022

Conversation

pushkine
Copy link
Contributor

Copy link
Contributor

@ehuss ehuss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Looks like this was implemented in rust-lang/rust#38814 and stabilized in rust-lang/rust#42656.

@ehuss ehuss merged commit 770c3f6 into rust-lang:master Jan 30, 2022
@pushkine
Copy link
Contributor Author

@ehuss it's actually indirectly documented at the bottom of the expression index page
https://doc.rust-lang.org/reference/expressions.html#expression-attributes

Note that CallExpression's CallParams and StructExprTuple's members are also missing outer attributes in their reference syntax, I was not comfortable editing them myself since it requires introducing new pseudo AST nodes

@ehuss
Copy link
Contributor

ehuss commented Jan 30, 2022

Sorry, I'm not sure I understand your comment. The Expression rule begins with OuterAttribute, with a marker to that section that specifies exactly where attributes are allowed. Thus something like CallParams doesn't need to specify OuterAttribute because it is part of Expression.

@pushkine
Copy link
Contributor Author

pushkine commented Jan 30, 2022

From what I understand Expressions cannot have attributes on their own, it's only their position as the child of another specific node that grants them that ability

I think it is very confusing to put a blanket OuterAttribute* (...) around the syntax definition of all expressions with only a foot note listing the AST context that allows it to happen, I'd expect that information to be in the definition of each of those parents instead

@ehuss
Copy link
Contributor

ehuss commented Jan 31, 2022

Ah, yea, I can understand that it can be confusing. The grammar in the reference defines the AST, which is essentially the parsed structure before certain validations are done. The reason it is done this way is primarily for macros, which work with AST fragments. For example, the following is valid:

macro_rules! expr {
    ($e:expr) => {};
}

fn main() {
    // Attributes are valid before any expression for `expr`.
    expr!(#[some_attr]1 + #[some_attr]2);
    expr!([
        #[some_attr]1,
        #[some_attr]2,
        #[some_attr]3,
    ]);
}

In this situation, attribute validation is done in a later phase.

ehuss added a commit to ehuss/rust that referenced this pull request Feb 1, 2022
Update books

## nomicon

4 commits in 66d097d3d80e8f88c288c6879c7c2b909ecf8ad4..9493715a6280a1f74be759c7e1ef9999b5d13e6f
2022-01-05 05:45:21 +0900 to 2022-01-27 19:00:32 -0800
- send-and-sync: it's -> its (rust-lang/nomicon#332)
- Clarify the HRTB chapter (rust-lang/nomicon#330)
- Clarify repr(transparent) in other-reprs (rust-lang/nomicon#329)
- Make C code more recognizably C (rust-lang/nomicon#331)

## reference

10 commits in 4dee6eb63d728ffb9e7a2ed443e9ada9275c69d2..411c2f0d5cebf48453ae2d136ad0c5e611d39aec
2022-01-18 09:26:33 -0800 to 2022-01-30 12:46:37 -0800
- paths.md: update comments of `Canoical paths` section (rust-lang/reference#1146)
- Add undocumented outer attributes above StructExpr fields (rust-lang/reference#1150)
-  (rust-lang/reference#1148)
- Fix micro typo in async/unsafe function docs (rust-lang/reference#1145)
- Note difference in CTFE timing between associated and free constants (rust-lang/reference#1120)
- Update the Preludes chapter for the 2021 edition changes to the standard library prelude (rust-lang/reference#1136)
- Link to associated constants section rather than glossary (rust-lang/reference#1141)
- functions.md: replace `argument` with `parameter` (rust-lang/reference#1142)
- Improve rendering (rust-lang/reference#1143)
- (minor) link references and replace wording by syntax definition (rust-lang/reference#1139)

## book

24 commits in f17df27fc14696912c48b8b7a7a8fa49e648088d..98904efaa4fc968db8ff59cf2744d9f7ed158166
2022-01-18 17:46:28 -0500 to 2022-01-29 21:22:31 -0500
- Snapshot of chapter 17 for nostarch
- Remove the section on object safety.
- Don't put a hyphen in 'object safe'. Fixes rust-lang/book#2960.
- Clarify that add_text on Post will work in any state. Fixes rust-lang/book#2159.
- Fix incorrect descriptions of what the code is doing. Fixes rust-lang/book#2745.
- Fix link style and inclusion in print
- Snapshot of ch16 for nostarch
- Cut discussion of threading models Rust *doesn't* support.
- Update a quote of compiler output
- Move transfers between threads, not shares. Fixes rust-lang/book#2843.
- Ch20-02 Remove reference to a long-gone "trick"
- Clarify translations a bit
- Added a mention to the translations appendix
- Fix listing number from `8-5` to `9-5` in `ch09-02`
- Moving example into blockquote means it can't be extracted to a listing project
- Move a link to the end with all the other links
- Propagate edits back to ch 9
- Responding to edits in chapter 9
- Update to 1.58
- Snapshot of chapter 15 for nostarch
- Change 'only difference' to 'main difference'. Fixes rust-lang/book#1581.
- Add a back reference to tuple struct syntax. Fixes rust-lang/book#1916
- Add a link to a section reference
- Remove an outdated example that says it won't compile but it does

## rustc-dev-guide

2 commits in 78dd6a4..8763adb
2022-01-18 14:44:26 -0300 to 2022-01-26 14:01:40 -0800
- git.md: Expanded a note to try to stress what you need to do if you're playing
- Clarify that r? works in comments.

## embedded-book

1 commits in 8c395bdd8073deb20ca67e1ed4b14a3a7e315a37..d5fc1bce3f8eb398f9c25f1b15e0257d7537cd41
2021-11-14 11:38:31 +0000 to 2022-01-24 07:13:31 +0000
- Add link to Japanese translation  (rust-embedded/book#311)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants