core.match

Vector match "underflow" => IndexOutOfBoundsException

Details

  • Type: Defect Defect
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Completed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Patch:
    Code and Test

Description

This fails with 0.2.0-alpha12:

(match [[:x]]
  [[m n & _]] 1)

I expect nil, but an unguarded subvec call throws an IndexOutOfBoundsException.

A WIP patch is attached that fixes this (perhaps incorrectly) but which produced regressions (outside of core.match), e.g.

(match [[[:x "t"]]]
 [[[:x & a] & tail]] :a
 [[[:y & p] [:x & a] & tail]] :b)
=> nil

The patch also "fixes" this (by changing pattern-compare behaviour for rest VectorPattern s, but that leads to a regression in the vector-pattern-rest-2 testcase in core.match.

(Original discussion with further background here.)

Activity

Hide
David Nolen added a comment -

The patch looks like it's going in the right direction. Can you explain why your patch without the pattern-compares case causes the second example to fail?

Show
David Nolen added a comment - The patch looks like it's going in the right direction. Can you explain why your patch without the pattern-compares case causes the second example to fail?
Hide
Greg Chapman added a comment -

FWIW, I've been using the patch described here, and haven't yet run into any problems, though I also haven't used core.match that much. Anyway, with the change to subvec-inline, both of the cases here act as expected (producing nil and :a, respectively).

(I note looking at my patch that I'm doubly-evaluating ocr in the second overload; obviously that should be fixed with a let binding).

Show
Greg Chapman added a comment - FWIW, I've been using the patch described here, and haven't yet run into any problems, though I also haven't used core.match that much. Anyway, with the change to subvec-inline, both of the cases here act as expected (producing nil and :a, respectively). (I note looking at my patch that I'm doubly-evaluating ocr in the second overload; obviously that should be fixed with a let binding).

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: