9f6cd6defb
Fix ICE: When Trying to check visibility of a #[type_const], check RHS instead. This PR fixes https://github.com/rust-lang/rust/issues/150956 for min_const_generic_args https://github.com/rust-lang/rust/issues/132980. The first part of this PR checks in `reachable.rs` if we have a type const use `visit_const_item_rhs(init);` instead of calling `const_eval_poly_to_alloc()` The second part is I noticed that if `const_eval_poly_to_alloc()` returns a `ErrorHandled::TooGeneric` then switches to `visit_const_item_rhs()`. So further up `const_eval_poly_to_alloc()` call order it eventual gets to `eval_in_interpreter()`. So I added a debug_assert in `eval_in_interpreter()` if we happen to try and run CTFE on a `type_const`. The other bit is just a test case, and some duplicated code I noticed. While the PR does get rid of the ICE for a type_const with `pub` visibility. If I try using the const though it will ICE with the following: ``` error: internal compiler error: /home/keith/GitHub/rust_kc/compiler/rustc_const_eval/src/check_consts/qualifs.rs:355:13: expected ConstKind::Param or ConstKind::Value here, found UnevaluatedConst { def: DefId(20:4 ~ colorkit[c783]::TYPE_CONST), args: [] } thread 'rustc' (819687) panicked at /home/keith/GitHub/rust_kc/compiler/rustc_const_eval/src/check_consts/qualifs.rs:355:13: ``` I suspect it is a similar issue to inherent associated consts. Since if I apply the same fix I had here: https://github.com/rust-lang/rust/pull/150799#discussion_r2676504639 I then can use the const internally and in external crates without any issues. Although, did not include that fix since if it is a similar issue it would need to be addressed elsewhere. r? @BoxyUwU @rustbot label +F-associated_const_equality +F-min_generic_const_args |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| messages.ftl | ||