Skip to content
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

AliasRelate hides info in transitive cases #7

Open
lcnr opened this issue Apr 17, 2023 · 0 comments
Open

AliasRelate hides info in transitive cases #7

lcnr opened this issue Apr 17, 2023 · 0 comments

Comments

@lcnr
Copy link
Contributor

lcnr commented Apr 17, 2023

if we have A == alias == B and A and B are partially inferred, AliasRelate is weaker than the current eager_inference_replacement.

Due to our new approach to generalization in rust-lang/rust#119106 this example now compiles in the new solver. While the underlying issue is still not fixed, it feels incredibly hard to trigger now.

use std::marker::PhantomData;

#[derive(Default)]
struct Foo<T, U>(PhantomData<(T, U)>);

trait Trait {
    type Assoc;
    
    fn to_assoc(self) -> Self::Assoc;
}

impl Trait for Foo<u32, i32> {
    type Assoc = Foo<u32, i32>;
    fn to_assoc(self) -> Self::Assoc {
        Foo(PhantomData)
    }
}
impl Trait for Foo<i32, u32> {
    type Assoc = Foo<i32, u32>;
    fn to_assoc(self) -> Self::Assoc {
        Foo(PhantomData)
    }
}

fn main() {
    let mut x: Foo<_, _> = Default::default();
    let mut assoc = x.to_assoc();
    assoc = Foo::<u32, _>(PhantomData);
    assoc = Foo::<_, i32>(PhantomData);
    x = assoc;
}

passes on stable, results in the following error with the new solver

error[E0282]: type annotations needed
  --> <source>:26:12
   |
26 |     let x: Foo<_, _> = Default::default();
   |            ^^^^^^^^^ cannot infer type for struct `Foo<_, _>`

error[E0283]: type annotations needed
  --> <source>:27:23
   |
27 |     let mut assoc = x.to_assoc();
   |                       ^^^^^^^^
   |
note: multiple `impl`s satisfying `Foo<_, _>: Trait` found
  --> <source>:12:1
   |
12 | impl Trait for Foo<u32, i32> {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
18 | impl Trait for Foo<i32, u32> {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: try using a fully qualified path to specify the expected types
   |
27 |     let mut assoc = <Foo<_, _> as Trait>::to_assoc(x);
   |                     +++++++++++++++++++++++++++++++ ~

The new solver has 3 obligations: AliasRelate(<Foo<_, _> as Trait>::Assoc, Foo<u32, _>) and AliasRelate(<Foo<_, _> as Trait>::Assoc, Foo<_, i32>) and then AliasRelate(<Foo<_, _> as Trait>::Assoc, Foo<_, _>) from the assignment x == assoc.

TODO: I expect us to keep shallow norm inside of the trait solver, so we need to add a test where we this happens while proving some goal

@compiler-errors compiler-errors changed the title AliasRelate hides info in trasitive cases AliasRelate hides info in transitive cases Apr 22, 2023
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jan 26, 2024
always normalize `LoweredTy` in the new solver

I currently expect us to stop using alias bound candidates of normalizable aliases due to rust-lang/trait-system-refactor-initiative#77 by landing rust-lang#119744. At this point it mostly doesn't matter whether we eagerly normalize (and replace with infer vars in case of ambiguity). cc rust-lang#113473 previous attempt

The infer var replacement for ambiguous projections can in very rare cases:
- weaken inference rust-lang/trait-system-refactor-initiative#81
- strengthen inference rust-lang/trait-system-refactor-initiative#7

I do not expect this impact on inference to significantly affect real crates.

r? `@compiler-errors`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jan 26, 2024
always normalize `LoweredTy` in the new solver

I currently expect us to stop using alias bound candidates of normalizable aliases due to rust-lang/trait-system-refactor-initiative#77 by landing rust-lang#119744. At this point it mostly doesn't matter whether we eagerly normalize (and replace with infer vars in case of ambiguity). cc rust-lang#113473 previous attempt

The infer var replacement for ambiguous projections can in very rare cases:
- weaken inference rust-lang/trait-system-refactor-initiative#81
- strengthen inference rust-lang/trait-system-refactor-initiative#7

I do not expect this impact on inference to significantly affect real crates.

r? ``@compiler-errors``
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jan 27, 2024
Rollup merge of rust-lang#120378 - lcnr:normalize-ast, r=compiler-errors

always normalize `LoweredTy` in the new solver

I currently expect us to stop using alias bound candidates of normalizable aliases due to rust-lang/trait-system-refactor-initiative#77 by landing rust-lang#119744. At this point it mostly doesn't matter whether we eagerly normalize (and replace with infer vars in case of ambiguity). cc rust-lang#113473 previous attempt

The infer var replacement for ambiguous projections can in very rare cases:
- weaken inference rust-lang/trait-system-refactor-initiative#81
- strengthen inference rust-lang/trait-system-refactor-initiative#7

I do not expect this impact on inference to significantly affect real crates.

r? ``@compiler-errors``
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant