| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Use token description in "expected/found" parse messages
Fix #54309.
|
|
|
|
|
|
|
|
|
|
Fix ordering of nested modules in non-mod.rs mods
Flatten relative offset into directory path before adding inline
(mod x { ... }) module names to the current directory path.
Fix #55094
|
|
Primarily refactoring `(Ident, Option<NodeId>)` to `Segment`
|
|
|
|
|
|
Flatten relative offset into directory path before adding inline
(mod x { ... }) module names to the current directory path.
Fix #55094
|
|
Issue: 54912
|
|
Remove incorrect span for second label inner macro invocation
A fix for issue #54841
|
|
r=nikomatsakis
Fix #54707 - parse_trait_item_ now handles interpolated blocks as function body decls
Fix #54707 - parse_trait_item_ now handles interpolated blocks as function body decls
Previously parsing trait items only handled opening brace token and semicolon, I added a branch to the match statement that will also handle interpolated blocks.
|
|
Fixes #47311.
r? @nrc
|
|
Fixes #47311.
r? @nrc
|
|
|
|
|
|
Issue: 54379
|
|
Does not implement the warning or a feature flag.
|
|
make `Parser::parse_foreign_item()` return a foreign item or error
Fixes `Parser::parse_foreign_item()` to follow the convention of `parse_trait_item()` and `parse_impl_item()` in that it *must* parse an item or return an error, and then the caller is responsible for detecting the closing delimiter.
This prevents it from looping endlessly on an unexpected token in `ext/expand.rs` where it was also leaking memory by continually pushing to `Parser::expected_tokens` via `Parser::check_keyword()`.
closes #54441
r? @petrochenkov
cc @dtolnay
|
|
Fixes #54065.
|
|
closes #54441
|
|
Track whether module declarations are inline (fixes #12590)
To track whether module declarations are inline I added a field `inline: bool` to `ast::Mod`. The main use case is for pretty to know whether it should render the items associated with the module, but perhaps there are use cases for this information to not be forgotten in the AST.
|
|
Fixes the off-by-one span issue where closure argument spans were
pointing to the token after the argument.
|
|
parser: Tweak function parameter parsing to avoid rollback on succesfull path
Since rollback is not perfect and may e.g. leave non-fatal errors after it, we need to make sure compilation fails if it happens.
So in particular case of `fn parse_arg_general` we need to parse the "good" `TYPE` first and only then rollback and recover erroneous `PAT: TYPE` if necessary.
Found when working on https://github.com/rust-lang/rfcs/pull/2544#issuecomment-423293222.
r? @ghost
|
|
Detect `for _ in in bar {}` typo
Fix #36611, #52964, without modifying the parsing of emplacement `in` to avoid further problems like #50832.
|
|
Make `dyn` a keyword in the 2018 edition
Proposed in https://github.com/rust-lang/rust/issues/44662#issuecomment-421596088.
|
|
|
|
|
|
|
|
Also fix some formatting along the way.
|
|
|
|
Use Applicability::Unspecified for all of them instead.
|
|
|
|
Advised by @estebank.
|
|
Closes #54109.
|
|
|
|
|
|
proc_macro::Group::span_open and span_close
Before this addition, every delimited group like `(`...`)` `[`...`]` `{`...`}` has only a single Span that covers the full source location from opening delimiter to closing delimiter. This makes it impossible for a procedural macro to trigger an error pointing to just the opening or closing delimiter. The Rust compiler does not seem to have the same limitation:
```rust
mod m {
type T =
}
```
```console
error: expected type, found `}`
--> src/main.rs:3:1
|
3 | }
| ^
```
On that same input, a procedural macro would be forced to trigger the error on the last token inside the block, on the entire block, or on the next token after the block, none of which is really what you want for an error like above.
This commit adds `group.span_open()` and `group.span_close()` which access the Span associated with just the opening delimiter and just the closing delimiter of the group. Relevant to Syn as we implement real error messages for when parsing fails in a procedural macro: https://github.com/dtolnay/syn/issues/476.
```diff
impl Group {
fn span(&self) -> Span;
+ fn span_open(&self) -> Span;
+ fn span_close(&self) -> Span;
}
```
Fixes #48187
r? @alexcrichton
|
|
|
|
|
|
|
|
refactor match guard
This is the first step to implement RFC 2294: if-let-guard. Tracking issue: https://github.com/rust-lang/rust/issues/51114
The second step should be introducing another variant `IfLet` in the Guard enum. I separated them into 2 PRs for the convenience of reviewers.
r? @petrochenkov
|
|
set applicability
Update a few more calls as described in #50723
r? @estebank
|
|
|
|
|
|
|
|
|
|
use String::new() instead of String::from(""), "".to_string(), "".to_owned() or "".into()
|
|
Implement try block expressions
I noticed that `try` wasn't a keyword yet in Rust 2018, so...
~~Fixes https://github.com/rust-lang/rust/issues/52604~~ That was fixed by PR https://github.com/rust-lang/rust/pull/53135
cc https://github.com/rust-lang/rust/issues/31436 https://github.com/rust-lang/rust/issues/50412
|
