untyped prepass, use for generic procs/template in compat mode #577
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Not fully implemented, missing types, type decls and routines, but these can hopefully be done later.
The generic and template prepasses are not too far apart and the attempt here is to implement them in 1 file, mostly based on the template prepass. I don't know every precise difference between the two and there might be mistakes but I'm still guessing this is easier to maintain than 2 files. Fixing old compiler bugs is a non-goal regardless.
The biggest difference is symbol definitions. Both the template and generics prepasses add symbols to the scope. Generics adds every single declared symbol as an
skUnknown
symbol, every single use of anskUnknown
symbol becomes an identifier (i.e. is injected). Templates do not add injected symbols to scope, instead storing a set of injected identifier names for them; but every gensym symbol is added to scope, having the corresponding symbol kind.The way they are combined here is generics now use injections instead of
skUnknown
, and injects are now somewhat scoped: an injected symbol defined in a scope will not be injected outside of that scope. For templates this would previously present as this bug:This implies a behavior change to templates, there is an off chance that code might have depended on this but it arguably should have already been the case. Worst case we can disable this scoping behavior in template mode. It should be 1 to 1 with generics though.
Injects are still tracked by a set of identifiers, each scope now tracks which identifiers it newly injected compared to the scopes above it, then the newly injected identifiers are removed from the inject set when exiting the scope. This means injected symbols are still checked before looking for symbols in scope, so stuff like this behaves the same as before:
I am not sure if we should handle this differently, it would most likely mean the inject behavior is moved to the scope object which has overlap with the hypothetical
untyped
identifier rules in #254. But this won't matter for a while.Other differences are:
withinMixin
(would prevent "undeclared identifier" errors which are no longer there)[]
etc, not sure if they have any differences between generics and templatesopenSym
as this is supposed to be for compatFinal note: Compat mode is currently global, meaning it is also active for templates/generic procs in the system module. Don't know if this will become a problem.
Edit: Windows CI implies compat mode is a problem with nifcache (thankfully only changes line infos and still works). Maybe just update hastur to wipe nifcache after the compat category for now. - Now done