Partial fix for #13747 assertion in Token::update_property_info() (no variable declaration in static_assert)

[chrchr-github]

Or maybe fIsName should not be set?

[danmar]

I didn't look carefully but this feels rather hacky to me. So we would still get such assertions for:

something(true && false);

spontanously true should not be seen as a valid variable type and false should not be seen as a valid variable name if it's a c++ file.. but I assume you looked into that already?

[chrchr-github]

This something(true && false); seems to work as expected in an executable scope, but of course static_assert can appear in global or other scopes.

[chrchr-github]

C23+ also has static_assert.

[danmar]

And you can achieve a static assertion with a macro. I have seen such:

#define STATIC_ASSERT(X)    char  dummy  [ (X) ? 1 : -1 ]

This can be used in the global scope

[chrchr-github]

My comment about the global scope was intended as a justification why static_assert needs special handling.

[danmar]

yeah .. I wanted to point out it would also be good to cover STATIC_ASSERT etc..

so such testcase would be good imho:

    const char code[] = "STATIC_ASSERT(true && false);\n";
    const char expected[] = "1: STATIC_ASSERT ( true && false ) ;\n";
    ASSERT_EQUALS(expected, tokenize(code));

[danmar]

my first question was if you looked into if true and false can be handled more intelligently instead? It does not seem impossible to determine that true && false is not a valid C++ variable declaration.

[chrchr-github]

my first question was if you looked into if true and false can be handled more intelligently instead? It does not seem impossible to determine that true && false is not a valid C++ variable declaration.

This is, among other things, tied to %type% matching true|false. I didn't want to touch that in this PR.

[chrchr-github]

yeah .. I wanted to point out it would also be good to cover STATIC_ASSERT etc..

so such testcase would be good imho:

I believe this currently leads to an internalError. But there were no such errors in daca when I last checked, so code like that seems to be uncommon in C++.