| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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
|
|
or "".into()
|
|
Remove super old comment on function that parses items
This comment was added more than 5 years ago in ab03c1e4221. As far as anyone reading this comment today needs to know, the function has never parsed items from inside an extern crate.
|
|
Point at the trait argument when using unboxed closure
Fix #53534.
r? @varkor
|
|
This comment was added more than 5 years ago in ab03c1e4221. As far as
anyone reading this comment today needs to know, the function has never
parsed items from inside an extern crate.
|
|
Fix typos found by codespell.
|
|
|
|
|
|
|
|
|
|
(Not `Try` since `QuestionMark` is using that.)
|
|
|
|
|
|
|
|
|
|
|
|
Addressed #51602
Fixed #51602
r? @estebank
here I have addressed the case where `in` was not expected right after `if` block. Speaking of `type ascription` I am not sure if this the best approach which I have implemented. Plus I think one more test case can be added to test `type-ascription` case, though I don't have any at this point of time. I will ping you again if all existing testcases pass.
|
|
|
|
|
|
|
