proc_macro::Group::span_open and span_close #53902
Conversation
rust-highfive
added
the
S-waiting-on-review
src/libproc_macro/lib.rs
Outdated
| #[stable(feature = "proc_macro_lib2", since = "1.29.0")] | ||
| pub fn span(&self) -> Span { | ||
| self.span | ||
| } | ||
|
|
||
| /// Returns the span pointing to the opening delimiter of this group, or the | ||
| /// span of the entire group if this is a None-delimited group. |
There was a problem hiding this comment.
Hmm, this sounds too specific.
Perhaps more general methods on Span like fn shrink_to_lo/fn shrink_to_hi in the compiler would be more useful?
There was a problem hiding this comment.
(Need to figure out specifics though, zero-character spans are still showed as single-character in errors, but positions may be +/-1 wrong depending on use case.)
There was a problem hiding this comment.
Either way works for me, but in my use case I don't really see this being called other than on the span of a Group. I opened #53904 with methods on Span.
There was a problem hiding this comment.
Some quick review of uses of shrink_to_lo/shrink_to_hi in the compiler:
- Pointing to the private visibility / place to insert visibility (not a group).
- Pointing at elided
()return type in functions (group). - Pointing to the place to insert missing imports (not a group).
- Pointing at the end of fn call to insert
.as_ref()(group). - Pointing at the last missing argument in fn call (group).
- Pointing at elided lifetime in
&Type(not a group). - Pointing at missing lifetime argument at the start of generic argument list (not a group).
- ... (ok, that's enough)
So, there are different possible uses for both groups and non-groups.
|
I'd be fine adding these, but I'd prefer to add them as unstable instead of initially insta-stable. |
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:
mod m {
type T =
}
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.
|
I'm personally comfortable with this as-is, but I think you've got further comments! |
|
Closing in favor of #53930, |
|
Updated to include #53930 (comment). |
src/libsyntax/ext/tt/macro_parser.rs
Outdated
| @@ -154,7 +154,7 @@ struct MatcherPos<'a> { | |||
| /// The beginning position in the source that the beginning of this matcher corresponds to. In | |||
| /// other words, the token in the source at `sp_lo` is matched against the first token of the | |||
| /// matcher. | |||
| sp_lo: BytePos, | |||
| sp_lo: Span, | |||
There was a problem hiding this comment.
This should be renamed to sp_open, I think.
|
📌 Commit 57d6ada has been approved by |
bors
added
S-waiting-on-bors
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: dtolnay/syn#476.
```diff
impl Group {
fn span(&self) -> Span;
+ fn span_open(&self) -> Span;
+ fn span_close(&self) -> Span;
}
```
Fixes #48187
r? @alexcrichton
|
☀️ Test successful - status-appveyor, status-travis |
|
This increased |
|
Thanks @nnethercote, I filed #54535 to follow up. |
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: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()andgroup.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: dtolnay/syn#476.impl Group { fn span(&self) -> Span; + fn span_open(&self) -> Span; + fn span_close(&self) -> Span; }Fixes #48187
r? @alexcrichton