If the implemented interfaces don't declare an element, keep only a single copy of the element - from the superclass.
In Dart Editor we use any element, but in in IDEA we show all of them, and we don't want to have duplicates.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org//1273003005 .
With the introduction of support for ".packages" files, analysis
server now uses a slightly different code path for translating the
Source objects from imported package files into "package:" URI's.
Previously it used PackageUriResolver.resolveAbsolute(); now it uses
ResourceUriResolver.resolveAbsolute(), and then translates the
resulting file: URI to a package: URI uring the .packages file.
The old code path used Source.fullName (the file path) to locate the
file in the filesystem; the new code path uses Source.uri. This
causes problems because when figuring out the correct import statement
to insert, the analysis server creates a bogus Source object whose uri
field is null. As a result, import fixups were getting relative paths
like "../../../../.pub-cache/..." rather than package imports, which
is clearly wrong.
As a short term non-invasive fix, we set Source.uri in the bogus
Source object, so that the new codepath is able to find the path of
the imported file.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1281313002 .
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 .
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 .
* 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 .
danrubel