Gate if-let guard feature

[tesuji]

Enhanced on #74315. That PR is in crater queue so I don't want to push to it.

Close #74232
cc #51114

[estebank]

tidy error: Found 1 features without a gate test.
Expected a gate test for the feature 'if_let_guard'.
Hint: create a failing test file named 'feature-gate-if_let_guard.rs'
      in the 'ui' test suite, with its failures due to
      missing usage of `#![feature(if_let_guard)]`.
Hint: If you already have such a test and don't want to rename it,
      you can also add a // gate-test-if_let_guard line to the test file.

[estebank]

LGTM, letting @eddyb have final r+.

[tesuji]

Crater result in #74315 : #74315 (comment)

There are real regressions here.

This snippet now fails to compile when previously accepted:

#[derive(PartialEq)]
struct Foo {
    a: i32,
    b: f32,
}

let f = Foo { a: 42, b: 0.0 };
match () {
    () if f == Foo { a: 0, b: 0.0 } => {}
    //~^ ERROR: struct literals are not allowed here
    _ => {}
}

But note that the if expression has the same restrictions without this PR:

if f == Foo { a: 0, b: 0.0 } {
//~^ ERROR: struct literals are not allowed here
}

error: struct literals are not allowed here
  --> src/lib.rs:14:13
   |
14 |     if f == Foo { a: 0, b: 0.0 } {
   |             ^^^^^^^^^^^^^^^^^^^^
   |
help: surround the struct literal with parentheses
   |
14 |     if f == (Foo { a: 0, b: 0.0 }) {
   |             ^                    ^

error: aborting due to previous error

I guess we have to accept this fate and fallback to previous parse_expr.

[tesuji]

Updated.

[estebank]

I guess we have to accept this fate and fallback to previous parse_expr.

Shame. We could maybe change that in 2021?

[tesuji]

There are 12 regressed crates out of 113052 crates tested.

Spurious:

• 2 is linker error:

  • artichoke/artichoke/1bd7af559015500752ae84f90df715cfbb8f6a09
  • tracing-attributes-0.1.9

• Network error:

  • corysabol.HyperFlo.cb68cc080eacf87a0f0737ece7c195dae1dd98ce
  • divy-work.deno-notify.f82302fc180ea17665d6b47b8de6666bab0aeb0b

Real regressions:

• librsvg: https://github.com/GNOME/librsvg/blob/85552f0ad25247f76a2f220b70078634c3d74dcf/rsvg_internals/src/xml.rs#L400-L407
  • oberien.pundoc.92313227dda7813cd9dc52cc86638793f83a56af
  • antoyo.buzzle.f3c98f8e00c9cf62ac6930e280dd498c7edcc8d0
  • antoyo.bview.6bedeeb50460e94ef5ebcef93a105c682984a956
• SuperTails.langcraft.36f631f8f0fc5686719a797de7003fead02971fd: already fixed upstream ?
• iameva.boardbots-rust.086843d02661324e3a7143b71bc0a0ba0160de4d: easy to fix
• museun.rcc.8d53bc74192718a2c9dddf1ad8648da5eb7f5a91: easy to fix
• async-tftp-0.2.0: easy to fix
• finchers-0.13.5: repository archived; easy to fix

---

There are breakages when disallowing struct literals in match guard.
The breakages is small and easy to fix
(I will fix them upstream if we agree on this move).
But disallowing struct literals on match guard
match restrictions on if condition and makes error reporting/parsing easier.

[tesuji]

This is Underspecified language semantics.

On reference, match arm guard is if expression, but if expr doesn't allow struct expression.

Can I nominate this issue for T-lang or T-compiler?
Join the discussion on Zulip: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Underspecified.20language.20semantics.20of.20match.20arm.20guard

[alercah]

The reason unwrapped struct expressions aren't allowed in if is due to ambiguity of {. There's no such ambiguity in a guard.

[tesuji]

The reason unwrapped struct expressions aren't allowed in if is due to ambiguity of {. There's no such ambiguity in a guard.

Yes, I agree there are no ambiguity in the correct code.
But with the incorrect code, parser has to recover and point out erroring span.
Let's take a look at this file to see the diagnostic: https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/issue-15980.rs
It is not bad but not good either.

[jyn514]

This doesn't seem like something that should be changed in a PR - this is a breaking change to the language itself. Can we try to improve the diagnostic instead?

[tesuji]

I don't change that in this PR. I will open a new issue for discussing it.

[tesuji]

Can we merge this PR, @eddyb ? This PR in current state doesn't break old code.

[jyn514]

You may want to find a different reviewer, I know that eddyb is very behind on github notifications 😅

[tesuji]

Thanks. I don't know what appropriate reviewers. I would wait a few days before finding another one.

[eddyb]

This seems to be a parsing change, so:
r? @petrochenkov

[petrochenkov]

@bors r+

[bors]

📌 Commit ef50477 has been approved by petrochenkov

[bors]

⌛ Testing commit ef50477 with merge 5528caf...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: petrochenkov
Pushing 5528caf to master...

[rust-log-analyzer]

Your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

##[section]Starting: Request a runner to run this job
Found online and idle self-hosted runner in current repository that matches the required labels: 'self-hosted , ARM64 , linux'

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @rust-lang/infra. (Feature Requests)