Unable to inference a result type of an indexing operation

[ztlpn]

Hi everyone, I was under impression that type inference involving arrays should work, but it is behaving weirdly:

fn foo(bar: [usize; 2]) -> usize {
    let baz = bar[1];
    baz
}

fn foo2(bar: [usize; 2]) -> usize {
    let baz = bar[1];
    return baz;
}

fn foo3(bar: [usize; 2]) {
    let baz = bar[1];
    println!("{}", baz);
}

fn main() {
    let foo4 = |bar: [usize; 2]| -> usize {
        let baz = bar[1];
        baz
    };

    let foo5 = |bar: [usize; 2]| -> usize {
        let baz = bar[1];
        return baz;
    };

    println!(
        "{} {} {} {}",
        foo([1, 2]),
        foo2([1, 2]),
        foo4([1, 2]),
        foo5([1, 2])
    );
    foo3([1, 2]);
}

The type inferred for baz is usize for foo1 and foo2 (good), {unknown} for foo3 and foo4 (I would expect that type inference is not too hard there) and () for foo5 (plain wrong!).

Tested with the latest master (4444192)

Edit: there are two separate issues: type in foo3 and foo4 is not inferred because it is an indexing operation and is inferred incorrectly in foo5 because of the return statement in the closure (#2547 )

[flodiebold]

These are not related to arrays -- it's indexing expressions which aren't implemented yet. I think there's nothing stopping us from doing that, just no-one has done it yet.

So all these indexing expressions get inferred as unknown; in cases foo1, foo2, foo4 and foo5 we then infer the type of baz from the later usage, except in foo5 we get it wrong because we don't handle return in closures correctly (we use the enclosing function's return type), which is another bug.

[ztlpn]

@flodiebold Oh, you are right - looks like I didn't compress the test case enough, the simplest case would be

fn main() {
    let foo = || {
        return 1;
    };
}

(foo gets resolved to || -> ()). Also, looks like explicit return type (let foo = || -> usize {...) in a closure gets ignored. Is this a known issue?

[flodiebold]

Yeah, that's the second thing I wrote -- when handling return, we don't handle closures and go straight to the surrounding function. It's a known issue to me, but we don't have an issue for it here yet 🙂

[ztlpn]

Ok, I've split the issue into two so that there is some place to subscribe to and track progress.

[oxalica]

It seems not fixed yet.

[flodiebold]

I think the main remaining issue is performing autoderef for indexing operations. We might also need to apply unsized coercions in the case of arrays, I haven't checked.

[flodiebold]

I now checked and we do need to perform unsized coercions.

Also, there's an issue with type variable fallback in the common case of some_array[1], because Chalk doesn't know that the only impl that can apply is the one for usize (but rustc is able to make this inference). Also also, this won't work in many cases until rust-lang/chalk#234 is fixed.

So to summarize, to get inference for array[0] to work, we need to:

• do autoderef for indexing
• do unsized coercions for indexing (as for method calls), Unsized coercions for method call receivers #2670
• fix inference for integer variables in Chalk (somehow; Handling integer/float variables chalk#327)
• fix ambiguity problems in Chalk, Ambiguity problems with associated types chalk#234

How complicated such a simple expression can be 😄

[flodiebold]

Autoref and unsizing are done now.