about summary refs log tree commit diff
path: root/compiler/rustc_attr_parsing/src
diff options
context:
space:
mode:
authorManish Goregaokar <manishsmail@gmail.com>2025-03-12 10:19:28 -0700
committerGitHub <noreply@github.com>2025-03-12 10:19:28 -0700
commit2d7a592c62f162d3f96192e2381bb1afbcb94e42 (patch)
tree26d1365a109659ce2e562c5e3f1eb2266591288e /compiler/rustc_attr_parsing/src
parent40c7a9014eb4cad066f6d990d0e0527faf877dab (diff)
parent42773bfcac71decb4058ca1c3b4eff816235549f (diff)
downloadrust-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