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
Remove super old comment on function that parses items
This comment was added more than 5 years ago in ab03c1e422. As far as anyone reading this comment today needs to know, the function has never parsed items from inside an extern crate.
This comment was added more than 5 years ago in ab03c1e422. As far as
anyone reading this comment today needs to know, the function has never
parsed items from inside an extern crate.
Addressed #51602Fixed#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.
The error and check for this already existed, but the parser didn't try to parse trait method arguments as patterns, so the error was never emitted. This surfaces the error, so we get better errors than simple parse errors.
