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

Impls for associated types misidentified as conflicting #100028

Closed
djkoloski opened this issue Aug 1, 2022 · 2 comments
Closed

Impls for associated types misidentified as conflicting #100028

djkoloski opened this issue Aug 1, 2022 · 2 comments
Labels
C-bug Category: This is a bug.

Comments

@djkoloski
Copy link
Contributor

This issue came up when a downstream user attempted to implement an rkyv trait for their own types. It appears that using an associated type as the target of an impl is not treated as a conflicting impl in the defining crate, but is treated as a conflicting impl in any downstream crates.

I tried this code:

// upstream/mod.rs

pub trait Associate {
    type Associated;
}

impl Associate for () {
    type Associated = ();
}

pub trait Upstream {}

impl Upstream for <() as Associate>::Associated {}

// downstream/mod.rs

use upstream::Upstream;

pub struct MyType;

impl Upstream for MyType {}

I expected to see this happen: the code compiles.

Instead, this happened:

error[E0119]: conflicting implementations of trait `upstream::Upstream` for type `MyType`
 --> downstream/src/lib.rs:5:1
  |
5 | impl Upstream for MyType {}
  | ^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: conflicting implementation in crate `upstream`:
          - impl Upstream for <() as Associate>::Associated;

Meta

rustc --version --verbose:

rustc 1.62.1 (e092d0b6b 2022-07-16)
binary: rustc
commit-hash: e092d0b6b43f2de967af0887873151bb1c0b18d3
commit-date: 2022-07-16
host: x86_64-apple-darwin
release: 1.62.1
LLVM version: 14.0.5

Credit to @Kixiron for discovering this issue.

@djkoloski djkoloski added the C-bug Category: This is a bug. label Aug 1, 2022
@veber-alex
Copy link
Contributor

I believe this is a duplicate of #99940

@lcnr
Copy link
Contributor

lcnr commented Aug 1, 2022

yes, this is a duplicate of #99940, closing.

still thanks for opening this PR ❤️ how can a bug existing since at least version 1.30 (which is the oldest one i have locally) get discovered twice in the span of 3 days.

i can't remember ever seeing this bug before #99940 😅

@lcnr lcnr closed this as completed Aug 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug.
Projects
None yet
Development

No branches or pull requests

3 participants