fatal error if both -Znext-solver and GCE are enabled#158738
Conversation
|
r? @mejrs rustbot has assigned @mejrs. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
r? @BoxyUwU |
|
|
|
I don't think we want to complicate the new solver with logic for supporting GCE stuff. In the short term generic_const_args and min_generic_const_args should obviate this feature 🤔 can you instead make the error about new solver and GCE being mutually incompatible be fatal so that compilation just ends rather than trucking on |
|
@rustbot author |
|
Reminder, once the PR becomes ready for a review, use |
027341c to
7645fac
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
@BoxyUwU updated this based on your feedback. the i renamed the regression test from recovery to incompatibility, and changed the const-trait known-bug test to use also rebased on latest ltm if you want anything adjusted. idk if there is a better place for the test, but this felt like the least noisy split to me. @rustbot ready |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
779ef3e to
6e45dd2
Compare
|
@bors r+ rollup |
…expr_recovery, r=BoxyUwU next_trait_solver: Recover from GCE const exprs fixes rust-lang#158428 the next solver already rejects `generic_const_exprs` with `-Znext-solver=globally`, but we can still walk into `ConstKind::Expr` while compiling after that error and crash anyway. imo this should stay as a recovery fix, not a gce implementation. ambiguity still lgtm to me here: idk that we want to say the expr is solved when the feature combo is already invalid, we just need to not ice after the real error. long-term, proper `ConstKind::Expr` support would be a much bigger thing. the next solver would need to type-check, normalize, compare, and evaluate or prove these exprs structurally, including nested binops, unops, casts, calls, and the result type for `ConstArgHasType`. that's out of scope for this pr. this teaches both const evaluatable and const arg has type paths to recover on `ConstKind::Expr`, then adds the union repro as a ui test.
…uwer Rollup of 12 pull requests Successful merges: - #159712 (Subtree sync for rustc_codegen_cranelift) - #155697 (Stabilize c-variadic function definitions) - #159285 (Simplify `apply_effects_in_range`) - #159596 (unify the AST repr of type const and const RHS) - #159607 (test: update riscv32e-registers.rs for LLVM 24 MC diagnostic changes) - #159659 (Move `Limit` out of `rustc_hir`) - #159707 (fix error when a dangling ref in a ManuallyDrop is used in a pattern) - #158479 (Reject static item as direct const generic arg) - #158738 (next_trait_solver: Recover from GCE const exprs) - #159451 (Remove config cloning in compiletest) - #159646 (Increase depth for float infer var fallback hack) - #159705 (bootstrap: Prefer `cfg!(not(test))` when skipping code paths during unit tests)
…uwer Rollup of 11 pull requests Successful merges: - #159712 (Subtree sync for rustc_codegen_cranelift) - #155697 (Stabilize c-variadic function definitions) - #159285 (Simplify `apply_effects_in_range`) - #159596 (unify the AST repr of type const and const RHS) - #159607 (test: update riscv32e-registers.rs for LLVM 24 MC diagnostic changes) - #159659 (Move `Limit` out of `rustc_hir`) - #159707 (fix error when a dangling ref in a ManuallyDrop is used in a pattern) - #158738 (next_trait_solver: Recover from GCE const exprs) - #159451 (Remove config cloning in compiletest) - #159646 (Increase depth for float infer var fallback hack) - #159705 (bootstrap: Prefer `cfg!(not(test))` when skipping code paths during unit tests)
Rollup merge of #158738 - Dnreikronos:next_trait_solver/gce_expr_recovery, r=BoxyUwU next_trait_solver: Recover from GCE const exprs fixes #158428 the next solver already rejects `generic_const_exprs` with `-Znext-solver=globally`, but we can still walk into `ConstKind::Expr` while compiling after that error and crash anyway. imo this should stay as a recovery fix, not a gce implementation. ambiguity still lgtm to me here: idk that we want to say the expr is solved when the feature combo is already invalid, we just need to not ice after the real error. long-term, proper `ConstKind::Expr` support would be a much bigger thing. the next solver would need to type-check, normalize, compare, and evaluate or prove these exprs structurally, including nested binops, unops, casts, calls, and the result type for `ConstArgHasType`. that's out of scope for this pr. this teaches both const evaluatable and const arg has type paths to recover on `ConstKind::Expr`, then adds the union repro as a ui test.
…uwer Rollup of 11 pull requests Successful merges: - rust-lang/rust#159712 (Subtree sync for rustc_codegen_cranelift) - rust-lang/rust#155697 (Stabilize c-variadic function definitions) - rust-lang/rust#159285 (Simplify `apply_effects_in_range`) - rust-lang/rust#159596 (unify the AST repr of type const and const RHS) - rust-lang/rust#159607 (test: update riscv32e-registers.rs for LLVM 24 MC diagnostic changes) - rust-lang/rust#159659 (Move `Limit` out of `rustc_hir`) - rust-lang/rust#159707 (fix error when a dangling ref in a ManuallyDrop is used in a pattern) - rust-lang/rust#158738 (next_trait_solver: Recover from GCE const exprs) - rust-lang/rust#159451 (Remove config cloning in compiletest) - rust-lang/rust#159646 (Increase depth for float infer var fallback hack) - rust-lang/rust#159705 (bootstrap: Prefer `cfg!(not(test))` when skipping code paths during unit tests)
…uwer Rollup of 11 pull requests Successful merges: - rust-lang/rust#159712 (Subtree sync for rustc_codegen_cranelift) - rust-lang/rust#155697 (Stabilize c-variadic function definitions) - rust-lang/rust#159285 (Simplify `apply_effects_in_range`) - rust-lang/rust#159596 (unify the AST repr of type const and const RHS) - rust-lang/rust#159607 (test: update riscv32e-registers.rs for LLVM 24 MC diagnostic changes) - rust-lang/rust#159659 (Move `Limit` out of `rustc_hir`) - rust-lang/rust#159707 (fix error when a dangling ref in a ManuallyDrop is used in a pattern) - rust-lang/rust#158738 (next_trait_solver: Recover from GCE const exprs) - rust-lang/rust#159451 (Remove config cloning in compiletest) - rust-lang/rust#159646 (Increase depth for float infer var fallback hack) - rust-lang/rust#159705 (bootstrap: Prefer `cfg!(not(test))` when skipping code paths during unit tests)
-Znext-solver and GCE are enabled
fixes #158428
the next solver already rejects
generic_const_exprswith-Znext-solver=globally, but we can still walk intoConstKind::Exprwhile compiling after that error and crash anyway.imo this should stay as a recovery fix, not a gce implementation. ambiguity still lgtm to me here: idk that we want to say the expr is solved when the feature combo is already invalid, we just need to not ice after the real error.
long-term, proper
ConstKind::Exprsupport would be a much bigger thing. the next solver would need to type-check, normalize, compare, and evaluate or prove these exprs structurally, including nested binops, unops, casts, calls, and the result type forConstArgHasType. that's out of scope for this pr.this teaches both const evaluatable and const arg has type paths to recover on
ConstKind::Expr, then adds the union repro as a ui test.