More detail when expecting expression but encountering bad macro argument#114292
More detail when expecting expression but encountering bad macro argument#114292bors merged 1 commit intorust-lang:masterfrom
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.
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.
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.
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.
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.
#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.
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.
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.
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.
I'm not sure how familiar users are with the "non-terminal" terminology.
There was a problem hiding this comment.
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.
Copied the wording from the reference, but would like to expand a little bit on the explanation
fee1-dead
left a comment
There was a problem hiding this comment.
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.
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.