mir_build: consider privacy when checking for irrefutable patterns #138001
Conversation
|
rustbot has assigned @compiler-errors. Use |
rustbot
added
S-waiting-on-review
|
Some changes occurred in exhaustiveness checking cc @Nadrieril Some changes occurred in src/tools/clippy cc @rust-lang/clippy Some changes occurred in match lowering cc @Nadrieril |
This comment has been minimized.
This comment has been minimized.
meithecatte
force-pushed
the
privately-uninhabited
branch
from
a75dd17 to
a4b5051
Compare
|
@bors try |
…=<try> mir_build: consider privacy when checking for irrefutable patterns This PR fixes rust-lang#137999. Note that, since this makes the compiler reject code that was previously accepted, it will probably need a crater run. I include a commit that factors out a common code pattern into a helper function, purely because the fact that this was repeated all over the place was bothering me. Let me know if I should split that into a separate PR instead.
| .inhabited_predicate(cx.tcx, adt_def) | ||
| .instantiate(cx.tcx, args) | ||
| .apply_ignore_module(cx.tcx, cx.infcx.typing_env(cx.param_env)) | ||
| || !v.inhabited_predicate(cx.tcx, adt_def).instantiate(cx.tcx, args).apply( |
|
☀️ Try build successful - checks-actions |
|
@craterbot check |
compiler-errors
added
S-waiting-on-crater
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
The crater run appears to be running extremely slow. The estimated end is up to 534 hours (22 days) and still increasing. Recent runs took 1-2 days. Edit: a check crater run 4 days ago took ~18 hours, this crater run is at 3% 15 hours in. |
|
@rust-timer build 5785402 (perf.rlo handles timeouts on benchmarks, it should be thus fine to check if this PR causes slowdowns) |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (5785402): comparison URL. Overall result: no relevant changes - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (secondary -2.8%)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.
CyclesResults (secondary -6.4%)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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: missing data |
|
As it doesn't appear to be a perf problem of the PR maybe its related to rust-lang/rustwide#94 and rustup 1.28 breaking rustwide also affects crater. Tough I would have expected a speedup in the crater run, as I would expect everything to fail immediately, rather than a slow down. |
|
The Crater Agent has apparently lost contact since ~2 hours ago |
|
@craterbot cancel |
|
🗑️ Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-review
|
Let's try again 🙏 otherwise I'll open a T-infra thread to investigate. @craterbot check |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
removed
the
S-waiting-on-review
craterbot
added
the
S-waiting-on-crater
|
The crater run is not starting. The agent is still unreachable. |
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🎉 Experiment
|
craterbot
added
S-waiting-on-review
|
I might be misreading this, but it seems like there's a bunch of spurious errors, and no legitimate failures. |
|
No regressions, yup |
|
I'm inclined to treat this as a bugfix. This probably wouldn't have been committed if we knew the consequence. |
A check for `#[non_exhaustive]` is often done in combination with checking whether the type is local to the crate, in a variety of ways. Create a helper method and standardize on it as the way to check for this.
meithecatte
force-pushed
the
privately-uninhabited
branch
from
a4b5051 to
044deec
Compare
|
I rebased the PR onto latest master and resolved the merge conflicts. |
|
r? nadrieril for a final review, though looks fine to me |
|
Looks good, agreed that it qualifies as bugfix. @bors r+ |
bors
added
S-waiting-on-bors
|
Disabling rollup to make it easier to find by bisection, just in case. @bors rollup=never |
|
cargo bisect-rustc handles rollups totally fine, and i don't expect this to have any fallout, so let's compromise and mark it as rollup=maybe :) @bors rollup=maybe |
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#135394 (`MaybeUninit` inherent slice methods part 2) - rust-lang#137051 (Implement default methods for `io::Empty` and `io::Sink`) - rust-lang#138001 (mir_build: consider privacy when checking for irrefutable patterns) - rust-lang#138540 (core/slice: Mark some `split_off` variants unstably const) - rust-lang#138589 (If a label is placed on the block of a loop instead of the header, suggest moving it to the header.) - rust-lang#138594 (Fix next solver handling of shallow trait impl check) - rust-lang#138613 (Remove E0773 "A builtin-macro was defined more than once.") Failed merges: - rust-lang#138602 (Slim `rustc_parse_format` dependencies down) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#135394 (`MaybeUninit` inherent slice methods part 2) - rust-lang#137051 (Implement default methods for `io::Empty` and `io::Sink`) - rust-lang#138001 (mir_build: consider privacy when checking for irrefutable patterns) - rust-lang#138540 (core/slice: Mark some `split_off` variants unstably const) - rust-lang#138589 (If a label is placed on the block of a loop instead of the header, suggest moving it to the header.) - rust-lang#138594 (Fix next solver handling of shallow trait impl check) - rust-lang#138613 (Remove E0773 "A builtin-macro was defined more than once.") Failed merges: - rust-lang#138602 (Slim `rustc_parse_format` dependencies down) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#138001 - meithecatte:privately-uninhabited, r=Nadrieril mir_build: consider privacy when checking for irrefutable patterns This PR fixes rust-lang#137999. Note that, since this makes the compiler reject code that was previously accepted, it will probably need a crater run. I include a commit that factors out a common code pattern into a helper function, purely because the fact that this was repeated all over the place was bothering me. Let me know if I should split that into a separate PR instead.
This PR fixes #137999.
Note that, since this makes the compiler reject code that was previously accepted, it will probably need a crater run.
I include a commit that factors out a common code pattern into a helper function, purely because the fact that this was repeated all over the place was bothering me. Let me know if I should split that into a separate PR instead.