diff options
| author | bors <bors@rust-lang.org> | 2023-07-22 20:37:44 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2023-07-22 20:37:44 +0000 |
| commit | 1d56e3a6d943062e41165bf07fea5ea8324ae011 (patch) | |
| tree | 1eb982f62568061c1d4a5ad774399f031025ab36 /compiler/rustc_parse/src/errors.rs | |
| parent | a6fbd1c58d2247d95aa5efa7b4ac5c846fcd5312 (diff) | |
| parent | 7b962d754350dd7cc8d2729416cb36a7244b3dd0 (diff) | |
| download | rust-1d56e3a6d943062e41165bf07fea5ea8324ae011.tar.gz rust-1d56e3a6d943062e41165bf07fea5ea8324ae011.zip | |
Auto merge of #112953 - compiler-errors:interpolated-block-exprs, r=WaffleLapkin
Support interpolated block for `try` and `async`
I'm putting this up for T-lang discussion, to decide whether or not they feel like this should be supported. This was raised in #112952, which surprised me. There doesn't seem to be a *technical* reason why we don't support this.
### Precedent:
This is supported:
```rust
macro_rules! always {
($block:block) => {
if true $block
}
}
fn main() {
always!({});
}
```
### Counterpoint:
However, for context, this is *not* supported:
```rust
macro_rules! unsafe_block {
($block:block) => {
unsafe $block
}
}
fn main() {
unsafe_block!({});
}
```
If this support for `async` and `try` with interpolated blocks is *not* desirable, then I can convert them to instead the same diagnostic as `unsafe $block` and make this situation a lot less ambiguous.
----
I'll try to write up more before T-lang triage on Tuesday. I couldn't find anything other than #69760 for why something like `unsafe $block` is not supported, and even that PR doesn't have much information.
Fixes #112952
Diffstat (limited to 'compiler/rustc_parse/src/errors.rs')
0 files changed, 0 insertions, 0 deletions
