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

Trait ref is not considered knowable due to normalization #51

Closed
Tracked by #114862
compiler-errors opened this issue Jul 24, 2023 · 0 comments · Fixed by rust-lang/rust#114457
Closed
Tracked by #114862
Labels
A-coherence Having to do with regressions in `-Ztrait-solver=next-coherence`

Comments

@compiler-errors
Copy link
Member

This code fails in the new trait solver -Ztrait-solver=next-coherence:

use std::future::Future;
use std::pin::Pin;

struct Value;

impl<'a> std::future::IntoFuture for Pin<&'a mut Value>
{
    type Output = ();
    type IntoFuture = Pin<Box<dyn Future<Output = ()> + Send>>;

    fn into_future(self) -> Self::IntoFuture {
        todo!()
    }
}

Which overlaps with this implementation: https://doc.rust-lang.org/std/future/trait.Future.html#impl-Future-for-Pin%3CP%3E

We try to prove that <&mut Value as std::ops::Deref>::Target: std::future::Future does not hold, but that ends up being ambiguous because aliases are treated as non-local tys, even though we can definitely normalize <&mut Value as std::ops::Deref>::Target to just Value, which is a local ty.

@compiler-errors compiler-errors added the A-coherence Having to do with regressions in `-Ztrait-solver=next-coherence` label Jul 24, 2023
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Aug 8, 2023
…ze, r=compiler-errors

normalize in `trait_ref_is_knowable` in new solver

fixes rust-lang/trait-system-refactor-initiative#51

Alternatively we could avoid normalizing the self type and do this at the end of the `assemble_candidates_via_self_ty` stack by splitting candidates into:
- applicable without normalizing self type
- applicable for aliases, even if they can be normalized
- applicable for stuff which cannot get normalized further

I don't think this would have any significant benefits and it also seems non-trivial to avoid normalizing only the self type in `trait_ref_is_knowable`.

r? `@compiler-errors`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Aug 12, 2023
…ze, r=compiler-errors

normalize in `trait_ref_is_knowable` in new solver

fixes rust-lang/trait-system-refactor-initiative#51

Alternatively we could avoid normalizing the self type and do this at the end of the `assemble_candidates_via_self_ty` stack by splitting candidates into:
- applicable without normalizing self type
- applicable for aliases, even if they can be normalized
- applicable for stuff which cannot get normalized further

I don't think this would have any significant benefits and it also seems non-trivial to avoid normalizing only the self type in `trait_ref_is_knowable`.

r? `@compiler-errors`
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 13, 2023
…, r=compiler-errors

normalize in `trait_ref_is_knowable` in new solver

fixes rust-lang/trait-system-refactor-initiative#51

Alternatively we could avoid normalizing the self type and do this at the end of the `assemble_candidates_via_self_ty` stack by splitting candidates into:
- applicable without normalizing self type
- applicable for aliases, even if they can be normalized
- applicable for stuff which cannot get normalized further

I don't think this would have any significant benefits and it also seems non-trivial to avoid normalizing only the self type in `trait_ref_is_knowable`.

r? `@compiler-errors`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-coherence Having to do with regressions in `-Ztrait-solver=next-coherence`
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant