Prevent generic pattern types from being used in libstd #136584
Conversation
|
changes to the core type system |
This comment has been minimized.
This comment has been minimized.
b025089 to
f12b963
Compare
| let c = self.tcx().normalize_erasing_regions( | ||
| self.infcx.typing_env(self.param_env), | ||
| c, | ||
| ); | ||
| if c.has_aliases() || c.has_param() { |
There was a problem hiding this comment.
This is a bit fishy, but I needed more than ClauseKind::ConstEvaluatable. ConstEvaluatable only checks that the constant itself will not fail to evaluate, which a generic parameter will also not (due to how we're enforcing things with const generics elsewhere).
So I took the knowledge that these constants always have concrete types and will normalize to error constants if they have errors themselves, to just evaluate here and check if there are still params or aliases around after normalization.
Oh and I need to normalize, can't just check for aliases and params, since we treat any unevaluated const as an alias, even if it refers to a free const. Which I guess makes sense as we want to cause normalization to actually get to the const and evaluate it.
There was a problem hiding this comment.
I think you can/should just use c.has_param() and forget about even normalizing- min const generics doesn't permit Foo<{ <T as Trait>::USIZE }> where the assoc const can be normalized to usize regardless of T so I think design wise it's fine to not be "clever" here and just say that referring to generic parameters syntactically is forbidden.
There was a problem hiding this comment.
I'm not sure why you need to check for aliases 🤔
There was a problem hiding this comment.
uh yea, i think I just thoroughly confused myself. Changed it to avoid normalization and just checking for params. No params in the args of the unevaluated const is what we actually are interested in after all
|
r? @BoxyUwU unless you specifically want a review from lcnr? though my understanding was that they are not particularly involved with pattern types |
f12b963 to
fab6d8a
Compare
|
@bors r+ rollup |
…oxyUwU Prevent generic pattern types from being used in libstd Pattern types should follow the same rules that patterns follow. So a pattern type range must not wrap and not be empty. While we reject such invalid ranges at layout computation time, that only happens during monomorphization in the case of const generics. This is the exact same issue as other const generic math has, and since there's no solution there yet, I put these pattern types behind a separate incomplete feature. These are not necessary for the pattern types MVP (replacing the layout range attributes in libcore and rustc). cc rust-lang#136574 (new tracking issue for the `generic_pattern_types` feature gate) r? `@lcnr` cc `@scottmcm` `@joshtriplett`
…oxyUwU Prevent generic pattern types from being used in libstd Pattern types should follow the same rules that patterns follow. So a pattern type range must not wrap and not be empty. While we reject such invalid ranges at layout computation time, that only happens during monomorphization in the case of const generics. This is the exact same issue as other const generic math has, and since there's no solution there yet, I put these pattern types behind a separate incomplete feature. These are not necessary for the pattern types MVP (replacing the layout range attributes in libcore and rustc). cc rust-lang#136574 (new tracking issue for the `generic_pattern_types` feature gate) r? `@lcnr` cc `@scottmcm` `@joshtriplett`
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#136107 (Introduce CoercePointeeWellformed for coherence checks at typeck stage) - rust-lang#136155 (Enable sanitizers on MSVC CI jobs) - rust-lang#136524 (Delay bug when method confirmation cannot upcast object pick of self) - rust-lang#136584 (Prevent generic pattern types from being used in libstd) - rust-lang#136603 (compiler: gate `extern "{abi}"` in ast_lowering) - rust-lang#136821 (assign marcoieni and jdno to infra-ci PRs) - rust-lang#136825 (Update books) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#136584 - oli-obk:pattern-types-generic, r=BoxyUwU Prevent generic pattern types from being used in libstd Pattern types should follow the same rules that patterns follow. So a pattern type range must not wrap and not be empty. While we reject such invalid ranges at layout computation time, that only happens during monomorphization in the case of const generics. This is the exact same issue as other const generic math has, and since there's no solution there yet, I put these pattern types behind a separate incomplete feature. These are not necessary for the pattern types MVP (replacing the layout range attributes in libcore and rustc). cc rust-lang#136574 (new tracking issue for the `generic_pattern_types` feature gate) r? ``@lcnr`` cc ``@scottmcm`` ``@joshtriplett``
Pattern types should follow the same rules that patterns follow. So a pattern type range must not wrap and not be empty. While we reject such invalid ranges at layout computation time, that only happens during monomorphization in the case of const generics. This is the exact same issue as other const generic math has, and since there's no solution there yet, I put these pattern types behind a separate incomplete feature.
These are not necessary for the pattern types MVP (replacing the layout range attributes in libcore and rustc).
cc #136574 (new tracking issue for the
generic_pattern_typesfeature gate)r? @lcnr
cc @scottmcm @joshtriplett