Permit multi-segment paths as const generic arguments without {}

[varkor]

mod m {
    pub const N: u32 = 0;
}

struct S<const X: u32>;

fn main() {
    let _ = S::<m::N>; // error[E0573]: expected type, found constant `m::N`
}

(Playground link)

There's no reason this couldn't be supported, but it's nontrivial to implement: we need to wait until type-checking to disambiguate between types and constants due to associated types (see this Zulip conversation).

This is essentially the same issue as #66615, but it's more visible (and affects min_const_generics).

[petrochenkov]

The treatment should be somewhat similar to imports, for every path in a generic argument context resolve should produce a PerNS<Option<Res>> instead of just Option<Res> (i.e. resolve the path in all namespaces).

Then that path is effectively lowered into two hir::Paths, each with its own resolution.
Except that we'll probably won't get away with cloning a path literally (what if it has items inside it? what about node IDs?) and will have to introduce some kind of hir::Path2 with two Resolutions instead.

[varkor]

On one hand, this is an annoying papercut, and essentially a special case that users would have to learn. On the other hand, it's quite a lot of complexity for a small issue. (Though if we end up fixing this issue in the future, after min_const_generics has been stabilised, that could be annoying too, because we'd want to warn about unnecessary {} at some point.)

[leonardo-m]

Generally special cases in both a compiler and a language should be avoided. Writing S::<{m::N}> isn't too much bad, but the syntax here is already a special case compared to the second part of the [T; N] array syntax...

[RalfJung]

If it is only the syntax concern that stops this, then why is S::<{m::N}> not part of min_const_generics?

[varkor]

If it is only the syntax concern that stops this, then why is S::<{m::N}> not part of min_const_generics?

{N} is special-cased to be treated as N in min_const_generics, which is not the same as the expression N (you can see this by writing {{N}}, which is not special-cased). This issue is about also special-casing m::N. We'd like to do this, but there are implementation difficulties. In const_generics, {m::N} is just treated as an expression, but we wanted to only allow the special cases in min_const_generics, because the implementation of const generics with arbitrary expressions was still buggy.

[hydra]

I bumped into this again today after using a constant from another crate via a fully qualified name as an argument to a generic struct, and would suggest that the compiler error message be improved in the interim.