[const generics] symbol `foo` is already defined

[oli-obk]

Const generics causes monomorphization to compare constants by identity instead of structurally. This means that two different references to equal data will compare as unequal.

The root problem is in

rust/src/librustc_mir/monomorphize/collector.rs

Line 338 in 3c1d9ad

if !visited.lock_mut().insert(starting_point.clone()) {

which puts the Instance of a function into a FxHashSet. Since the Instance's substs contain constants, hashing these constants will cause structurally equal constants to have different hashes.
For HashStable this has been solved by hashing the actual data and not things like pointers. For comparison we have TypeRelation which does a more appropriate version of comparison.

I tried this code:

#![feature(const_generics)]

pub fn function_with_bytes<const BYTES: &'static [u8; 4]>() -> &'static [u8] {
    BYTES
}

pub fn main() {
    assert_eq!(function_with_bytes::<b"AAAA">(), &[0x41, 0x41, 0x41, 0x41]);
    assert_eq!(function_with_bytes::<{&[0x41, 0x41, 0x41, 0x41]}>(), b"AAAA");
}

I expected to see this happen: successful compilation just as if the type were &'static [u8]

Instead, this happened:

error: symbol `_ZN10playground19function_with_bytes17h85b0fd4613beba85E` is already defined
 --> src/main.rs:3:1
  |
3 | / pub fn function_with_bytes<const BYTES: &'static [u8; 4]>() -> &'static [u8] {
4 | |     BYTES
5 | | }
  | |_^

cc @varkor

cc @rust-lang/wg-const-eval It's a footgun that ConstKind and especially ConstValue can be compared for equality. Technically a ConstKind::Unevaluated is value/structurally equal to any other ConstKind. We may need that Eq impl for query return value hashing though, not sure.

[oli-obk]

There's two ways that I see that we can use to go forward:

1. remove Eq, PartialEq, Ord, PartialOrd, Hash from ConstValue and everything that depends on it. This requires some wrapper helpers (forwarding Eq to TypeRelation) around the return values of queries as query return types need Eq impls I think.
2. manually implement Eq, PartialEq, Ord, PartialOrd, Hash to use TypeRelation and HashStable. This may cause some things to become slow, as more work is done. We could benchmark this as a first try.

[eddyb]

TypeRelation isn't relevant here, you should have fully normalized constants by the time of the monomorphization collector (i.e. no CosntKind::Unevaluated), anything else is a bug.

Keep in mind types have the same problem with ty::Projection and ty::Opaque.

[oli-obk]

Ok, but even ignoring any ConstKind other than ConstKind::Value, the only place that correctly compares ConstKind::Value is TypeRelation, so we can pull that out as a common function for comparing ConstKind::Value. That'll still have to have access to a TyCtxt in order to be able to fetch the Allocation that a const pointer points to.

[eddyb]

You shouldn't need TypeRelation to compare fully normalized monomorphic things, interning should deduplicate everything by-typesystem-semantic-value.

[eddyb]

Oh, as a side mention, if you need to validate that the typesystem doesn't contain any non-deduplicatable constants (e.g. &STATIC references), we can do it in WF checking, post-#70107.

[varkor]

I don't think we can run into issues with min_const_generics here, so not marking it as blocking.

[lcnr]

this is now fixed by valtrees:

needs test though:

#![feature(adt_const_params)]

pub fn function_with_bytes<const BYTES: &'static [u8; 4]>() -> &'static [u8] {
    BYTES
}

pub fn main() {
    assert_eq!(function_with_bytes::<b"AAAA">(), &[0x41, 0x41, 0x41, 0x41]);
    assert_eq!(function_with_bytes::<{&[0x41, 0x41, 0x41, 0x41]}>(), b"AAAA");
}