Also, to guarantee that LINE_INFO is computed, we need to replace
context.getLineInfo() with context.computeLineInfo() in the server.
This should be equivalently fast in both summary (from provider) and
non-summary cases (the source should have been scanned and parsed in
order to resolve references to its elements).
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/2225893003 .
This option has the same functionality as the flag
"--build-summary-exclude-informative", except it is an option rather
than a flag. This makes it possible to get both a "full" summary and a
"semantic" summary by specifying both "--build-summary-output" and
"--build-summary-output-semantic".
The flag "--build-summary-exclude-informative" is kept around to ease in
transitioning tools, but it is deprecated.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/2104003004 .
A bunch of changes to pave the way for emebdder SDK summary creation.
* Moves _embedder.yaml processing into the embedder SDK (out of the resolver).
* Changes EmbedderUriResolver to compose rather than extend a DartUriResolver.
* Fixes the wierd handling (dropping to add back) of `dart:` URIs.
* Fixes the incorrect overriding docs for `SDKLibraryImpl.shortName`.
* Updates embedder test to include a definition of `dart:core` in anticipation of adding some embedder SDK tests.
Some API work TODO in a follow-up CL (notably the way we check for the presence of embedders by querying the resolver is odd).
BUG=
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/2009303002 .
Addresses the issue seen in https://github.com/dart-lang/sdk/issues/26448.
Ultimately we want a better story for summaries in the presence of embedded SDKs; in the short-term this simply disables them.
The trick (and reason for all of the changes here) is that there is *a lot* of temporal coupling in the initiailization of contexts, sdks, resolvers, etc. With this change, embedder processing is pulled out to where it can be done before the SDK is configured. Hopefully this even makes this a bit more clear as resolver setup is less complex.
Open question: I think the logic that calls `pub list-dirs` is dead and can safely be removed. Comments there welcome.
Thanks!
BUG=
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/1984733003 .
Fixes: https://github.com/dart-lang/sdk/issues/26129
The issue was that we were creating the SDK and populating its options (notably `strong-mode`) *before* options processors were called. The result was that client code analysis contexts and SDK contexts were getting configured differently causing confusion when client code was getting analyzed with a non-strong-mode SDK.
BUG=
R=paulberry@google.com
Review URL: https://codereview.chromium.org/1962403002 .
This simplifies the integration with build systems such as Bazel, in
which it is sometimes convenient to have a build unit which depends on
other build units but doesn't introduce any additional source files of
its own.
R=pquitslund@google.com
Review URL: https://codereview.chromium.org/1960263003 .
The hashes were being thrown away anyway; computing them just wastes
time.
Cuts the runtime of generating an AST-based summary of the analyzer
package (with a warm VM) by about 19%.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1910553002 .
When building summaries from ASTs, we only use the context to read
source files; we don't need it to provide an element model. Therefore,
we can save some time by turning off the context's use of summaries,
because this prevents it from trying to eagerly deserialize the
summaries of dart:async and dart:core.
Saves a significant amount of time when building a summary of a small
package using ASTs. For example, saves ~37% of time when building a
strong mode summary of the "yaml" package.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1882263002 .
Brian Wilkerson