You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
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?
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.
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.
Activity
msullivan commentedon Jul 31, 2013
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?
msullivan commentedon Aug 3, 2013
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.
msullivan commentedon Aug 6, 2013
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.
msullivan commentedon Aug 8, 2013
Simple fix has problems, though. So have a more complex fix. Which also has problems. Still investigating.
msullivan commentedon Aug 8, 2013
OK, have it all fixed. Just trying to document it well at this point.
Merge rust-lang#6909