Skip to content

Check for "constants we match on must be PartialEq" misses lifetime-dependent impls #121007

Open

Description

@RalfJung

The following should trigger a warning that we can only match on PartialEq consts, but it doesn't: (example by @lcnr, then slightly tweaked)

use std::marker::PhantomData;

struct Inv<'a>(PhantomData<*mut &'a ()>);

// This type is only sometimes `PartialEq`.
impl PartialEq for Inv<'static> {
    fn eq(&self, _: &Inv<'static>) -> bool {
        true
    }
}

impl<'a> Inv<'a> {
    // The value `None` makes this have structural equality for any type `Self`.
    const NOT_STATIC: Option<Self> = None;
}

fn foo<'a>(x: Option<Inv<'a>>) {
    match x {
        Inv::<'a>::NOT_STATIC => (),
        Some(_) => panic!()
    }
    
    // Enabling the next line confirms that the type does
    // indeed not implement `PartialEq`.
    //x == Inv::<'a>::NOT_STATIC;
}

fn main() {
    foo(None)
}

Here is another example of the same issue.

The problem is that we call predicate_must_hold_modulo_regions here, but only borrowck knows the actual lifetimes and borrowck has no idea that this trait obligation even exists.

We should leave some sort of trace in MIR that there is a PartialEq obligations to ensure borrowck can check this with the right lifetimes.

Activity

  1. added
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Feb 13, 2024
  2. fmease commented on Feb 13, 2024

    @fmease
    Member

    I guess we could do something similar to #105102?

  3. added
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    T-typesRelevant to the types team, which will review and decide on the PR/issue.
    A-lifetimesArea: Lifetimes / regions
    C-bugCategory: This is a bug.
    and removed
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Feb 13, 2024
  4. RalfJung commented on Feb 13, 2024

    @RalfJung
    MemberAuthor

    Maybe? I have absolutely no idea what that PR does.^^ I don't really know anything about our trait system implementation.

  5. lcnr commented on Feb 13, 2024

    @lcnr
    Contributor

    I guess we could do something similar to #105102?

    sadly not, the "type is copy" check can be self-contained and can therefore handle its region constraints by itself using infcx.resolve_regions. As patterns are part of MIR bodies, we have to check their region constraints together with the rest of the body during MIR borrowck. The implementation would instead be similar to https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/typeck_results/struct.CanonicalUserTypeAnnotation.html and https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Body.html#structfield.required_consts: we store a list of requirements which have to be true for the given MIR even though they aren't directly present in the source. We then check them during mir borrowck

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-lifetimesArea: Lifetimes / regionsA-patternsRelating to patterns and pattern matchingA-trait-systemArea: Trait systemC-bugCategory: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.T-typesRelevant to the types team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions