Syntactically reject tuple index shorthands in struct patterns to fix a correctness regression
Split out of PR rust-lang/rust#154492. This fixes a correctness regression introduced in PR rust-lang/rust#81235 from 2021. Crater was run in my other PR and didn't report any real regressions (https://github.com/rust-lang/rust/pull/154492#issuecomment-4187544786); a rerun has been issued for a few spurious builds (https://github.com/rust-lang/rust/pull/154492#issuecomment-4237077272) but I'm certain it won't find anything either.
This is a theoretical breaking change that doesn't need any T-lang input IMHO since it's such a minute, niche and crystal clear bug that's not worth bothering them with (such a decision is not unprecedented). I'm adding it to the compatibility section of the release notes as is customary.
The Reference doesn't need updating since it didn't adopt this bug and thus accurately describes this part of the grammar as it used to be before 2021-02-23 and as it's meant to be.
The majority of the diff is doc comment additions & necessary UI test restructurings.
Change keyword order for `impl` restrictions
Based on rust-lang/rust#155222, this PR reorders keywords in trait definitions to group restrictions with visibility. It changes the order from `pub(...) const unsafe auto impl(...) trait Foo {...}` to `pub(...) impl(...) const unsafe auto trait Foo {...}`.
Tracking issue for restrictions: rust-lang/rust#105077
r? @Urgau
cc @jhpratt
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#152901 (Introduce a `#[diagnostic::on_unknown]` attribute)
- rust-lang/rust#155078 (Reject dangling attributes in where clauses)
- rust-lang/rust#154449 (Invert dependency between `rustc_errors` and `rustc_abi`.)
- rust-lang/rust#154646 (Add suggestion to `.to_owned()` used on `Cow` when borrowing)
- rust-lang/rust#154993 (compiletest: pass -Zunstable-options for unpretty and no-codegen paths)
- rust-lang/rust#155097 (Make `rustc_attr_parsing::SharedContext::emit_lint` take a `MultiSpan` instead of a `Span`)
Fix ICE when combining #[eii] with #[core::contracts::ensures]
Fixesrust-lang/rust#153745
Builtin attribute macros like #[eii] generate AST items programmatically without collected tokens. When another attribute macro was present on the same item, the compiler would panic in TokenStream::from_ast() trying to tokenize the generated items during subsequent attribute expansion.
Generate fake token streams (via pretty-print and re-parse) for Item and ForeignItem nodes that lack collected tokens, following the existing pattern used for Crate and out-of-line modules.
Use fine grained component-wise span tracking in use trees
This often produces nicer spans and even doesn't need a Span field anymore (not that I expect the unused field to affect any perf, but still neat).
remove unnecessary variables and delimiter check
Zulip discussion: https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/question.20about.20lex_token_tree_open_delim.20in.20rustc_parse/with/580552157
In `lex_token_tree_open_delim`, after calling `self.lex_token_trees(/* is_delimited */ true)`:
- If the delimiters are well-balanced, the value popped from the stack will always equal to `open_delim` and `pre_span`.
- If the delimiters are not balanced, `self.lex_token_trees(/* is_delimited */ true)` will return an error so this branch will not be reached
Therefore `open_delimiter` and `open_delimiter_span` can be removed.
Test `tests/ui/parser` all passed
Emit a pre-expansion feature gate warning for `box`'ed struct field patterns
While the following code triggers a feature gate *warning*:
```rs
fn f() {
#[cfg(false)]
let box x; //~ WARN box pattern syntax is experimental
}
```
the code below does not (on stable & main):
```rs
fn f() {
#[cfg(false)]
let Struct { box x };
}
```
This is an oversight as both are part of the unstable feature `box_patterns` (that isn't properly gated pre expansion for historical reasons). Of course, both forms lead to a feature gate error *post expansion*.
This is a bug fix and doesn't need any input from T-compiler or T-lang. For context, emitting warnings in these cases is legitimized by [MCP 535](https://github.com/rust-lang/compiler-team/issues/535)[^1].
Part of rust-lang/rust#154045.
[^1]: In case you're wondering why the MCP talks about a *lint* even though the feature gate warnings as seen today don't reference any lint by name, read https://github.com/rust-lang/rust/issues/154045#issuecomment-4144034419.
Improve doc comment unicode guidance
Fixesrust-lang/rust#153096
This PR does not suggest HTML bidi markup, because doc comments are still Rust source first, not only rendered rustdoc output. HTML only helps in the rendered documentation rather than making them explicit in source.
Add macro matcher for `guard` fragment specifier
Tracking issue #153104
This PR implements a new `guard` macro matcher to match `if-let` guards (specifically [`MatchArmGuard`](https://github.com/rust-lang/reference/blob/50a1075e879be75aeec436252c84eef0fad489f4/src/expressions/match-expr.md#match-guards)). In the upcoming PR, we can use this new matcher in the `matches!` and `assert_matches!` macros to support their use with `if-let` guards. (see #152313)
The original `Expr` used to represent a guard has been wrapped in a new `Guard` type, allowing us to carry the span information of the leading `if` keyword. However, it might be even better to include the `if` keyword in the `Guard` type as well? I've left a FIXME comment in the code.
Start migrating `DecorateDiagCompat::Builtin` items to `DecorateDiagCompat::Dynamic`
Part of https://github.com/rust-lang/rust/issues/153099.
End goal being to completely remove the two steps currently required by `DecorateDiagCompat::Builtin` and remove duplicated types.
r? @JonathanBrouwer
Builtin attribute macros like #[eii] generate AST items
programmatically without collected tokens. When another attribute macro
was present on the same item, the compiler would panic in
TokenStream::from_ast() trying to tokenize the generated items during
subsequent attribute expansion.
Generate fake token streams (via pretty-print and re-parse) for Item
and ForeignItem nodes that lack collected tokens, following the
existing pattern used for Crate and out-of-line modules.
It's defined in `rustc_span::source_map` which doesn't make any sense
because it has nothing to do with source maps. This commit moves it to
the crate root, a more sensible spot for something this basic.
Parse `impl` restrictions
This PR implements the parsing logic for `impl` restrictions (e.g., `pub impl(crate) trait Foo {}`) as proposed in [RFC 3323](https://rust-lang.github.io/rfcs/3323-restrictions.html).
As the first step of the RFC implementation, this PR focuses strictly on the parsing phase. The new syntax is guarded by the `#![feature(impl_restriction)]` feature gate.
This implementation basically follows the pattern used in rust-lang/rust#141754.
r? @jhpratt
Don’t report missing fields in struct exprs with syntax errors.
@Noratrieb [told me](https://internals.rust-lang.org/t/custom-cargo-command-to-show-only-errors-avoid-setting-rustflags-every-time/24032/7?u=kpreid) that “it is a bug if this recovery causes follow-up errors that would not be there if the user fixed the first error.” So, here’s a contribution to hide a follow-up error that annoyed me recently.
Specifically, if the user writes a struct literal with a syntax error, such as
```rust
StructName { foo: 1 bar: 2 }
```
the compiler will no longer report that the field `bar` is missing in addition to the syntax error.
This is my first time attempting any change to the parser or AST; please let me know if there is a better way to do what I’ve done here. ~~The part I’m least happy with is the blast radius of adding another field to `hir::ExprKind::Struct`, but this seems to be in line with the style of the rest of the code. (If this were my own code, I would consider changing `hir::ExprKind::Struct` to a nested struct, the same way it is in `ast::ExprKind`.)~~ The additional information is now stored as an additional variant of `ast::StructRest` / `hir::StructTailExpr`.
**Note to reviewers:** I recommend reviewing each commit separately, and in the case of the first one with indentation changes ignored.
This adds a variant `NoneWithError` to AST and HIR representations of
the “rest” or “tail”, which is currently always treated identically to
the `None` variant.
Don't allow subdiagnostic to use variables from their parent
Tangentially related to https://github.com/rust-lang/rust/issues/151366
This is PR 1/2 for structured diagnostics, will do the unstructured ones next. After the second PR I will be able to remove some code that should compensate for this PR being positive.
Regardless of this PR having a positive diff, I feel that subdiagnostics being able to use variables from their parent is very confusing, so this is for the better,.
r? @jdonszelmann
Jacob Pratt