-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Inherent associated type projection does not respect where
clauses
#104251
Comments
where
clauses
For comparison, the analogous code containing an (inherent) associated constant instead leads to the following error:
Code: struct Foo<T: ?Sized>(T);
impl<T> Foo<T> {
const BAR: () = ();
}
fn main() {
let _: () = Foo::<[u8]>::BAR;
} @rustbot claim (edit: I've just noticed it says associated item cannot be called even though we're not calling anything ^^ well, that's a separate issue & I'm gonna create a GitHub issue for it sometime later) |
Ah 😅 what's more, we don't actually take the concrete #![feature(inherent_associated_types)]
struct S<T>(T);
impl S<u8> {
type P = ();
}
impl S<String> {
type P = bool;
}
fn main() {
let _: S<String>::P = false;
// ^^^^^ expected `()`, found `bool` // <- this is incorrect!
// the code should pass tycheck
} I consider this to be part of this issue or at least strongly related to it. In any case, I am already looking into fixing this. Let's see if I can actually manage to do so! Edit: I already have a working patch locally for which I am gonna open a PR after the weekend :) |
Type-directed probing for inherent associated types When probing for inherent associated types (IATs), equate the Self-type found in the projection with the Self-type of the relevant inherent impl blocks and check if all predicates are satisfied. Previously, we didn't look at the Self-type or at the bounds and just picked the first inherent impl block containing an associated type with the name we were searching for which is obviously incorrect. Regarding the implementation, I basically copied what we do during method probing (`assemble_inherent_impl_probe`, `consider_probe`). Unfortunately, I had to duplicate a lot of the diagnostic code found in `rustc_hir_typeck::method::suggest` which we don't have access to in `rustc_hir_analysis`. Not sure if there is a simple way to unify the error handling. Note that in the future, `rustc_hir_analysis::astconv` might not actually be the place where we resolve inherent associated types (see rust-lang/rust#103621 (comment)) but `rustc_hir_typeck` (?) in which case the duplication may naturally just disappear. While inherent associated *constants* are currently resolved during "method" probing, I did not find a straightforward way to incorporate IAT lookup into it as types and values (functions & constants) are two separate entities for which distinct code paths are taken. Fixes #104251 (incl. rust-lang/rust#104251 (comment)). Fixes #105305. Fixes #107468. `@rustbot` label T-types F-inherent_associated_types r? types
I tried this code:
I expected to see it fail, since while
Foo<[u8]>
is WF, it does not satisfy the where-clauses of theimpl
that it's selecting the associated typeBar
from.The text was updated successfully, but these errors were encountered: