diff options
| author | Manish Goregaokar <manishsmail@gmail.com> | 2025-03-12 10:19:28 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-03-12 10:19:28 -0700 |
| commit | 2d7a592c62f162d3f96192e2381bb1afbcb94e42 (patch) | |
| tree | 26d1365a109659ce2e562c5e3f1eb2266591288e /compiler/rustc_attr_parsing/src | |
| parent | 40c7a9014eb4cad066f6d990d0e0527faf877dab (diff) | |
| parent | 42773bfcac71decb4058ca1c3b4eff816235549f (diff) | |
| download | rust-2d7a592c62f162d3f96192e2381bb1afbcb94e42.tar.gz rust-2d7a592c62f162d3f96192e2381bb1afbcb94e42.zip | |
Rollup merge of #138259 - compiler-errors:disentangle-ribs, r=BoxyUwU
Disentangle `ForwardGenericParamBan` and `ConstParamTy` ribs
In #137617, the `ConstParamTy` rib was adjusted to act kinda like the `ForwardGenericParamBan`. However, this means that it no longer served its purpose banning generics from *parent items*. Although we still are checking for param type validity using the `ConstParamTy_` trait, which means that we weren't accepting code we shouldn't, I think it's a bit strange for us not to be rejecting code like this during *resolution* and instead letting these malformed const generics leak into the type system:
```rust
trait Foo<T> {
fn bar<const N: T>() {}
}
```
This PR does a few things:
1. Introduce a `ForwardGenericParamBanReason` enum, and start using the `ForwardGenericParamBan` rib to ban forward-declared params in const tys when `generic_const_parameter_types` is enabled.
2. Start using the `ConstParamTy` rib to ban *all* generics when `generic_const_parameter_types` is disabled.
3. Improve the diagnostics for both of the cases above, and for forward-declared params in parameter defaults too :3
r? `@BoxyUwU` or reassign
Diffstat (limited to 'compiler/rustc_attr_parsing/src')
0 files changed, 0 insertions, 0 deletions
