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

Type checker doesn't consider trait duality when reasoning about type parameters for associated types #38917

Closed
bholley opened this issue Jan 8, 2017 · 5 comments · Fixed by #81485
Labels
A-associated-items Area: Associated items (types, constants & functions) A-trait-system Area: Trait system A-type-system Area: Type system C-bug Category: This is a bug. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@bholley
Copy link
Contributor

bholley commented Jan 8, 2017

See the testcase here: https://is.gd/WZh43I

I'd normally run this by a few people before filing an issue, but #rust is quiet on a Saturday night. ;-)

@Manishearth thoughts?

@Manishearth Manishearth added A-trait-system Area: Trait system A-type-system Area: Type system labels Jan 8, 2017
@Manishearth
Copy link
Member

Trait resolution basically doesn't know how to figure out that two types are equal in the case of "dual traits".

This is one of the inevitable issues @nox is going to hit in his Servo script bindings refactor 😉

I do wish we had a more formalized notion of type families that could be used to better instruct the compiler in these cases. @nikomatsakis was talking about this in his blog, and I've personally found the need for a family-trait type situation more than once, both when modeling dualities and when modeling generic abstractions over sets of types like you're trying to do.

bholley added a commit to bholley/servo that referenced this issue Jan 8, 2017
bholley added a commit to bholley/servo that referenced this issue Jan 9, 2017
… TNode. r=emilio

This works around the issue described in rust-lang/rust#38917
@Mark-Simulacrum
Copy link
Member

This appears to work today; E-needstest.

@Mark-Simulacrum Mark-Simulacrum added the E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. label May 19, 2017
@nikomatsakis
Copy link
Contributor

I don't think it works necessarily -- if you remove the bound that @bholley highlighted, you still get an error.

@nikomatsakis nikomatsakis removed the E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. label May 25, 2017
@nikomatsakis
Copy link
Contributor

The example that @bholley expected to pass (and I think he is right that it should) is this one:

use std::borrow::Borrow;

trait TNode: Sized {
  type ConcreteElement: TElement<ConcreteNode = Self>;
}

trait TElement: Sized {
    type ConcreteNode: TNode<ConcreteElement = Self>;
}

trait DomTraversal<N: TNode> {
    type BorrowElement: Borrow<N::ConcreteElement>;
}

fn recalc_style_at<E, D>()
    where E: TElement,
          D: DomTraversal<E::ConcreteNode>,
{
}


fn main() {
}

@estebank
Copy link
Contributor

estebank commented Nov 5, 2019

Current output:

error[E0277]: the trait bound `<D as DomTraversal<<E as TElement>::ConcreteNode>>::BorrowElement: std::borrow::Borrow<E>` is not satisfied
  --> src/main.rs:15:1
   |
11 |   trait DomTraversal<N: TNode> {
   |   ---------------------------- required by `DomTraversal`
...
15 | / fn recalc_style_at<E, D>()
16 | |     where E: TElement,
17 | |           D: DomTraversal<E::ConcreteNode>,
   | |                                            - help: consider further restricting the associated type: `, <D as DomTraversal<<E as TElement>::ConcreteNode>>::BorrowElement: std::borrow::Borrow<E>`
18 | | {
19 | | }
   | |_^ the trait `std::borrow::Borrow<E>` is not implemented for `<D as DomTraversal<<E as TElement>::ConcreteNode>>::BorrowElement`

@estebank estebank added A-associated-items Area: Associated items (types, constants & functions) F-associated_type_bounds `#![feature(associated_type_bounds)]` T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Nov 5, 2019
@jonas-schievink jonas-schievink removed the F-associated_type_bounds `#![feature(associated_type_bounds)]` label Jan 28, 2021
JohnTitor added a commit to JohnTitor/rust that referenced this issue Feb 2, 2021
Add some tests for associated-type-bounds issues

Closes rust-lang#38917
Closes rust-lang#40093
Closes rust-lang#43475
Closes rust-lang#63591

rust-lang#47897 is likely closable too, but it needs an MCVE
~~rust-lang#38917, rust-lang#40093, rust-lang#43475, rust-lang#47897 all are mislabeled and shouldn't have the `F-associated-type-bounds` label~~

~~rust-lang#71685 is also mislabeled as commented on in that thread~~
@bors bors closed this as completed in a61e6ab Feb 2, 2021
@fmease fmease added A-trait-system Area: Trait system and removed A-trait-system Area: Trait system labels Dec 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-associated-items Area: Associated items (types, constants & functions) A-trait-system Area: Trait system A-type-system Area: Type system C-bug Category: This is a bug. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants