-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More detail when expecting expression but encountering bad macro argument #114292
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
r? compiler kinda swamped |
@@ -53,6 53,9 @@ LL | my_recursive_macro!(); | |||
error: expected expression, found `A { a: a, b: 0, c: _, .. }` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we perhaps just say "found pattern A ...
" instead of highlighting a span and having to render out a possibly very long token-stream in an additional note?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed to do that
This comment has been minimized.
This comment has been minimized.
error: expected expression, found `1 1` | ||
--> $DIR/trace_faulty_macros.rs:49:37 | ||
| | ||
LL | (let $p:pat = $e:expr) => {test!(($p,$e))}; | ||
| -- this is interpreted as pattern `1 1` (in expansion #2) | ||
... | ||
LL | (($p:pat, $e:pat)) => {let $p = $e;}; | ||
| ^^ expected expression | ||
... | ||
LL | test!(let x = 1 1); | ||
| ------------------ | ||
| | | | ||
| | this is interpreted as expression `1 1` (in expansion #1) | ||
| in this macro invocation | ||
| | ||
= note: this error originates in the macro `test` (in Nightly builds, run with -Z macro-backtrace for more info) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a lot of words but it still doesn't clearly explain what the issue is here, imo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know, ideally we would actually point at $e:pat
, but without this context it is even harder to understand that the reason 1 1
is understood as a pattern is that there's multiple levels of macro evaluation at play.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#71039 is two problems:
- reinterpreting expr non-terminals as patterns leads to confusing errors with multiple layers of nesting,
- unrelated to nesting, using pattern non-terminals in expr position itself leads to weird errors.
this is an example of (2.), which would be fixed if we were to point at the :pat
kind, and which (afaict) isn't helped by this pr?
macro_rules! m {
($e:pat) => { let x = $e; }
//~^ ERROR expected expression, found `1`
}
fn main() {
m!(1);
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
which (afaict) isn't helped by this pr?
maybe this is a mischaracterization -- the context added by this pr might help a bit, but ideally the only thing we'd need to add a new label for is the :pat
part.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think I figured out a way to add the span for e:pat
as the def_site
context of the span for $e
, but I'll need to talk with petrochenkov to see if that's reasonable. If we had that, it could also be used in a bunch of other errors as well.
| -- this is interpreted as pattern `1 1` (in expansion #2) | ||
... | ||
LL | (($p:pat, $e:pat)) => {let $p = $e;}; | ||
| ^^ expected expression |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specifically, it doesn't explain why 1 1
is interpreted as a pattern -- I think the only thing we need to point out is that the non-terminal kind is pat
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how familiar users are with the "non-terminal" terminology.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be helpful to add a link to https://doc.rust-lang.org/reference/macros-by-example.html#forwarding-a-matched-fragment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copied the wording from the reference, but would like to expand a little bit on the explanation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would also be helpful to have a test where an input ident is first accepted as $x: ident
and then subsequently accepted as an expr then pattern triggering the error. Would be nice to see how the macro backtracking works in that case
| -- this is interpreted as pattern `1 1` (in expansion #2) | ||
... | ||
LL | (($p:pat, $e:pat)) => {let $p = $e;}; | ||
| ^^ expected expression |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be helpful to add a link to https://doc.rust-lang.org/reference/macros-by-example.html#forwarding-a-matched-fragment
cc #115089 r? compiler |
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
More detail when expecting expression but encountering bad macro argument Partially address rust-lang#71039. ``` error: expected expression, found `1 1` --> $DIR/trace_faulty_macros.rs:49:37 | LL | (let $p:pat = $e:expr) => {test!(($p,$e))}; | -- this is interpreted as pattern `1 1` (in expansion #2) ... LL | (($p:pat, $e:pat)) => {let $p = $e;}; | ^^ expected expression ... LL | test!(let x = 1 1); | ------------------ | | | | | this is interpreted as expression `1 1` (in expansion #1) | in this macro invocation | = note: this error originates in the macro `test` (in Nightly builds, run with -Z macro-backtrace for more info) ```
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (06d28f4): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 628.751s -> 627.511s (-0.20%) |
As expected, the tests affected by the larger type are all macro related, in particular tt-muncher (again, unsurprising). I leave it to the reviewer to determine if such a perf impact is worth it for this tracking. An alternative approach would be to create a new span context for macro arguments and inject those in the macro backtrace as the def_span, but the machinery is not set up to do that easily. |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
03fde33
to
a9a0cd9
Compare
This comment was marked as resolved.
This comment was marked as resolved.
…ment Partially address rust-lang#71039.
a9a0cd9
to
4e41880
Compare
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
More detail when expecting expression but encountering bad macro argument Partially address rust-lang#71039. ``` error: expected expression, found pattern `1 1` --> $DIR/trace_faulty_macros.rs:49:37 | LL | (let $p:pat = $e:expr) => {test!(($p,$e))}; | ------- -- this is interpreted as expression, but it is expected to be pattern | | | this macro fragment matcher is expression ... LL | (($p:pat, $e:pat)) => {let $p = $e;}; | ------ ^^ expected expression | | | this macro fragment matcher is pattern ... LL | test!(let x = 1 1); | ------------------ | | | | | this is expected to be expression | in this macro invocation | = note: when forwarding a matched fragment to another macro-by-example, matchers in the second macro will see an opaque AST of the fragment type, not the underlying tokens = note: this error originates in the macro `test` (in Nightly builds, run with -Z macro-backtrace for more info) ```
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (97a26f5): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 676.569s -> 674.073s (-0.37%) |
@b-naber given the current perf results, I would like to merge this PR without further changes 😄 |
Ah, I see that you had already approved earlier, contingent on perf @b-naber. If the current code looks reasonable, I'd like to merge this sooner rather than later, as it is a bit bitrotty. |
@bors r |
☀️ Test successful - checks-actions |
Finished benchmarking commit (2831701): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 675.186s -> 675.761s (0.09%) |
On nested macro invocations where the same macro fragment changes fragment type from one to the next, point at the chain of invocations and at the macro fragment definition place, explaining that the change has occurred.
Fix #71039.