Compiler accepts const equality bound involving nonsensical nested equality constraint on associated const #102335
Assignees
Labels
C-bug
Category: This is a bug.
F-associated_const_equality
`#![feature(associated_const_equality)]`
requires-nightly
This issue requires a nightly compiler in some way.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
rustbot
added
requires-nightly
fmease
changed the title
compiler-errors
added
the
F-associated_const_equality
|
Doesn't need assoc const equality: trait T {
type A: S<C<i32 = ()> = ()>;
}
trait Q {}
trait S {
type C: Q;
}
fn main() {}Let me take a quick stab at this. @rustbot claim |
|
On a related note, a slightly modified version of the code above leads to an ICE (I was about to create a separate issue for this, should I still do that?): #![feature(associated_const_equality)]
#![crate_type = "lib"]
trait T {
type A: S<C<X = 0i32> = 34>;
}
trait S {
const C: i32;
}stderr (diagnostics & backtrace)This only leads to an ICE on the current nightly (2022-09-27) (e.g. on the playground) but not on older ones like 9062b78 (2022-09-21). @compiler-errors |
|
If you want to bisect it feel free, but I think fixing the original issue in this report will also fix this one. |
Yeah, I think so, too. I guess I won't bisect this. |
|
This regressed in the last day |
|
Oh wait, I caused it: searched nightlies: from nightly-2022-08-01 to nightly-2022-09-26 bisected with cargo-bisect-rustc v0.6.3Host triple: x86_64-unknown-linux-gnu cargo bisect-rustc --start=2022-08-01 --prompt |
fmease
changed the title
Aaron1011
pushed a commit
to Aaron1011/rust
that referenced
this issue
Jan 6, 2023
…n-assoc-ty-binding, r=cjgillot Deny associated type bindings within associated type bindings Fixes rust-lang#102335 This was made worse by rust-lang#100865, which unified the way we generate substs for GATs and non-generic associated types. However, the issue was not _caused_ by rust-lang#100865, evidenced by the test I added for GATs: ```rust trait T { type A: S<C<(), i32 = ()> = ()>; //~^ ERROR associated type bindings are not allowed here } trait Q {} trait S { type C<T>: Q; } fn main() {} ``` ^ which passes on beta (where GATs are stable) and presumably ever since GATs support was added to `create_substs_for_associated_item` in astconv.
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Uh oh!
There was an error while loading. Please reload this page.
I expect the following code to be rejected by the compiler but it is actually accepted and compiles successfully:
The associated constant
S::Cdoes not have any generic parameters / associated items (constants cannot have those anyways in the current version of Rust) and thus the argument list<i32 = u64>should be flagged as erroneous. Interestingly, if you remove the= u64, the compiler correctly identifies this as an error:this associated constant takes 0 generic arguments but 1 generic argument was supplied.I think
i32 = u64is to be interpreted as a nested equality constraint (and not as a “defaulted” parameter, i.e. a parameter with a default value).Meta
rustc -Vv:@rustbot label T-compiler requires-nightly
I would label this with F-associated_const_equality but sadly that label does not exist.(it now does)Hence, I am just going to mention its tracking issue: #92827.
CC @JulianKnodt
The text was updated successfully, but these errors were encountered: