Although it wasn't previously clear in the documentation,
implementations of UriResolver.restoreAbsolute() should only depend on
Source.fullName. To do otherwise breaks some assumptions made by
analysis server. This CL fixes all implementations except
SdkExtUriResolver (which has been deferred to issue #24090).
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1296653003 .
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 .
Brian Wilkerson