Ability to set packages and/or directories that should be indexed by analysis server for code completion

[lambdabaa]

Currently analysis server only suggests code completions which are already imported. For example, if I have two sibling classes Foo and Bar and ask analysis server for completions on Ba^ from foo.dart before importing bar.dart, Bar will not be suggested. Likewise, if I ask for Proces, Process will not be suggested from dart:io unless I've already imported it.

In order to have Java parity in IntelliJ, we need to be able to do this, and code completion will be much more useful overall with this ability.

The additional API I would like is something along the lines of completion.setActiveTargets(List<String> targets).

/cc @jwren @scheglov @bwilkerson

[scheglov]

Some additional clarification.

If both files are in the same project, or even in analysis roots set in DAS, then these folders are already know to DAS, and we could provide completion suggestions from them. Same is for .package file - we parse these files, and can learn about additional directories with Dart files from which we can give suggestions.

The problem starts when we live in mono-repository, where in theory everything is available for completion. In this case we require the client to provide additional directories for DAS to parse and provide suggestions from. It is OK is these new directories will have some intersection with analysis roots, we always can merge two sets.

[bwilkerson]

The additional API I would like ...

Are you asking for a server protocol, or a method on some class (and if the latter, which class)?

Independent of the actual API, what I think you're asking for is a way to set the scope for finding names to suggest. It isn't clear to me that we ought to allow this to be set. The alternative is that we pick the "right" scope and just use it everywhere without the need/ability for it to be set externally.

There are a few scopes that I can think of, each described as a delta from the previous scope:

• the name scope of the enclosing library (the names declared in the library and the names that are imported), which is what we currently use,
• all of the names from the transitive closure of libraries reachable from the enclosing library,
• all of the names declared in the current package (the package containing the enclosing library),
• all of the names in all packages that the current package depends on,
• all of the names in the workspace containing the current package.

So which of those scopes would match our user's expectations?

The problem starts when we live in mono-repository, where in theory everything is available for completion.

I think we can solve that problem by choosing a scope that is smaller than the whole workspace.

[lambdabaa]

Are you asking for a server protocol, or a method on some class (and if the latter, which class)?

A new protocol message {"method": "completion.setActiveTargets", "params": {"targets": List<String>}}.

Independent of the actual API, what I think you're asking for is a way to set the scope for finding names to suggest. It isn't clear to me that we ought to allow this to be set. The alternative is that we pick the "right" scope and just use it everywhere without the need/ability for it to be set externally.

Yes. What I really want is for all of my declared dependencies (whether pub or bazel) to show up in code completion results. If analysis server is able to make that determination, that's even better :).

So which of those scopes would match our user's expectations?

My expectation coming from Java development with IntelliJ + Bazel is that there's a build file which declares my project's sources and dependencies. A dependency might be a package or a library. Any interfaces, classes, etc defined in one of my sources or dependencies would be available in code completion, but I don't expect that the transitive closure (dependencies' dependencies) will show up as code completion suggestions.

[bwilkerson]

I think we agree. That sounds like the most reasonable choice.

But just to be a little more precise, I think we want to suggest

• all of the names declared in the current library,
• all of the public names defined in other libraries in the current package, and
• all of the public names from public libraries in the packages that the current package depends on directly.

[zoechi]

Related to #25820, #21931

[lambdabaa]

We're developing the analysis server protocol changes in https://dart-review.googlesource.com/c/sdk/+/90125.

[lambdabaa]

We did it, thanks @bwilkerson and @scheglov for all of your work on this!