Undeclared consts not caught in Option Explicit

[ghost]

Option _Explicit

Const TFL_WALK = &H00000002
Const TFL_CROUCH = &H00000004
Const TFL_BARRIERJUMP = &H00000008
Const TFL_JUMP = &H00000010
Const TFL_LADDER = &H00000020
Const TFL_WALKOFFLEDGE = &H00000080
Const TFL_SWIM = &H00000100
Const TFL_WATERJUMP = &H00000200
Const TFL_TELEPORT = &H00000400
Const TFL_ELEVATOR = &H00000800
Const TFL_JUMPPAD = &H00040000
Const TFL_AIR = &H00080000
Const TFL_WATER = &H00100000
Const TFL_FUNCBOB = &H01000000

Const TFL_DEFAULT = TFL_WALK Or TFL_CROUCH Or TFL_BARRIERJUMP Or TFL_JUMP Or TFL_LADDER Or TFL_WALKOFFLEDGE Or TFL_SWIM Or TFL_WATERJUMP Or TFL_TELEPORT Or TFL_ELEVATOR Or TFL_AIR Or TFL_WATER Or TFL_JUMPPAD Or TFL_FUNCBOB

If you erase part of the letters from the constants that are in the TFL_DEFAULT declaration (not in their individual declarations), you can see that it still gives an "OK" in the IDE message line. I tried it with several different constants in that expression and it still gave an "OK". With Option _Explicit enabled, it would be expected that the constant evaluator would catch constants that are not yet declared. It looks like constant declarations with fewer constants are caught but the message line says it is a compiler error rather than an undeclared variable/const.

[mkilgore]

Messing around with it, it's pretty clearly more broken than just an issue with Option _Explicit, you get nonsense values when using non-existent CONST variables.

From what I've worked out, variable names which aren't resolved to existing CONST variables don't get filtered out by Evaluate_Expression$(). The bad names then get passed to evaluateconst$(), and depending on how exactly you write your expression it will incorrectly pass the name of the variable you wrote to _CV(_INTEGER64, constvar$). The resulting value gets used in place of the variable name in your expression, completely screwing up the actual value.

I think I have a solution but I need to write a bunch more test cases to be confident with it. But basically, evaluateconst$() already collects type information on each 'block', but when evaluating the left and right side of an operator it doesn't actually check that type information. It seems like a little bit of extra logic after evalconstequ: to verify that et and btype(i) are not zero solves the issue.

[ghost]

Sounds good. Let me know when you want me to do any tests, if you need me to