On 11/6/23 11:29, William F Pokorny wrote:
> 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.
I believe this fixed in the yuqk fork - in that lack of a semicolon is
now flagged as an error. Only took a week... :-(
Details for those interested.
Added an optional parameter in hereViaRValue defaulted false to:
called from Parser::Parse_RValue() and set true. Plus to
Parse_Express(expr, &terms, true)
called from Parser::Parse_Declare() and set true.
Plus to a set of expression related functions and calls in
parser_expressions.cpp so the proper indication of the 'right value
parsing' state exists in the function called Parser::Parse_Num_Factor()
where the vector dot access parsing happens near the bottom.
It appears when the dot access methods were coded, the right side
parsing state was never extended down into Parse_Num_Factor(). Further,
necessary checking for semicolons was never created. Such checking needs
to know whether the parser was in a right hand value parsing state.
This despite code being used where the dot access bit sometimes,
necessarily, is triggering the execution of directives coded right in
the middle of other work parsing work(a).
(a) - The triggering by way of a side effect of somewhere down the call
chains grabbing directive tokens while the parser is in a state which
allows the mid stream directives.
What all this means.
In the yuqk fork, the vector form of tuple / batch / list ID assignments
should work. Further, due the additional checking down in the dot access
methods for semicolons, it should be much less likely other non-tuple
form vector type assignments can cause unwanted side effects due the
lack of a semicolon. It would have been complicated SDL code which fell
into the trap previously. If users previously tripped it, and got
confusing results, my bet is they probably simplified their code - and
things began to work.
I offer no equivalent v3.8 parser fixes beyond what can be found in my
code or the description herein. Partly, this because I leaned on some
newer yuqk / v4.0 parser functionality for the fix but, the update is
complicated and I'm not going to try and replicate it in another version
of parser code.
Disclaimer. There are simply too many paths into Parse_Num_Factor() for
me to be 100% sure all situations which could be a problem are fixed. My
test cases are clean... It's better than it was.
Post a reply to this message