rust/compiler/rustc_ast/src, branch 1.76.0

Give `VariantData::Struct` named fields, to clairfy `recovered`.

2023-12-20T00:07:34+00:00

Rollup merge of #118880 - GearsDatapacks:issue-118859-fix, r=compiler-errors

2023-12-17T20:29:59+00:00

More expressions correctly are marked to end with curly braces Fixes #118859, and replaces the mentioned match statement with an exhaustive list, so that this code doesn't get overlooked in the future

Auto merge of #118897 - nnethercote:more-unescaping-cleanups, r=fee1-dead

2023-12-16T08:52:06+00:00

More unescaping cleanups More minor improvements I found while working on #118699. r? `@fee1-dead`

Fix enforcement of generics for associated items

2023-12-15T16:17:28+00:00

Change expr_trailing_brace to an exhaustive match to force new expression kinds to specify whether they contain a brace

2023-12-14T18:11:18+00:00

Add inline const and other possible curly brace expressions to expr_trailing_brace Add tests for `}` before `else` in `let...else` error Change to explicit cases for expressions with optional values when being checked for trailing braces Add tests for more complex cases of `}` before `else` in `let..else` statement Move other possible `}` cases into separate arm and add FIXME for future reference

Unify single-char and multi-char `CStrUnit::Char` handling.

2023-12-12T23:06:13+00:00

The two cases are equivalent. C string literals aren't common so there is no performance need here.

Don't rebuild raw strings when unescaping.

2023-12-12T22:26:10+00:00

Raw strings don't have escape sequences, so for them "unescaping" just means checking for invalid chars like bare CR. Which means there is no need to rebuild them one char or byte at a time while escaping, because the unescaped version will be the same. This commit removes that rebuilding. Also, the commit changes things so that "unescaping" is unconditional for raw strings and raw byte strings. That's simpler and they're rare enough that the perf effect is negligible.

Don't gate the feature twice

2023-12-12T13:52:05+00:00

Add spacing information to delimiters.

2023-12-10T22:36:40+00:00

This is an extension of the previous commit. It means the output of something like this: ``` stringify!(let a: Vec = vec![];) ``` goes from this: ``` let a: Vec = vec![] ; ``` With this PR, it now produces this string: ``` let a: Vec = vec![]; ```

Improve `print_tts` by changing `tokenstream::Spacing`.

2023-12-10T22:19:09+00:00

`tokenstream::Spacing` appears on all `TokenTree::Token` instances, both punct and non-punct. Its current usage: - `Joint` means "can join with the next token *and* that token is a punct". - `Alone` means "cannot join with the next token *or* can join with the next token but that token is not a punct". The fact that `Alone` is used for two different cases is awkward. This commit augments `tokenstream::Spacing` with a new variant `JointHidden`, resulting in: - `Joint` means "can join with the next token *and* that token is a punct". - `JointHidden` means "can join with the next token *and* that token is a not a punct". - `Alone` means "cannot join with the next token". This *drastically* improves the output of `print_tts`. For example, this: ``` stringify!(let a: Vec = vec![];) ``` currently produces this string: ``` let a : Vec < u32 > = vec! [] ; ``` With this PR, it now produces this string: ``` let a: Vec = vec![] ; ``` (The space after the `]` is because `TokenTree::Delimited` currently doesn't have spacing information. The subsequent commit fixes this.) The new `print_tts` doesn't replicate original code perfectly. E.g. multiple space characters will be condensed into a single space character. But it's much improved. `print_tts` still produces the old, uglier output for code produced by proc macros. Because we have to translate the generated code from `proc_macro::Spacing` to the more expressive `token::Spacing`, which results in too much `proc_macro::Along` usage and no `proc_macro::JointHidden` usage. So `space_between` still exists and is used by `print_tts` in conjunction with the `Spacing` field. This change will also help with the removal of `Token::Interpolated`. Currently interpolated tokens are pretty-printed nicely via AST pretty printing. `Token::Interpolated` removal will mean they get printed with `print_tts`. Without this change, that would result in much uglier output for code produced by decl macro expansions. With this change, AST pretty printing and `print_tts` produce similar results. The commit also tweaks the comments on `proc_macro::Spacing`. In particular, it refers to "compound tokens" rather than "multi-char operators" because lifetimes aren't operators.