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
Sorry, something went wrong.
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.
Sorry, something went wrong.
| 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.
Sorry, something went wrong.
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.
Sorry, something went wrong.
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
foo?.[0:1] panics at runtime when foo is nil. Optional chaining works for member access (foo?.bar) through MemberNode.Optional + OpJumpIfNil, but SliceNode had no equivalent.
Added the same Optional + OpJumpIfNil pattern to SliceNode.
Fixes #822