return const array from impl function, loses const information

[robinvd]

When returning an const length array from an associated function the length is lost and it becomes a [T; _] array.

I tried this code:
(Playground)

#![feature(const_generics)]

struct X;

impl X {
    pub fn getn<const N: usize>(&self) -> [u8; N] {
        getn::<N>()
    }
}

fn getn<const N: usize>() -> [u8; N] {
    unsafe {
        std::mem::zeroed()
    }
}

fn test() {
    // works
    let [a,b,c] = getn::<3>();
    
    // cannot pattern-match on an array without a fixed length
    let [a,b,c] = X.getn::<3>();
    
    // mismatched types, expected array `[u8; 3]` found array `[u8; _]`
    let arr: [u8; 3] = X.getn::<3>();
}

I expected to see this happen:
all lines in test compile

Instead, this happened:
functions from the impl did not return a const array

Meta

rustc --version --verbose:

rustc 1.41.0-nightly (412f43ac5 2019-11-24)
binary: rustc
commit-hash: 412f43ac5b4ae8c3599e71c6972112e9be4758fa
commit-date: 2019-11-24
host: x86_64-unknown-linux-gnu
release: 1.41.0-nightly
LLVM version: 9.0

[robinvd]

@varkor I saw in #44580 (comment) that you would be able to help/mentor const_generics issues

I would like to give this issue a go, but have no idea where to start. Maybe you could give me some pointers?

[varkor]

This is a slightly more minimal reproduction:

#![feature(const_generics)]

struct A<const N: usize>;

struct X;

impl X {
    fn inner<const N: usize>() -> A<N> {
        outer::<N>()
    }
}

fn outer<const N: usize>() -> A<N> {
    A
}

fn main() {
    let i: A<3usize> = outer::<3usize>(); // ok
    let o: A<3usize> = X::inner::<3usize>(); // error
}

@robinvd: This is quite a surprising error to me: I don't have any immediate guesses as to what might be going on. We'll need to do a little investigation here. The error in the example above is:

expected `3usize`, found `3usize`

Clearly, these should unify, so the first step would be to work out why unification doesn't think they're the same value. Hopefully that'll give some clues. The main thing that's different about trait functions is that they have an extra (hidden) generic parameter, which is the Self type, so there's possibly an indexing issue here (the first generic parameter is Self, so that could be getting compared with N and causing issues). Feel free to do some digging — I'll try to update with more detailed instructions if I get a handle on what might be causing this.

[varkor]

The reason the values don't unify is because we hit this:

rust/src/librustc/ty/relate.rs

Line 578 in 760ce94

_ => Err(TypeError::ConstMismatch(expected_found(relation, &a, &b))),

where we have (something like)

a=Const { ty: usize, val: Unevaluated(DefId(0:17 ~ const_trait_error[317d]::main[0]::{{constant}}[3]), []) }
b=Const { ty: usize, val: Value(Scalar(0x0000000000000003)) }

For some reason, it's unable to evaluate one of the constants.

[varkor]

The issue is that in

rust/src/librustc_typeck/collect.rs

Lines 1429 to 1432 in 760ce94

	| Node::Expr(&hir::Expr {
	kind: ExprKind::Path(QPath::Resolved(_, ref path)),
	..
	}) => Some(&**path),

we only consider QPath::Resolved. We also need to handle QPath::TypeRelative, which occurs whenever we have a path A::B (like in X::inner).

[varkor]

I've done some refactoring to make the method a little clearer. The bit that needs fixing now is:
master...varkor:const_generics-assoc-method#diff-4ed25c00aceb84666fca639cf8101c7cR1512
What I'd like to be able to do here is something like tcx.typeck_tables_of(def_id).type_dependent_def(hir_id), but this causes a cycle error.

[robinvd]

slightly unrelated. I tried some things yesterday, but my edit/compile cycle was 9 minutes with ./x.py test -i --stage 1 src/test/ui/const-generics/const-parameter-in-impl.rs --keep-stage 1. Is this just how big the rust compiler is?

[varkor]

It does take a little while to compile rustc, yes. I'm using the suggestion options in the rustc guide and it takes 3 – 4 minutes on my computer after making changes in librustc_typeck/collect.rs, for example.

[lcnr]

will probably get fixed by #71154