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 
column number.

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 
different situations.


> 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