fix(jdk-codemodel): defer method/field body conversion to a second pass so forward type references resolve#107
Merged
Merged
Conversation
…ss so forward type references resolve
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
JdkInitializerused to register a type's descriptor and convert its method bodies, constructor bodies, field initializers, and static/instance initializer blocks in the same single pass over compilation units, in source-list order, viaprocessMembers/processField/processConstructor/processMethod. This meant that if a source file processed earlier in the list called into a type processed later, the call would silently fail to resolve sinceJdkExpressionConverter'sresolveField/resolveParameter/resolveMethodreturnOptional.empty()when the target type's descriptor isn't registered yet, with no diagnostic.The fix collects each type's body/initializer work into a
bodyTaskslist during the registration walk, then defers actual conversion viadeferredConversionsuntil every compilation unit's type descriptors have been registered, re-establishingexprConverter's type context and enclosing type for each deferred task since that context is mutated while scanning subsequent classes.Added
TwoPassResolutionTeststo reproduce the bug directly at the codemodel level with in-memory sources, asserting that a caller's call to a callee resolves to aResolvedMethodtrait regardless of which order the two types are passed toJdkInitializer.