use visitor for #[structural_match] check

[pnkfelix]

This changes the code so that we recur down the structure of a type of a const (rather than just inspecting at a shallow one or two levels) when we are looking to see if it has an ADT that did not derive PartialEq and Eq.

Fix #61188

Fix #62307

Cc #62336

[rust-highfive]

r? @varkor

(rust_highfive has picked a reviewer for you, use r? to override)

[pnkfelix]

The way this is written might be bad for performance, since it is doing a visit of the type structure on every call to const_to_pat, and that routine calls itself recursively.

Thinking further on this, we might be able to avoid that cost by factoring the recursive traversal into a subroutine, and then doing the type traversal once, at the start of const_to_pat, before starting the recursive traversal. (But I would want to be careful about not overlooking cases where the problematic ADT occurs more deeply in the input.)

[pnkfelix]

(I've left the WIP marker because I want to add tests that double-check the refactoring in commit 9db458f300a1f0c844071a41a547bd6294c99610 didn't break things.)

[Centril]

Just some nits...

[Centril]

Indentation is weird here, should be:

fn search_for_adt_without_structural_match<'tcx>(
    tcx: TyCtxt<'tcx>,
    ty: Ty<'tcx>,
) -> Option<&'tcx AdtDef> {
    ...

[matthewjasper]

Does this handle matching on const A: &[Option<NoDerive>] = ...?

[pnkfelix]

@matthewjasper no, it mishandles the case of const A: &[Option<NoDerive>] (as in, it fails to reject a pattern using that const).

The code also mishandles some other cases that I just discovered, some of which are regressions over the current master. So I need to fix that, and add corresponding regression tests.

• I wanted to double check the text of Restrict constants in patterns rfcs#1445 to make sure I understand the intended scope of that change
• its possible the RFC intended for us to use a shallow check of the attribute; i.e., that we would accept the case of a struct wrapping another struct, where the wrapper derives PartialEq and Eq but the wrapped type does not derive them and instead uses its own implementation.
• But I don't think that could have been the true intention, since allowing such side-stepping of the attribute via a wrapper struct seems like it would undermine the objectives of the RFC itself.
• (I suspect the reality is the RFC was written assuming a sort of recursive semantics, where converting the wrapper to a pattern would involve converting the wrapped struct to a pattern, which in turn would cause the wrapped struct to be checked. But this is not what currently happens, at least for &T, due to the way we sometimes dispatch to a PartialEq::eq call rather than expanding.)

I'll post a follow-up comment outlining the behavior on a set of cases after I finishing going through the analysis.

[pnkfelix]

Okay, that change 9db458f300a1f0c844071a41a547bd6294c99610 (to move the visit up above the recursive loop) broke (as in regressed) cases like these:

struct NoDerive(i32);

impl PartialEq for NoDerive {
    fn eq(&self, _: &Self) -> bool { false }
}

impl Eq for NoDerive { }

#[derive(PartialEq, Eq)]
struct WrapInline(NoDerive);

const WRAP_DIRECT_INLINE: WrapInline = WrapInline(NoDerive(0));

#[derive(PartialEq, Eq)]
struct WrapParam<T>(T);

const WRAP_DIRECT_PARAM: WrapParam<NoDerive> = WrapParam(NoDerive(0));

Independently of that change, regardless of where the visit is done, I/we also fail to correctly handle:

const WRAP_INDIRECT_INLINE: & &WrapInline = & &WrapInline(NoDerive(0));

const WRAP_INDIRECT_PARAM: & &WrapParam<NoDerive> = & &WrapParam(NoDerive(0));

[pnkfelix]

Okay so now I've removed commit 9db458f300a1f0c844071a41a547bd6294c99610 to avoid regressing cases that we were handling correctly before, and I've added 1e55df7a3ab2fca0ec35b884cf556af4b76d3624 because I've decided that we do need to visit the substs of an ADT (and just treat PhantomData<T> as a special case).

With that change in place, we handle @matthewjasper 's example correctly, as well as most of the other ones I identified.

The one case that this version continues to mishandle is this (play):

struct NoDerive;

impl PartialEq for NoDerive {
    fn eq(&self, _: &Self) -> bool { false }
}

impl Eq for NoDerive { }

#[derive(PartialEq, Eq)]
struct WrapInline(NoDerive);

const WRAP_INLINE: & &WrapInline = & &WrapInline(NoDerive);

fn main() {
    match WRAP_INLINE {
        WRAP_INLINE => { println!("WRAP_INLINE matched WRAP_INLINE"); }
        _ => { println!("WRAP_INLINE did not match WRAP_INLINE"); }
    }
}

I think handling this case correctly (and also efficiently) will require deeper changes, though. E.g. a new bit in rustc::ty::TypeFlags.

• To be honest we might be better off trying to address finding our long-term solution to the structural-match problem rather than trying to plug all the leaks in #[structural_match]...
• But under the assumption that gathering consensus on a language problem like that will always take more time than you expect, I'll see about changing rustc::ty::TypeFlags in the short term.
• Update: I found a simpler way to deal with it: just traverse the fields and use a seen map for the &AdtDef's we've seen. (I wonder how many other passes are reimplementing this graph traversal themselves, either with seen: HashSet<&AdtDef> or HashSet<Ty>)

[pnkfelix]

Okay, so now I've added a more complete traversal that addresses the problem posted above.

But doing that then led me to ask some questions, like:

• "Now that I am traversing the fields, should I stop traversing the substs of an ADT?"
  • (probably yes, especially given the next bullet...)
• "How should unsafe pointers be handled?"
  • (probably should not recur on the T in *const T)

The fact that I'm asking these questions leads me to think three things:

• I need to add more tests
• The implementation here needs more work
• This probably needs to be initially deployed with a warning cycle. (I don't think that will be too hard to do, even.)

[Centril]

r? @nikomatsakis since they wrote the original RFC.

[pnkfelix]

Turning this from an error to a warning exposes more issues; e.g. the point where we are doing this check in the compiler's control flow, namely lowering from HIR to HAIR, is a spot where for some reason we may attempt to lower the same input multiple times, and thus the warning gets issued redundantly.

(The very fact that we are re-running lower on the same input seems like a worrisome thing, just in terms of compiler efficiency...)

So, do I focus on making this a LintPass rather than doing it in lowering? Or do I try to figure out why lowering is being run multiple times on the same input?

• Update: the answer about the latter seems to be that we call lower_pattern from both hair::pattern::Pattern::from_hir and from hair::pattern::check_match. I guess that should be at most a 2x cost, and most patterns tend to be small. (But it also strikes me as unfortunate redundant work.)
• In any case, given the answer above, it seems like I can readily resolve my issue by having the PatternContext know whether it should issue lints or not (and then the different contexts that create it can adjust it accordingly.)

[pnkfelix]

Okay I'm finally narrowing in on a solution that I'm happy with, I hope.

I am going to try to deploy this as a future-compat lint; I've filed #62411 as a tracking issue for that.

[pnkfelix]

(last commit 02af3ca was result of my realization that while I had added special case code to preserve existing behavor for empty-arrays (#62336), I hadn't put in a corresponding unit test. That's fixed now.)

[nikomatsakis]

My 2 cents:

• r=me on the PR itself.
• it seems like a good idea to do a crater run (with this lint level set to deny) to get an idea of the impact.
• I do think we ought to resolve this question around constants. This feels like something where, if we had a functional working group around const generics, they could ultimately resolve it.

[pnkfelix]

hmm, looking at #36891, I now wonder: should we use a different name than non_structural_match for the future-compat lint here? I had considered e.g. indirect_non_structural_match...

Having said that, I nonetheless plan to let this PR land as is. We can bikeshed the names while the PR is on nightly (right?)

Update: ha ha, I'm losing my marbles; the PR has already named the lint indirect_structural_match. Its just the tracking issue for the lint that has the wrong name.

[pnkfelix]

@bors r=nikomatsakis

[bors]

📌 Commit b0b64dd has been approved by nikomatsakis

[bors]

⌛ Testing commit b0b64dd with merge c6a9e76...

[bors]

☀️ Test successful - checks-azure, checks-travis, status-appveyor
Approved by: nikomatsakis
Pushing c6a9e76 to master...