Add a storage for the origin of const inference variables.

[lcnr]

We currently don't store the origin of const inference variables. This is needed to emit more helpful error messages.

For type inference variables, this is done using https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/struct.InferCtxtInner.html#method.type_variables and then
https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/type_variable/struct.TypeVariableTable.html#method.var_origin.

We use this to provide better diagnostics in case type inference fails:

rust/src/librustc_infer/infer/error_reporting/need_type_info.rs

Lines 198 to 201 in 9912925

	let ty_vars = &inner.type_variables();
	let var_origin = ty_vars.var_origin(ty_vid);
	if let TypeVariableOriginKind::TypeParameterDefinition(name, def_id) = var_origin.kind {
	let parent_def_id = def_id.and_then(|def_id| self.tcx.parent(def_id));

A similar mechanism should probably also be used for consts.

[varkor]

It would be good to have some examples of where diagnostics are subpar because of this missing feature, to decide if it's a prerequisite for stabilising min_const_generics.

[lcnr]

yeah, will look a bit into some interesting test cases here in the near future hopefully

[lcnr]

One issue here is something like this:

#![feature(min_const_generics)]

struct Foo;

impl Foo {
    fn bar(self) -> Foo {
        Foo
    }

    fn baz<const N: usize>(self) -> Foo {
        println!("baz: {}", N);
        Foo
    }
}

fn main() {
    Foo.bar().bar().bar().bar().baz();
}

which results in

error[E0282]: type annotations needed
  --> src/main.rs:17:5
   |
17 |     Foo.bar().bar().bar().bar().baz();
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: unable to infer the value of a const parameter

for baz<T> we instead get

error[E0282]: type annotations needed
  --> src/main.rs:17:33
   |
17 |     Foo.bar().bar().bar().bar().baz();
   |                                 ^^^ cannot infer type for type parameter `T` declared on the associated function `baz`

btw I am not actually sure if this issue makes sense, we already have the origin of const infer values stored, so
I don't actually think we need to add a new storage here 😆 we "just" have to use the current one

[pickfire]

Is there any suggestion for user on how to fix this?

[lcnr]

Not completely sure what you mean here @pickfire

Do you mean when the user encounters a type annotations needed error? If so, we should add a suggestion like the following if it's applicable

note: use the turbofish here, I know you want to

On working on this issue itself, I am not actually sure what this issue actually is about, as my initial reason for opening it was somewhat incorrect.

I do think we should further improve the error message when type inference gets stuck for const inference variables. I don't know the best way to do this though, so I can't really give any mentoring instructions here yet

[varkor]

I think the main reason this issue exists is that when type inference fails for type parameters, we already have lots of heuristics to suggest to the user how to correct it. We don't have any of those for consts yet. However, this might be something that we continue to improve over time, so there may not be any direct action we can take with regards to this issue now.

[pickfire]

note: use the turbofish here, I know you want to

Yes, I don't know how to solve const issue but it would be good to have some sort of guidance.

[varkor]

I've opened #76737 for the turbofish suggestion. Let's simply open new issues as we encounter problems, and then we can close this one.