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

Conflicting implementation of trait with generic_const_exprs feature #92186

Open
minseongg opened this issue Dec 22, 2021 · 2 comments
Open

Conflicting implementation of trait with generic_const_exprs feature #92186

minseongg opened this issue Dec 22, 2021 · 2 comments
Labels
A-const-generics Area: const generics (parameters and arguments) C-bug Category: This is a bug. F-generic_const_exprs `#![feature(generic_const_exprs)]` requires-incomplete-features requires-nightly This issue requires a nightly compiler in some way.

Comments

@minseongg
Copy link

minseongg commented Dec 22, 2021

I tried this code:

#![allow(incomplete_features)]
#![feature(adt_const_params)]
#![feature(generic_const_exprs)]

use std::marker::PhantomData;

pub struct Foo<const P: Protocol, T> {
    _marker: PhantomData<T>,
}

#[derive(PartialEq, Eq)]
pub enum Protocol {
    Variant1,
    Variant2,
}

pub trait Bar {}

impl<T> Bar for Foo<{ Protocol::Variant1 }, T> {}
impl<T> Bar for Foo<{ Protocol::Variant2 }, T> {}

I expected to see this happen: This is the result when I commented generic_const_exprs feature.

$ cargo build
   Compiling test-nightly v0.1.0
    Finished dev [unoptimized + debuginfo] target(s) in 0.22s

Instead, this happened:

$ cargo build
   Compiling test-nightly v0.1.0
error[E0119]: conflicting implementations of trait `Bar` for type `Foo<{ Protocol::Variant1 }, _>`
  --> src/lib.rs:28:1
   |
27 | impl<T> Bar for Foo<{ Protocol::Variant1 }, T> {}
   | -------------------- first implementation here
28 | impl<T> Bar for Foo<{ Protocol::Variant2 }, T> {}
   | ^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `Foo<{ Protocol::Variant1 }, _>`

For more information about this error, try `rustc --explain E0119`.
error: could not compile `test-nightly` due to previous error

Meta

rustc --version --verbose:

rustc 1.59.0-nightly (23f69235a 2021-12-20)
binary: rustc
commit-hash: 23f69235ad2eb9b44ac1a55eeaa3f9b484d9de4a
commit-date: 2021-12-20
host: x86_64-unknown-linux-gnu
release: 1.59.0-nightly
LLVM version: 13.0.0
Backtrace

$ RUST_BACKTRACE=1 cargo build
   Compiling test-nightly v0.1.0
error[E0119]: conflicting implementations of trait `Bar` for type `Foo<{ Protocol::Variant1 }, _>`
  --> src/lib.rs:20:1
   |
19 | impl<T> Bar for Foo<{ Protocol::Variant1 }, T> {}
   | -------------------- first implementation here
20 | impl<T> Bar for Foo<{ Protocol::Variant2 }, T> {}
   | ^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `Foo<{ Protocol::Variant1 }, _>`

For more information about this error, try `rustc --explain E0119`.
error: could not compile `test-nightly` due to previous error

@minseongg minseongg added the C-bug Category: This is a bug. label Dec 22, 2021
@workingjubilee workingjubilee added F-generic_const_exprs `#![feature(generic_const_exprs)]` A-const-generics Area: const generics (parameters and arguments) F-adt_const_params `#![feature(adt_const_params)]` and removed F-adt_const_params `#![feature(adt_const_params)]` labels Dec 22, 2021
@BoxyUwU
Copy link
Member

BoxyUwU commented Dec 22, 2021

caused by #90023 because during coherence we try to equate Foo<{ 1 }> with Foo<{ 2 }> to see if the impls overlap, which tries to equate the anon consts: { 1 } with { 2 } which have substs of _ and with that PR we now bail with EvaluatedToAmbig whereas before we were able to say they dont unify.

more minimal repro:

#![feature(generic_const_exprs)]
#![allow(incomplete_features)]

pub struct Foo<const N: usize>;
pub trait Bar<T> {}

impl<T> Bar<T> for Foo<{ 1 }> {}
impl<T> Bar<T> for Foo<{ 2 }> {}

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jan 18, 2022
…ce, r=lcnr

Directly use ConstValue for single literals in blocks

Addresses the minimal repro in rust-lang#92186, but doesn't fix the underlying problem (which would be solved by solving the anon subst problem afaict).

I do, however, think that it makes sense in general to treat single literals in anon blocks as const values directly, especially in light of the problem that the issue refers to (anon const evaluation being postponed until infer variables in substs can be resolved, which was introduced by rust-lang#90023), i.e. while we do get warnings for those unnecessary braces, we should try to avoid errors caused by those braces if possible.
@lcnr
Copy link
Contributor

lcnr commented Jun 24, 2022

this also affects inherent impls

const ONE : i32 = 1;
const TWO : i32 = 2;

struct Foo<const i: i32, const j: i32> {}

impl<const i: i32> Foo<i, ONE> {
    pub fn foo() {}
}

impl<const i: i32> Foo<i, TWO> {
    pub fn foo() {}
}

@workingjubilee workingjubilee added requires-nightly This issue requires a nightly compiler in some way. requires-incomplete-features labels Mar 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-generics Area: const generics (parameters and arguments) C-bug Category: This is a bug. F-generic_const_exprs `#![feature(generic_const_exprs)]` requires-incomplete-features requires-nightly This issue requires a nightly compiler in some way.
Projects
None yet
Development

No branches or pull requests

4 participants