On 11/6/23 10:04, William F Pokorny wrote:
> All seems to work except the mandatory semicolon bit is not enforced by
> the parser!
> This means the following code runs without complaint, but incorrectly.
> #declare <A0,A1,A2> = <3,2,1>; // This works.
> #declare <A0,A1,A2> = <1,2,3> // This only appears to work
> // Meaning no
> #debug concat("A0 = ",str(A0,3,1),"\n")
> #debug concat("A1 = ",str(A1,3,1),"\n")
> #debug concat("A2 = ",str(A2,3,1),"\n")
> #error "Stopping at parse test end\n"
> The exposure made worse because in other applications, the tuple ID
> assignments treat the trailing semicolon as optional.
An update. It was apparent once I dug through the code that clipka
intended for the vector form to work like other tuple assignments in not
needing a trailing semicolon, but allowing one.
The vector tuple form is broken in all parsers since mid 2015 in not
working as intended or failing for lack of semicolons.
Try as I might over the past few days, I've not been able to make it
work as intended without breaking the general ability to declare things
A capability which looks to be the primary reason we sometimes need
semicolons. We need to somehow mark the end of all the '#' language
directives where we allow them in the middle of a other parsing.
It's also very much related to how grabbing a single token can sometimes
cause the parser to eat up a bunch of scene code and do nothing with it.
This last is exactly what is happening in the sample code up top. It is
what was happening with this recent bug find too:
I've take a run or two at forcing the semicolon in this one tuple /
batch assignment type, but so far I'm failing there too. That said, I
think this the more likely outcome at the moment.
Post a reply to this message