fix(parser): support optional chaining on slice expressions - #945
fix(parser): support optional chaining on slice expressions#945eyupcanakman wants to merge 1 commit into
Conversation
cf006b6 to
d239381
Compare
sanmaxdev
left a comment
sanmaxdev
left a comment
There was a problem hiding this comment.
The nil case works, but this also moves concrete non-slice values past the checker. I reproduced it with let x = 1; x?.[0:1]: compilation succeeds, then execution returns cannot slice 0. Please keep concrete non-slice values as compile-time errors and add a regression case.
| case reflect.String, reflect.Array, reflect.Slice: | ||
| // ok | ||
| default: | ||
| if node.Optional { |
There was a problem hiding this comment.
This suppresses the checker error for every concrete non-slice type, not only nil. Since OpJumpIfNil only skips nil values, let x = 1; x?.[0:1] compiles and then fails during execution with cannot slice 0. Please preserve the compile-time error for concrete non-slice values and add a regression case.
There was a problem hiding this comment.
The checker now only skips the error for a nil nature, so concrete non-slice types fail at compile time again. Regression cases are in test/issues/822.
Allow nil?.[from:to] to return nil instead of erroring with "cannot slice unknown". Add Optional field to SliceNode, propagate it through parser, checker, and compiler using the same pattern as MemberNode optional chaining. In the checker the bypass is limited to a nil nature, so a concrete non-sliceable type is still a compile-time error, and the slice bounds are still checked. Fixes expr-lang#822
d239381 to
8b4f396
Compare
2 participants
foo?.[0:1]panics at runtime whenfoois nil. Optional chaining works for member access (foo?.bar) throughMemberNode.Optional+OpJumpIfNil, butSliceNodehad no equivalent.Added the same
Optional+OpJumpIfNilpattern toSliceNode.Fixes #822