Improve incremental tracking of method references and lambdas - #10323
Improve incremental tracking of method references and lambdas#10323niloc132 wants to merge 15 commits into
Conversation
| if (incrementalCompile) { | ||
| compilerContext.getMinimalRebuildCache().recordNestedTypeNamesPerType(unit, types); | ||
| } |
There was a problem hiding this comment.
This change lets us only deserialize the set of GWT types once. This is the only call to CompilationUnit.getTypes() and also the only call to recordNestedTypeNamesPerType.
| recordNestedTypeName(compilationUnitTypeName, typeName); | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
THis pair of loops could probably be more efficient if we didn't remove-all and add-all, but just looked for the actual added/removed changes. GWT UI classes tend to have lambdas, anon inner classes, so this usually isn't a very short list, but it probably isn't long enough to really matter - but its also pretty likely most of the classes that were present last time are still there.
|
This is back in draft to avoid merging until I've finished going over the new test added via #10390 and understanding the differences, possibly merging the fixes. |
2 participants
Ensures that all GWT JDeclaredTypes are correctly marked as changed, including method references and lambdas.
Changes naming convention for method reference types - this slightly degrades debugability, but better ensures that fresh compiles and incremental compiles will result in the same output for a given class, improving how much testing we can do.
Note that adding/removing inner classes results in different incremental/initial output, so one of the new tests must opt out of that check.
Fixes #9670