| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Improve diagnostics when parsing angle args
https://github.com/rust-lang/rust/pull/79266 introduced parsing of generic arguments in associated type constraints, this however resulted in possibly very confusing error messages in cases in which closing angle brackets were missing such as in `Vec<(u32, _, _) = vec![]`, which outputs an incorrectly parsed equality constraint error, as noted by `@cynecx.`
This PR tries to provide better error messages in such cases.
r? `@petrochenkov`
|
|
Refactor token collection to capture trailing token immediately
Split out from https://github.com/rust-lang/rust/pull/80689 - when we start capturing more information about attribute targets, we'll need to know in advance if we're capturing a trailing token or not.
r? `@ghost`
|
|
|
|
When encountering the following typo:
```rust
a: loop { break 'a; }
```
provide an appropriate suggestion.
|
|
|
|
Fixes #81007
Previously, we would fail to collect tokens in the proper place when
only builtin attributes were present. As a result, we would end up with
attribute tokens in the collected `TokenStream`, leading to duplication
when we attempted to prepend the attributes from the AST node.
We now explicitly track when token collection must be performed due to
nomterminal parsing.
|
|
Use Option::map_or instead of `.map(..).unwrap_or(..)`
``@rustbot`` modify labels +C-cleanup +T-compiler
|
|
Set tokens on AST node in `collect_tokens`
A new `HasTokens` trait is introduced, which is used to move logic from
the callers of `collect_tokens` into the body of `collect_tokens`.
In addition to reducing duplication, this paves the way for PR #80689,
which needs to perform additional logic during token collection.
|
|
|
|
A new `HasTokens` trait is introduced, which is used to move logic from
the callers of `collect_tokens` into the body of `collect_tokens`.
In addition to reducing duplication, this paves the way for PR #80689,
which needs to perform additional logic during token collection.
|
|
Rework diagnostics for wrong number of generic args (fixes #66228 and #71924)
This PR reworks the `wrong number of {} arguments` message, so that it provides more details and contextual hints.
|
|
Suggest async {} for async || {}
Fixes #76011
This adds support for adding help diagnostics to the feature gating checks and
then uses it for the async_closure gate to add the extra bit of help
information as described in the issue.
|
|
|
|
ast: Remove some indirection layers from values in key-value attributes
Trying to address some perf regressions from https://github.com/rust-lang/rust/pull/78837#issuecomment-745380762.
|
|
|
|
We will never need to pop past our starting frame during token
capturing. Using an empty stack allows us to avoid pointless heap
allocations/deallocations.
|
|
|
|
This is important to not accidentally stabilize the parsing of the syntax while it still is experimental and not formally accepted
|
|
- Adds optional default values to const generic parameters in the AST
and HIR
- Parses these optional default values
- Adds a `const_generics_defaults` feature gate
|
|
|
|
|
|
Implement edition-based macro :pat feature
This PR does two things:
1. Fixes the perf regression from https://github.com/rust-lang/rust/pull/80100#issuecomment-750893149
2. Implements `:pat2018` and `:pat2021` matchers, as described by `@joshtriplett` in https://github.com/rust-lang/rust/issues/54883#issuecomment-745509090 behind the feature gate `edition_macro_pat`.
r? `@petrochenkov`
cc `@Mark-Simulacrum`
|
|
Rename kw::Invalid -> kw::Empty
See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Is.20there.20a.20symbol.20for.20the.20empty.20string.3F/near/220054471
for context.
r? `@petrochenkov`
|
|
|
|
See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Is.20there.20a.20symbol.20for.20the.20empty.20string.3F/near/220054471
for context.
|
|
|
|
use matches!() macro in more places
|
|
|
|
Implemented a compiler diagnostic for move async mistake
Fixes #79694
First time contributing, so I hope I'm doing everything right.
(If not, please correct me!)
This code performs a check when a move capture clause is parsed. The check is to detect if the user has reversed the async move keywords and to provide a diagnostic with a suggestion to fix it.
Checked code:
```rust
fn main() {
move async { };
}
```
Previous output:
```txt
PS C:\Repos\move_async_test> cargo build
Compiling move_async_test v0.1.0 (C:\Repos\move_async_test)
error: expected one of `|` or `||`, found keyword `async`
--> src\main.rs:2:10
|
2 | move async { };
| ^^^^^ expected one of `|` or `||`
error: aborting due to previous error
error: could not compile `move_async_test`
```
New output:
```txt
PS C:\Repos\move_async_test> cargo +dev build
Compiling move_async_test v0.1.0 (C:\Repos\move_async_test)
error: the order of `move` and `async` is incorrect
--> src\main.rs:2:13
|
2 | let _ = move async { };
| ^^^^^^^^^^
|
help: try switching the order
|
2 | let _ = async move { };
| ^^^^^^^^^^
error: aborting due to previous error
error: could not compile `move_async_test`
```
Is there a file/module where these kind of things are tested?
Would love some feedback 😄
|
|
|
|
Ran the tidy check
Following the diagnostic guide better
Diagnostic generation is now relegated to its own function in the diagnostics module.
Added tests
Fixed the ui test
|
|
|
|
Gracefully handle mistyping -> as => in function return type
Fixes #77019
|
|
Thanks to Vadim Petrochenkov who [told me what the fix was][z]!
[z]: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/finding.20which.20macro.20rule.20to.20use/near/220240422
|
|
|
|
Properly capture trailing 'unglued' token
If we try to capture the `Vec<u8>` in `Option<Vec<u8>>`, we'll
need to capture a `>` token which was 'unglued' from a `>>` token.
The processing of unglueing a token for parsing purposes bypasses the
usual capturing infrastructure, so we currently lose the trailing `>`.
As a result, we fall back to the reparsed `TokenStream`, causing us to
lose spans.
This commit makes token capturing keep track of a trailing 'unglued'
token. Note that we don't need to care about unglueing except at the end
of the captured tokens - if we capture both the first and second unglued
tokens, then we'll end up capturing the full 'glued' token, which
already works correctly.
|
|
Recover on `const impl<> X for Y`
`@leonardo-m` mentioned that `const impl Foo for Bar` could be recovered from in #79287.
I'm not sure about the error strings as they are, I think it should probably be something like the error that `expected_one_of_not_found` makes + the suggestion to flip the keywords, but I'm not sure how exactly to do that. Also, I decided not to try to handle `const unsafe impl` or `unsafe const impl` cause I figured that `unsafe impl const` would be pretty rare anyway (if it's even valid?), and it wouldn't be worth making the code more messy.
|
|
If we try to capture the `Vec<u8>` in `Option<Vec<u8>>`, we'll
need to capture a `>` token which was 'unglued' from a `>>` token.
The processing of unglueing a token for parsing purposes bypasses the
usual capturing infrastructure, so we currently lose the trailing `>`.
As a result, we fall back to the reparsed `TokenStream`, causing us to
lose spans.
This commit makes token capturing keep track of a trailing 'unglued'
token. Note that we don't need to care about unglueing except at the end
of the captured tokens - if we capture both the first and second unglued
tokens, then we'll end up capturing the full 'glued' token, which
already works correctly.
|
|
|
|
|
|
|
|
|
|
Fixes #79357 unstable or-pat suggestions
Fixes #79357
|
|
|
|
Update error to reflect that integer literals can have float suffixes
For example, `1` is parsed as an integer literal, but it can be turned
into a float with the suffix `f32`. Now the error calls them "numeric
literals" and notes that you can add a float suffix since they can be
either integers or floats.
|
|
|
|
rustc_parse: fix ConstBlock expr span
The span for a ConstBlock expression should presumably run through the end of the block it contains and not stop at the keyword, just like is done with similar block-containing expression kinds, such as a TryBlock
|
|
Properly handle attributes on statements
We now collect tokens for the underlying node wrapped by `StmtKind`
nstead of storing tokens directly in `Stmt`.
`LazyTokenStream` now supports capturing a trailing semicolon after it
is initially constructed. This allows us to avoid refactoring statement
parsing to wrap the parsing of the semicolon in `parse_tokens`.
Attributes on item statements
(e.g. `fn foo() { #[bar] struct MyStruct; }`) are now treated as
item attributes, not statement attributes, which is consistent with how
we handle attributes on other kinds of statements. The feature-gating
code is adjusted so that proc-macro attributes are still allowed on item
statements on stable.
Two built-in macros (`#[global_allocator]` and `#[test]`) needed to be
adjusted to support being passed `Annotatable::Stmt`.
|
