Handle generic associated constants in const qualification for structural match

[ecstatic-morse]

#67343 started using const qualification for more precise structural match warnings. The idea is that const qualification should be strictly more precise than the current type visitor (search_for_structural_match_violation). However, const qualification is more conservative in the face of generic associated constants than the type visitor, which typically runs after substitution. This was the case in the example in #73431.

We will need to make const qualification handle all cases that search_for_structural_match_violation does before switching away from the latter.

[lcnr]

I am not completely sure how the FlowSensitiveAnalysis works, but at least for the parts I am familiar with it should be possible to change ConstQualifs::custom_eq to Option<&'tcx [Ty<'tcx>]> where all the Ty<'tcx> are projections/opaque types which are required to be structurally match but are still too generic.

i.e. The current custom_eq: false would then be Some(&[]) and custom_eq: true would be None.

Afaik this is only a problem when dealing with generic associated constants using other
associated constants/generic methods, so I am personally fine with drawing an arbitrary line where
we stop using value based reasoning here 🤔

trait Foo {
    const A: Self;
}

impl Foo for Option<f32> {
    const A: Self = None;
}

impl Foo for usize {
    const A: Self = 7;
}

struct A<T>(T);

impl<T: Foo> A<T> {
    const VALUE: T = T::A;
}

fn main() {
    match Some(1.0f32) {
        // I do not want to use value based reasoning for `T::A`,
        // so the following should error/warn because `Option<f32>` is not structurally match.
        A::<Option<f32>>::VALUE => (),
        _ => (),
    }

    match 42 {
        // This should be accepted.
        A::<usize>::VALUE => (),
        _ => (),
    }
}

[bjorn3]

This seems to happen for ui/consts/const_in_pattern/issue-73431.rs too.

[lcnr]

@bjorn3 what exactly do you mean here? https://github.com/rust-lang/rust/blob/master/src/test/ui/consts/const_in_pattern/issue-73431.rs was the issue which first hit this problem.

#73431 is similar to this part of my code snippet:

    match 42 {
        // This should be accepted.
        A::<usize>::VALUE => (),
        _ => (),
    }

[bjorn3]

DIdn't read the top-level comment properly. I just saw the warning while running the test suite with RUSTC_LOG=warn.

[lcnr]

Assigning P-medium as described here #73431 (comment)

[ecstatic-morse]

@lcnr Sorry I missed your comment.

it should be possible to change ConstQualifs::custom_eq to Option<&'tcx [Ty<'tcx>]> where all the Ty<'tcx> are projections/opaque types which are required to be structurally match but are still too generic.

This is indeed possible, although not with the current dataflow framework, which only works on BitSets of some index type. We would need to extend it to work on arbitrary lattices (in this case the set of all projections/opaque types ordered by inclusion). I've had this on the backburner for some time, but I might get around to it soon.

If we were to go this route, const qualification will become slower and more memory hungry, so like you I would prefer to avoid it. Given that, it seems we would need to break code like this to convert fully to a const-qualification-based approach. Presumably, having two layers of associated constants in a pattern is presumably something very few users care about. However, I don't think this meets the requirements for a breaking change, since the code isn't actually unsound.