fix type of const params in assoc fns.

[lcnr]

extends and blocked on #70223

fixes#70273

r? @eddyb cc @varkor

[eddyb]

<S as T<123>>::f::<456>() should also work, if you added a const param to f as well.

[lcnr]

will add a test

[eddyb]

I mean you'll need to implement it, it won't work with the current approach.

[lcnr]

for whatever reason adding a const param to f actually prevents the ice. not quite sure why, but this is new behavior so lets add a test for it

The following works on the current nightly.

#![feature(const_generics)]//~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crashtraitT<constA:usize>{fnl<constN:usize>() -> usize;fnr<constN:usize>() -> usize;}structS;impl<constN:usize>T<N>forS{fnl<constM:usize>() -> usize{N}fnr<constM:usize>() -> usize{M}}fnmain(){assert_eq!(<SasT<123>>::l::<456>(),123);assert_eq!(<SasT<123>>::r::<456>(),456);}

playground

[eddyb]

Oh, oops, it's because both the trait and the method have the exact same number of parameters and the same types. Make one of them a bool instead of usize, then you should see how it thinks the method segment has the trait's parameter (which is wrong).

[lcnr]

jup. Quite surprisingly, using usize and u16 works 🤔
but using bool and usize does not work on nightly rn

[eddyb]

Yes, because the integer literals will work with any integer type.

[lcnr]

I am going to experiment with using the res of the segment instead of the path.

Closing this for now as I don't know how long this will take.