[analyzer] Needs to determine the public library to use to reference elements defined in private libraries

[bwilkerson]

The problem we currently face is that when a tool needs to add an import for an element defined in a private library we have no way to add an import for anything other than the defining (private) library, even if that element is also exported by a public library.

The need is to be able to take an arbitrary element from an internal library and efficiently determine which public libraries, if any, make that element available. Individual tools could then decide how to handle the cases where there are zero, one, or many such libraries.

We minimally need this for code completion and quick fixes / quick assists / code actions. If we're going to support it for quick fixes we should implement this in such a way that plugins can also use this API.

The dartdoc implementation currently has the notion of a 'canonical' library. We'd like to unify these two pieces of implementation into a common set of APIs, though the concept of choosing one of the potentially many public libraries to be the canonical library might only be useful to dartdoc.

The question, then, is what design we ought to use for this piece of support. The purpose of this issue is to discuss whether there are other requirements and what that design might look like.

[bwilkerson]

@srawlins @kallentu @DanTup @scheglov

[srawlins]

The problem we currently face is that when a tool needs to add an import for an element defined in a private library we have no way to add an import for anything other than the defining (private) library, even if that element is also exported by a public library.

Hmm, I thought we had that implementation in analyzer already? Well, two:

• ImportLibrary._importLibraryForElement
• NotImportedContributor.computeSuggestions
• Some shared code at https://github.com/dart-lang/sdk/blob/main/pkg/analyzer/lib/src/dart/analysis/file_state_filter.dart

[DanTup]

Yep, we do have this and it's used by some things like the Flutter snippets (added in c24f36d). It's async and may involve scanning through libraries to find the "best" one to use, so it doesn't automatically apply to anything using writeType().

This came up in Dart-Code/Dart-Code#4902 about the create_missing_overrides fix not using it, so it can produce override signatures that add src/ imports. It's probably fairly easy to update that fix to use this functionality, however I'm not sure if it might hurt performance (the time to search depends on the size of your project, and the number of times we search depends on the number of possible fixes that use this functionality).

It would probably be better (for performance) if we could decouple producing the edits from a fix from computing the list of which fixes are valid, but I don't know if it matters enough to warrant doing (how slow is the search really? how many fixes would end up triggering the search?).

[bwilkerson]

I had another idea about the performance aspect, and wanted to record it so that it isn't forgotten when we get to implementing this support.

What if we added an 'exported by' relationship to the index? Essentially, every time we analyze a library L we look at the export directives and record, for every element being exported by that export, that it's exported by L. It would probably be faster to go through the search engine to access this information from the index than it is to effectively re-search every time we need to ask the question.

If we can make it fast enough, then perhaps we can make it part of writeType, which would cover most of the places where we need this kind of support.

(We could make 'exported by' record a library-to-library mapping, but then we'd have to analyze the export scopes as a post-processing step. Of course, if we make it an element-to-library mapping then we might end up choosing a suboptimal set of imports unless we post-process them to remove unnecessary imports.)

[scheglov]

I don't think that exported by relationship can work. The index is per Dart file, it can have only information that is available in this file and its dependencies. It by definition cannot have information that a class A declared in this library is re-exported by another library. We cannot go back and patch the index of a library.

We already have this information about exports: LibraryElement2.exportNamespace. And NotImportedCompletionPass already uses it, by determining which libraries are available to the completion target, and looks into their exportNamespace. From this, there is one step to add, if necessary, a caching layer.