Improve faulty parsing of byte array literal (alternative version) #12818
Conversation
|
Maybe a discussion point (that also applies to #12817 ): the choice currently (and previously) done in case of error is to consume elements until a closing bracket |
|
I restarted the CI run and now this looks odd: It shows an error and I can not restart it anymore. Very very odd |
|
I think I did the conflict resolution wrong, the tests should have been added, not removed |
privat
force-pushed
the
improve-faulty-parsing-bytearray-alt
branch
from
468be24 to
f81ebb6
Compare
|
I rebased the commits to solve the merge |
…arsing-bytearray-alt
privat
force-pushed
the
improve-faulty-parsing-bytearray-alt
branch
from
f81ebb6 to
5d21ae0
Compare
|
oops. I shouldn't have solved the conflicts by hand in a text editor before the first coffee. |
|
tests are ok (but the windows box is dead) |
|
I like this solution better than the alternative, as here we know that we have a wrong ByteArray |
Parsing keeps the content of faulty elements in byte array literals by interpreting the faulty element as classic literal array elements (instead of just skipping them), and put them in an instance of
RBLiteralByteArrayErrorNodeinstead of in a faultyRBLiteralByteArrayNodeinstance as previously.The old way was fragile and broke clients (including compilation and execution), since a
valueof aRBLiteralByteArrayNodecan only contain bytes.Note: This is an alternative implementation of #12817 — there can be only one. that is somewhat simpler (you can compare the diffs) and more robust.
The only drawback is that
RBEnglobingErrorNode(the superclass of the error node used) need love:contentsshould have as(I think)But I consider these to be out of the scope of the PR and should be solved independently.