Skip to content

[ .. a] pattern breaks matches #6909

Closed
Closed

Description

@huonw

This should print ok, but prints not ok.

fn main() {
    println(match &[1] {
        [2, .. _] => "not ok",
        [.. _]  => "ok"
    });
}

The problem seems to be the [.. _] pattern, since if this is replaced by _ or a, it prints ok. It also prints ok when matching on an empty vector. (The use of _ is not important.)

Activity

  1. msullivan commented on Jul 31, 2013

    @msullivan
    Contributor

    Confirmed. Bugs where we actually generate the wrong code are pretty bad, so fixing this is probably decently high priority. Not sure it actually fits for a milestone, though?

  2. msullivan commented on Aug 3, 2013

    @msullivan
    Contributor

    OK, I've figured out what is going on. The problem is that the matcher is too strict when deciding what patterns are included in some condition. Essentially the problem is that it decides that the condition that are relevant are "length > 1" and "length > 0" and decides that [2, .. _] is the only pattern that matches "length > 1", which is obviously bogus. Fixing this seems a bit tricky, since we need to be able to properly expand out the patterns while still properly handling bindings.

    Note that this seems like a degenerate case, since the last pattern could just be replaced with a _, but there are more complicated and interesting things where this happens too.

  3. msullivan commented on Aug 6, 2013

    @msullivan
    Contributor

    Oh, no, there is a pretty simple solution to this. The trick is, when checking submatches generated by a vector length check, set it up so that if none of the subpatterns match, it goes to the next vector length check. I'm explaining it poorly, but it is a really simple fix.

  4. msullivan commented on Aug 8, 2013

    @msullivan
    Contributor

    Simple fix has problems, though. So have a more complex fix. Which also has problems. Still investigating.

  5. msullivan commented on Aug 8, 2013

    @msullivan
    Contributor

    OK, have it all fixed. Just trying to document it well at this point.

  6. added a commit that references this issue on Aug 21, 2026
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-codegenArea: Code generation

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions