Syntax tightening needed on special line beginnings #798
Conversation
A line beginning with a comment, a section name, or an equals decorator ('===') would still have the rest of that line parsed as if it were part of a normal line for the current section. However, since no [section-related] start-of-line processing had occurred for that line, the objects accessed during parsing could be stale, incorrect, or non-existent. This prevents this by disallowing additional content after section names and equals decorators, and making comments transparent to start-of-line detection. (It also whites-out start-of-line comments for additional transparency to later processing.)
(Note: This commit also makes PuzzleScript less tolerant to stray right parentheses.)
BentSm
changed the title
|
A note to self: this also fixes things like (comment)homepage www.asdasdas.net not working |
| if (ch === '(' && state.tokenIndex !== -4) { // tokenIndex -4 indicates message command | ||
| stream.next(); | ||
| state.commentLevel++; | ||
| } else if (ch === ')') { |
There was a problem hiding this comment.
Just a note to self: this is a bit that just gobbles up all right-parentheses without so much as dropping an error if something's amiss.
|
Ok, I had a look at this: firstly, I would like to commend you on your very good bug finding, reporting + example construction skills. I thought I'd be able to get this tests vetted + in today, but I won't so I'm leaving this note as a note to future me (Nothing necessarily actionable on your part, @BentSm, I'll make whatever changes are needed as part of the pull-review / understanding the behaviour better [I need to be very very careful I understand this because it's a change to such an important/delicate part of the engine ]): I think I don't want to modify the really awful old pony test case - I think I'd prefer to keep it working (the ponies one with random close-parens scattered about), so I'll look at this another day with a view to preserving it. (note to self: I think it might be just a thing of reintroducing that deleted bit of code in the pull-request). Thanks again :) |
|
Thank you again very much for alerting me to this issue. I've taken most of the changes by hand (cf fix for #810), but not all (the closing bracket stuff I deal with differently), so as to preserve compatability with the legacy test cases. |
Compiler now uses the parser to parse the legend section rather than having its own very primitive parsing. I hope this doesn't break anything - I should probably throw some more examples with weird unicode at it.... related to #798 [Also includes test-cases, and fixes up some old ones due to me improving error messages, and removed a superfluous/misleading error messages from the lime rick examples]
2 participants
A line beginning with a comment, a section name, or an equals decorator ('===') would still have the rest of that line parsed as if it were part of a normal line for the current section. However, since no [section-related] start-of-line processing had occurred for that line, the objects accessed during parsing could be stale, incorrect, or non-existent. This prevents this by disallowing additional content after section names and equals decorators, and making comments transparent to start-of-line detection. (It also whites-out start-of-line comments for additional transparency to later processing.)
(These commits also make PuzzleScript less tolerant to stray right parentheses)
For instance:
(Ouch.)
Or: (This compiles just fine... Playing is another matter altogether.)
Also, an example of how stray right parentheses can be problematic: