-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Do not ICE on generic const expr referencing missing ty param #142810
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
base: master
Are you sure you want to change the base?
Conversation
Make `ParamEnv::find_ty_from_env` return an `Option<Ty>>` so if a const has a type corresponding to an unknown type parameter, we don't ICE when using `generic_const_exprs`: ```rust #![allow(incomplete_features)] #![feature(generic_const_exprs, adt_const_params)] struct X< const FN: () = { || { let _: [(); B]; //~ ERROR cannot find value `B` in this scope //~^ ERROR the constant `FN` is not of type `()` }; }, >; fn main() {} ```
Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor |
I'm pretty certain it's an explicit design choice that Given that GCE is on its way out, I'm not totally sure if this fix should be merged. I'll defer to @BoxyUwU of course. |
Also, could you please write up an explanation for why this actually fixes the bug that it does? Given the subtle interaction, it's not necessarily clear why this ICE triggers in the first place, and why we're trying to look up a const param that's not present in the param-env. Specifically, there seem to be a lot of pieces that are necessary, like the closure, and some that aren't, like that |
The job Click to see the possible cause of the failure (guessed by this bot)
|
Make
ParamEnv::find_ty_from_env
return anOption<Ty>>
so if a const has a type corresponding to an unknown type parameter, we don't ICE when usinggeneric_const_exprs
:Fix #142709.