Don't warn empty branches unreachable for now

[Nadrieril]

The stabilization of min_exhaustive_patterns updated the unreachable_pattern lint to trigger on empty arms too. This has caused some amount of churn, and imposes an unjoyful #[allow(unreachable_patterns)] onto library authors who want to stay backwards-compatible.

While I think the lint should eventually cover these cases, for transition's sake I'd prefer to revert linting to what it was prior to stabilization, at least for now.

Fixes #129031.

r? @compiler-errors

[compiler-errors]

Hm... I find it strange to be associating this with an edition, rather than associating it with a new lint and a lint group. I wonder if @traviscross has any thoughts about this.

[kpreid]

As I see it, the logic of associating it with an edition is that people who are doing an edition migration are opting into changing their source code in "syntax cleanup" kinds of ways. It's not necessarily that the lint should be permanently associated only with the edition, but that looking for 2024 edition is a cheap way to identify authors who are opting in now. As time passes (at a minimum, after 1.82 is stable; maximum, after 1.81 is no longer a reasonable MSRV to maintain), it will become less important that only opt-ins get this warning, and it could become edition independent.

[compiler-errors]

Lints can have edition-specific warning levels though -- e.g.

    @edition Edition2024 => Warn;

in the lint definition. I'd still much rather we still split the lint out into two and apply an edition-2024-specific Warn level to it, so that users can opt into this on earlier editions, and we can attach lint-specific wording and documentation to the case where patterns are redundant due to being uninhabited.

[traviscross]

@rustbot labels +T-lang

As described here, I don't think there's going to be lang appetite for this.

[compiler-errors]

@rustbot author

[compiler-errors]

I'd prefer if this were implemented as splitting the lint into two as I've mentioned several times before.

[Nadrieril]

Well, since T-lang doesn't seem to want to mitigate the fallout there's no need to do that either

[bors]

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

[joshtriplett]

Let's see if we have consensus to go ahead with this:

@rfcbot merge

[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
• @traviscross

Concerns:

• split-lint resolved by Don't warn empty branches unreachable for now #129103 (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.

[traviscross]

CE said:

I'd prefer if this were implemented as splitting the lint into two as I've mentioned several times before.

@rfcbot concern split-lint

I'd like to see this change done by making unreachable_patterns into a lint group and then adding an impossible_patterns lint to it that's allow-by-default (and fires in all editions) and then make that lint warn-by-default in Rust 2024. This is closer to what we decided earlier here.

This concern is to confirm that's what we're deciding here, as that's not what this PR implements.

[joshtriplett]

@traviscross My intent was to build a consensus on "the lint should not fire on these cases", without specifying the exact mechanism. No objection to doing that by splitting the lint.

[tmandry]

@rfcbot reviewed

I support splitting the lint, or reverting to its old behavior and reintroducing as a separate lint later. I particularly agree with what @compiler-errors said in #129031 (comment):

I find the unreachable patterns lint to be very high signal towards there being an underlying problem with the code, and impossible patterns to be useful for signaling "hey, this code is dead" but not necessarily at the same severity level as the former, especially because we required users to include these dead arms previously.

Going forward, I would like to separate such cases whenever possible. I think it is tempting to collapse the cases into one because they fit nicely under a succinct description. But the combination of

• aggressive churn (going from enforcing one way to linting against that way) and
• a different risk profile for churned code

is a clear signal to separate them. (cc #122759)

edit: Changing the default from allow to warn on the new lint in edition 2024 seems like a good rollout strategy; we can always move to warn in all editions later.

[Nadrieril]

@bors r=compiler-errors

[bors]

📌 Commit 5b7be14 has been approved by compiler-errors

It is now in the queue for this repository.

[apiraino]

Beta backport accepted as per compiler team on Zulip. A backport PR will be authored by the release team at the end of the current development cycle.

@rustbot label +beta-accepted