Support interpolated block for try and async

[compiler-errors]

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:

macro_rules! always {
  ($block:block) => {
    if true $block
  }
}

fn main() {
    always!({});
}

Counterpoint:

However, for context, this is not supported:

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

[rustbot]

r? @WaffleLapkin

(rustbot has picked a reviewer for you, use r? to override)

[Noratrieb]

Why do we need lookahead here in the first place?

[compiler-errors]

No idea. This could probably be relaxed as long as we make sure not to allow code like async #[attr] {, but that could be done in the code that actually parses the async expr.

[joshtriplett]

We discussed this in today's @rust-lang/lang meeting. We were a little surprised this doesn't already work, and didn't see any reason it shouldn't work.

@rust-lang/lang-advisors, are you aware of any reason that unsafe $block didn't work, historically?

@rfcbot merge
@rfcbot concern wait-for-advisors

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry

Concerns:

• wait-for-advisors resolved by Support interpolated block for try and async #112953 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[scottmcm]

Given the if example works, as does the same thing with else

macro_rules! always {
  ($block:block) => {
    if false {} else $block
  }
}

it seems entirely reasonable to allow this to work.

It makes sense to me that unsafe foo!(), where the macro expands to a block, wouldn't work, but when the whole construct is created by the macro, it seems enough like what's allowed elsewhere.

@rfcbot reviewed

---

For fun, this doesn't work, but that's probably for the best, since it's not an AST block, even though it's lexically "correct":

struct Foo {}

macro_rules! foo {
  ($block:block) => {
    Foo $block
  }
}

fn main() {
    let _x = foo!({});
}

[RalfJung]

If we allow it for try and sync then surely we should also allow it for unsafe? Why does the PR only change try and async, not unsafe?

It is not clear to me whether the FCP includes also allowing this for unsafe or not.

[compiler-errors]

I think this should also work for unsafe, but I'd like that clarified too.

[joshtriplett]

@rfcbot resolve wait-for-advisors

We talked about this in today's lang meeting. We're going to treat this FCP as approving the proposed PR. We'd be happy to see a PR for unsafe as well, and we'll do an FCP on that PR to avoid ambiguity of what's being approved.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[compiler-errors]

In that case, I will put up a PR to fix a bug having to do with const {} interpolated blocks (imo that's just a bug), and then I will look into supporting unsafe {} as well in a different PR, though that one is significantly more involved due to the way that we thread unsafety throughout the parser.

[WaffleLapkin]

Implementation looks good to me, r=me once FCP finishes.

[scottmcm]

(Removed nomination as this went into FCP after the nomination; please re-nominate if there are new questions.)

[bors]

☔ The latest upstream changes (presumably #113865) made this pull request unmergeable. Please resolve the merge conflicts.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[compiler-errors]

@bors r=WaffleLapkin

[bors]

📌 Commit 7b962d7 has been approved by WaffleLapkin

It is now in the queue for this repository.

[bors]

⌛ Testing commit 7b962d7 with merge 1d56e3a...

[bors]

☀️ Test successful - checks-actions
Approved by: WaffleLapkin
Pushing 1d56e3a to master...

[rust-timer]

Finished benchmarking commit (1d56e3a): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This 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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.7%	[-2.7%, -2.7%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.7%	[-2.7%, -2.7%]	1

Cycles

Results

This 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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.2%	[1.2%, 1.2%]	1
Improvements ✅ (primary)	-3.7%	[-3.7%, -3.7%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-3.7%	[-3.7%, -3.7%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 651.047s -> 651.728s (0.10%)