Description Stephan Herrmann 2019-07-08 16:59:06 EDT

To continue from here: 

(In reply to Till Brychcy from bug 547181 comment #98)
> I have a list of TODOs where I have some doubts and not all cleanups are
> done yet.
> 
> Cleanups note done yet:
> - I still suspect the module parameter is not needed in
> SPB.combineWithSiblings (and therefore in PB.addPackage).
> - remove getPackage0Any
> 
> 
> Here's is a list of TODOs that I have open (no particular order).
> 
> - I think PackageBinding.getPackage(char[], ModuleBinding) can only work if
> moduleBinding is the enclosingModule, which it is when called from
> CUS.checkAndSetImports, but maybe not when called from Scope.getOnlyPackage
> (which is only used by DefaultBindingResolver). Reason is that the computed
> value depends on mod (for PPBs) but the getPackage0() is just based on name.
> - Similar in PackageBinding.getTypeOrPackage
> - Should the parent of PPB also always be a PPB?
> - SPB.findPackage doesn't use module parameter at all except for passing to
> addPackage. I wonder if SPB.findPackage could be comletely removed, so the
> impl from PPB is used (doing this doesn't cause any test failures)
> - Is it true, that all elements of LE.knowPackages are PPBs (possibly from
> another module) or SPBs whose enclosingModule is the LE's module? If not,
> should we try to reach that state?
> - In CodeSnippetScope.getBinding, a null is passed as mod to
> packageBinding.getTypeOrPackage, which looks like it can lead to an NPE
> - I think doing SplitPackageBinding.combine in a loop could lead to lots
> unnecessary  addWrappingSplitPackageBinding for intermediate results
> - ModuleBinding.UNOBSERVABLE is used only in FileSystem, not by other
> NameEnvironments, which seems strange
> - add the end of MB.getVisiblePackage, if parent is a SPB,  addPackage will
> try to add siblings even though the computed package should already be fine