Skip to content

ast: the id of a ref pattern conflated; has type T in some contexts and &T in others #18207

Description

@pnkfelix

While working on my follow-up to #17439 I rediscovered an old problem in our ast representation:

We usually act like you can unambiguously map a node_id to a single type for that node id. However, if you want to know the type of a pattern like the ref x in:

let t = Some(box 3i);
match t {
  Some(ref x) => ...,
  None => ...,
}

then you have a problem: are you trying to find the type of the thing that is being borrowed by the match (i.e. int in this case)? Or are you trying to find the type of x itself (&int in this case)?

The problem is that there is just one node_id for the entire ref <id> pattern, even though there are two distinct things that you are potentially trying to match.

Activity

  1. steveklabnik commented on Oct 27, 2015

    @steveklabnik
    Contributor

    @pnkfelix is this issue still valid?

  2. pnkfelix commented on Oct 27, 2015

    @pnkfelix
    ContributorAuthor

    @steveklabnik IMO it still is an issue. Its something internal to the compiler, but I wouldn't be surprised if it is a source of bugs (either old or new.)

    cc @rust-lang/compiler

  3. arielb1 commented on Oct 27, 2015

    @arielb1
    Contributor

    @pnkfelix

    This is semi-going-away with MIR, so not particularly important.

  4. eddyb commented on Oct 27, 2015

    @eddyb
    Contributor

    @arielb1 should we have tags for that sort of "fixed-by-MIR" thing?

  5. pnkfelix commented on Oct 29, 2015

    @pnkfelix
    ContributorAuthor

    Hmm I will need to review the MIR RFC ... while I understand that some analyses will be applicable to the MIR (and indeed, some of those will solely apply to MIR then, no more AST inputs), for some reason I assumed that we would still do some amount of type-related computations on the AST form. (Why did I think this? I guess mostly for lints that want type info... Or will those all be ported to operate on MIR somehow? Doesn't sound very linty at that point)

  6. brson commented on Apr 4, 2017

    @brson
    Contributor

    @pnkfelix still a problem you want fixed?

  7. added
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    P-lowLow priority
    on Apr 4, 2017
  8. pnkfelix commented on Apr 6, 2017

    @pnkfelix
    ContributorAuthor

    I don't know enough our current lints to judge if it is still a problem, so I will close.

  9. added a commit that references this issue on Oct 8, 2024
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

    P-lowLow priorityT-compilerRelevant to the compiler 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