Previously ContextManager watched the contents of each context folder
independently; this was redundant in the case where one context folder
was nested inside another. Also it led to some race conditions, since
we had to examine the contents of a folder in order to determine
whether there should be a context associated with it, but we couldn't
begin watching those files for that context until after the context
was created; this left a small window of time where a change to the
files might go unnoticed.
Note that a minor functional change is introduced: if "pub list"
indicates that the package resolution for a given folder is dependent
upon a file outside that folder, we no longer watch that file for
changes. This shouldn't be a problem, since in practice "pub list"
always lists exactly two files as dependencies, and both of those
files are inside the folder (pubspec.yaml and pubspec.lock).
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1257933002 .
Partially fixes#23909. Previously, these tests didn't work at all.
Now they verify that the FolderDisposition is based on the correct
package root, but they don't yet verify that the package map is
generated correctly.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1257913002 .
Previously, we tracked "pub list" dependencies using
ContextInfo.packageMapInfo.dependencies, but that mechanism could only
be used for folders that resolved packages using "pub list". Other
dependencies were tracked ad hoc (such as dependencies on ".packages",
or anti-dependencies* on "pubspec.yaml"); others weren't tracked at
all (such as dependencies on ".analysis_options").
(*In this context, an "anti-dependency" is a dependency on the fact
that a file is absent. E.g. when we decide not to create a separate
context for a subfolder, it is in part because that subfolder lacks
its own "pubspec.yaml" file.)
This CL migrates the "pub list" dependencies to a more general
mechanism; future CL's will migrate the other ad hoc dependencies to
use the same mechanism.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1258723002 .
The new class hierarchy encapsulates the packageUriResolver and
packages parameters that were previously used in the
ContextManagerCallback API. In a future CL, I intend to use it more
extensively within ContextManagerImpl in order to make the algorithm
for choosing contexts more declarative.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1258473003 .
This codepath was only exercised during unit tests and race
conditions. The fact that it was executed during unit tests at all
was due to a bug (see #23909). The behavior during race conditions
was incorrect (it tried to set up package resolution using a folder
that didn't exist).
This CL fixes the race condition behavior and disables the affected
tests. In a future CL I will fix the underlying bug that caused the
unit tests to execute incorrectly, and re-enable the tests.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1253803002 .
- There is now a single virtual ContextInfo representing the root of
the context tree; this should allow us to reduce the need for
traversing the _contexts map, and should reduce the number of corner
cases that need to be handled when creating and destroying contexts,
since tree roots will never be created nor destroyed.
- We now build the contexts while recursing down the directory tree
and populate them with files while unwinding the recursion; this is
more consistent with the data flow (deciding which contexts to build
depends only on the current directory and directories above it;
deciding which files to include in a context depends only on the
current directory and directories below it).
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org//1243233003 .
* apply source path translation in the order in which they are defined
* print elapse times in milliseconds
* log overlay content if server exception occurs
* simplify diagnostic port initialization
* add option to start server using new task model
BUG=
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1249793007 .
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
John McCutchan