rust/src/tools/rust-analyzer/crates/parser/test_data, branch perf-tmphttps://github.com/rust-lang/rust
http://git.dreamy.place/mirrors/rust/atom?h=perf-tmp2025-08-14T17:30:29+00:00feat: hint at unterminated strings in unknown prefix errors2025-08-14T17:30:29+00:00Ralf Anton Beierralf_beier@me.com2025-08-11T04:16:34+00:00urn:sha1:58ec13d79389f3886e71d43a0fcf501b84c1a40f
When encountering 'unknown literal prefix' errors, check for unbalanced
quotes in recent code and suggest checking for unterminated string literals.
Merge Trait and TraitAlias handling2025-08-13T07:28:08+00:00Deadbeefent3rm4n@gmail.com2025-08-04T08:11:51+00:00urn:sha1:8d247472e5f9612b4bf9668de937ad9c373b891cparser: fix parsing of trait bound polarity and for-binders2025-08-10T06:21:11+00:00Nathaniel McCallumnathaniel@mccallum.life2025-08-10T05:38:17+00:00urn:sha1:6b8a812aafaad6b0edd04d12569fe43ee1e69eed
The rustc AST allows both `for<>` binders and `?` polarity
modifiers in trait bounds, but they are parsed in a specific
order and validated for correctness:
1. `for<>` binder is parsed first.
2. Polarity modifiers (`?`, `!`) are parsed second.
3. The parser validates that binders and polarity modifiers
do not conflict:
```rust
if let Some(binder_span) = binder_span {
match modifiers.polarity {
BoundPolarity::Maybe(polarity_span) => {
// Error: "for<...> binder not allowed with ? polarity"
}
}
}
```
This implies:
- `for<> ?Sized` → Valid syntax. Invalid semantics.
- `?for<> Sized` → Invalid syntax.
However, rust-analyzer incorrectly had special-case logic that
allowed `?for<>` as valid syntax. This fix removes that incorrect
special case, making rust-analyzer reject `?for<> Sized` as a
syntax error, matching rustc behavior.
This has caused confusion in other crates (such as syn) which
rely on these files to implement correct syntax evaluation.
Parse `for<'a> [const]`2025-07-22T13:24:42+00:00Chayim Refael Friedmanchayimfr@gmail.com2025-07-22T13:24:42+00:00urn:sha1:2bd169fcc7c47c324fc4a1b3dd42bc7a2ab45b0a
And also refactor parsing of HRTB.
Make `global_asm!()` work2025-07-09T15:55:27+00:00Chayim Refael Friedmanchayimfr@gmail.com2025-07-09T15:55:27+00:00urn:sha1:90653b0f5cbe567cee2489c0b71ce4ddd26c8f71
Because apparently, we were not accepting inline asm in item position, completely breaking it.
Differentiate between `asm!()`, `global_asm!()` and `naked_asm!()`, and make only `asm!()` unsafe2025-07-09T14:37:27+00:00Chayim Refael Friedmanchayimfr@gmail.com2025-07-09T14:37:27+00:00urn:sha1:ebdd8598d4b08bc11436c5f3d4b1e338d5131a1cParse new const trait syntax2025-06-26T09:08:30+00:00Lukas Wirthme@lukaswirth.dev2025-06-26T09:08:30+00:00urn:sha1:c190510d8c56e16ffaeff54674ed057859883a9bBetter parser recovery for macro calls in type bound position2025-06-05T14:11:30+00:00Lukas Wirthme@lukaswirth.dev2025-06-05T14:11:30+00:00urn:sha1:1de497207d02c4f66a71c4a16fa94e061e404280Give path segment type anchors their own grammar rule2025-06-04T09:40:05+00:00Lukas Wirthme@lukaswirth.dev2025-06-04T09:30:43+00:00urn:sha1:25cef03fdfe7b1943ca1b992954d3c32accc7769Update expected test output2025-05-30T21:16:38+00:00Arthur Baarsaibaars@github.com2025-05-30T21:16:38+00:00urn:sha1:ca4811241caa91a5a9da62b4bddb9be937b3b8f5