-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make novel structural match violations not a bug
#73446
Conversation
Should the warning text reference some issue for further info? |
c8816fb
to
38e921b
Compare
Done. See #73448. |
706e56f
to
3a1207f
Compare
As discussed in private with @ecstatic-morse , i cannot immediately tell if this represents a hole in the structural-match check that we will need to plug (and thus maybe we should have something stronger than a But it probably isn't worth the effort of putting in the plumbing to issue a proper lint warning here; instead effort should be focused on fixing #73448 itself. and in any case, this PR as it stands fixes the ICE, which trumps all else at the moment. @bors r+ |
📌 Commit 3a1207f has been approved by |
unilaterally accepting for beta-backport. |
giving this priority since it is a |
Make novel structural match violations not a `bug` Fixes (on master) rust-lang#73431. Ideally, `CustomEq` would emit a strict subset of the structural match errors that are found by `search_for_structural_match_violation`, since it allows more cases due to value-based reasoning. However, const qualification is more conservative than `search_for_structural_match_violation` around associated constants, since qualification does not try to substitute type parameters. In the long term, we should probably make const qualification work for generic associated constants, but I don't like extending its capabilities even further. r? @pnkfelix
Make novel structural match violations not a `bug` Fixes (on master) rust-lang#73431. Ideally, `CustomEq` would emit a strict subset of the structural match errors that are found by `search_for_structural_match_violation`, since it allows more cases due to value-based reasoning. However, const qualification is more conservative than `search_for_structural_match_violation` around associated constants, since qualification does not try to substitute type parameters. In the long term, we should probably make const qualification work for generic associated constants, but I don't like extending its capabilities even further. r? @pnkfelix
⌛ Testing commit 3a1207f with merge 205c00429373b16ac70c645031eabc44fe4c8232... |
Yielding to rollup |
⌛ Testing commit 3a1207f with merge 493d2a798de149fba00e07f2fb8f0f25f562b760... |
@bors retry |
⌛ Testing commit 3a1207f with merge b7a9cf51cc76a4992329c385a49862503e968c3e... |
💥 Test timed out |
@bors retry p=5 |
☀️ Test successful - checks-azure |
…ulacrum [beta] backports This PR backports the following: * Make novel structural match violations not a `bug` rust-lang#73446 * linker: Never pass `-no-pie` to non-gnu linkers rust-lang#73384 * Disable the `SimplifyArmIdentity` pass rust-lang#73262 * Allow inference regions when relating consts rust-lang#73225 * Fix link error with #[thread_local] introduced by rust-lang#71192 rust-lang#73065 * Ensure stack when building MIR for matches rust-lang#72941 * Don't create impl candidates when obligation contains errors rust-lang#73005 r? @ghost
Fixes (on master) #73431.
Ideally,
CustomEq
would emit a strict subset of the structural match errors that are found bysearch_for_structural_match_violation
, since it allows more cases due to value-based reasoning. However, const qualification is more conservative thansearch_for_structural_match_violation
around associated constants, since qualification does not try to substitute type parameters.In the long term, we should probably make const qualification work for generic associated constants, but I don't like extending its capabilities even further.
r? @pnkfelix