You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This cannot be implemented easily because the parser insists on being really stupid. It never ceases to amaze me that something as simple as 'block-scope', 'local' and 'global' is so confusing for a parser.
The parser->globals field is in fact not 'global' in the sense that globals are stored there exclusively. No, not at all. For some insane reason locals that need to be used immediately are stored there because all of them are guaranteed to be generated.
Blindly putting something into an ast_block's locals vector won't work for function locals if they need to be used because generation happens way later. The parser's _locals is just downright stupid in that it too is not actually locals but rather the current block-scope's parent block-scope. Then to make it even more confusing the hashtables for searching for the globals which contain locals also finds aliases, and for some reason there are locals that search for variables up to a 'certain' block-scope depth (what the actual fuck?). The hashtables have no relation to locals or globals at all. To make it worse, for some insane reason, the parser has 'variables' which are globals and locals and labels and parameters and everything else under the sun.
For some other pointlessly nonsensical reason an ast_value that is CV_CONST and hasvalue=true is in fact uninitialized, even when expression.flags contains AST_FLAGS_INITIALIZED
Enums cannot be local to block scope, they must be global. Suggest allowing block-scope enums
The text was updated successfully, but these errors were encountered: