diff options
| author | Dylan DPC <99973273+Dylan-DPC@users.noreply.github.com> | 2022-10-22 16:28:08 +0530 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2022-10-22 16:28:08 +0530 |
| commit | ada50112ba6fab327b8e55483343ac00a16369a5 (patch) | |
| tree | ba1e8b155230bd22f6f19130e8ce03e18d338f41 /compiler/rustc_plugin_impl/src/errors.rs | |
| parent | 988153cc2662eae41a6f779484ec65f0edba3716 (diff) | |
| parent | 3d7b1f0d18a4bdb667c6244b1748136c312cc9cf (diff) | |
| download | rust-ada50112ba6fab327b8e55483343ac00a16369a5.tar.gz rust-ada50112ba6fab327b8e55483343ac00a16369a5.zip | |
Rollup merge of #103224 - compiler-errors:semi-after-closure-in-macro, r=fee1-dead
Allow semicolon after closure within parentheses in macros #88546 added some parsing logic that if we're parsing a closure, and we're within parentheses, and a semicolon follows, then we must be parsing something erroneous like: `f(|| a; b)`, so it replaces the closure body with an error expression. However, it's valid to parse those tokens if we're within a macro, as in #103222. This is a bit unsatisfying fix. Is there a more robust way of checking that we're within a macro? I would also be open to removing this "_It is likely that the closure body is a block but where the braces have been removed_" check altogether at the expense of more verbose errors, since it seems very suspicious in the first place... Fixes #103222.
Diffstat (limited to 'compiler/rustc_plugin_impl/src/errors.rs')
0 files changed, 0 insertions, 0 deletions
