about summary refs log tree commit diff
path: root/compiler/rustc_plugin_impl/src/errors.rs
diff options
context:
space:
mode:
authorDylan DPC <99973273+Dylan-DPC@users.noreply.github.com>2022-10-22 16:28:08 +0530
committerGitHub <noreply@github.com>2022-10-22 16:28:08 +0530
commitada50112ba6fab327b8e55483343ac00a16369a5 (patch)
treeba1e8b155230bd22f6f19130e8ce03e18d338f41 /compiler/rustc_plugin_impl/src/errors.rs
parent988153cc2662eae41a6f779484ec65f0edba3716 (diff)
parent3d7b1f0d18a4bdb667c6244b1748136c312cc9cf (diff)
downloadrust-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