Am 24.03.2019 um 15:59 schrieb William F Pokorny:
> That was painful to run down, but changing Parser::IsEndOfInvokedMacro()
> in the file source/parser/parser_tokenizer.cpp as in the attached file
> fixes the issue.
Well, that's a lead I might investigate. But as you don't seem to be
confidently understanding what's going on, I'll be going with the
presumption that this is not a proper fix but just a patch.
> Have to admit I'm not sure even now I completely understand what was
> happening (how it could happen perhaps). We seem to have been comparing
> structures in the original - which I don't think c++ does by default?
> return (Cond_Stack.back().PMac->endPosition ==
> CurrentFilePosition()) && ...
> If this true though, why no compile warning or error?
That's easily explained: The data is of type `LexemePosition`, which is
a struct defining an overloaded comparison operator.
(In C++, structs and classes are the same category of beasts. The only
semantic difference between `struct` and `class` is the default member
and base class access: `struct` implies `public` by default, while
`class` implies `private` by default. According to the language
standard, it is even perfectly valid to pre-declare a type as `struct`
and later define it as `class` or vice versa.)
The `LexemePosition` type holds a file offset, as well as a line and
Comparison is done by file offset, but the code also features an
assertion, which tests whether the comparison by line and column yields
the same result. If the assertion fails, debug builds bomb (i.e. core
dump or break into a debugger), and non-debug builds throw an exception
to trigger a parse error.
(Usually such assertion tests are only enabled in debug builds, but in
the parser they're currently deliberately enabled in all builds, because
I don't fully trust my current understanding of the parser and the
refactoring work I have based on that understanding.)
If `Cond_Stack.back().PMac->endPosition == CurrentFilePosition()` throws
an exception, it means either of two things:
(A) The positions compared are from two different files, which means the
calling code has failed to check whether it is even in the right file.
(B) The line/column tracking is buggy, and yields different positions in
> In any case, once
> in a while on the structure compare some error got thrown and caught by
> the parser code and no message was set which is why we get the unhelpful
> generic something wrong message.
This is the default error message for failed assertions. Unfortunately
somewhere along the chain of error message handling the location
information for the assertion seems to be lost, the original exception
should include the nformation that it was triggered in `parsertypes.h`
line 62 (in my version of the file at any rate), maybe even that it was
in function `LexemePosition::operator==` (depending on compiler). Maybe
it's worth investigating and fixing that.
Post a reply to this message