investigate why we need to resolve compilation units again

[sigmundch]

computeLibraryElement used to be enough to compute the resolved tree for anything reachable from a library. However, getResolvedCompilationUnit2 sometimes returns null. Doing resolveCompilationUnit returns the right thing, but seems like this might be running the resolver more than necessary.

[sigmundch]

It seems that resolveCompilationUnit will check the cache anyways. I've also tried doing getResolvedCompilationUnit first, and only call resolvedCompilationUnit when its null, but I am not noticing any changes in performance.

Also context.getLibraryElement(source).definitingCompilationUnit.node seems similar too.

[vsmenon]

Is this still open?

[sigmundch]

Closed. We figured out what was happening here. Basically it was an issue around caching and the cache size. When elements are evicted from the cache, getResolvedCompilationUnit returns null, even if it was previously computed. computeLibraryElement will check the cache too, and only recompute as needed.