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 .
When summaries are built in fallback mode, the only information stored
in the package bundle is (a) which libraries appear in the bundle, and
(b) where the source files can be found on disk. This is enough
information so that DDC will still be able to tell how libraries are
grouped into build units, but otherwise summary functionality is
disabled.
This is intended to be availadle as a temporary workaround so that if
a bug is found in the summary infrastructure, it won't prevent DDC
compilation from working (it will just make it slower).
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1826353002 .
It (in combination with --build-summary-only-diet) makes the
package:path summary is almost 3 times smaller, partially because of
skipping bodies, patially because of excluding documentation comments,
and partially because of making 'codeRange' fields informative.
We also remove MD5 hashes.
As I can see after changes in method bodies we generate the exactly
same file (or at least 'cmp -l' thinks so). Adding a new field results
in a file of different length.
R=paulberry@google.com, brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/1828973002 .
Build mode differs from package mode in the following ways:
- The analyzer no longer guesses the relationship between paths and
URIs based on directory structure. Instead, each input file is
specified in the form "$uri|$path".
- The analyzer does not read any files from disk that are not
specified on the command line.
- There are no restrictions on the relationship between summaries and
packages. In particular: (a) multiple input summaries may summarize
parts of the same package, and (b) part of a package may be
specified with an input summary while an output summary is being
generated for other parts of the same package.
- Output may be redirected to a file.
- The analyzer may be told to exit with success even in the event that
an error is found during analysis.
This should ease the integration with Bazel, and provide a starting
point for integrating with other build systems.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1830463002 .
This is similar to --package-warnings, except that diagnostics will
only be reported for Dart packages matching the given prefix.
Also added the number of source files analyzed and the number of
errors generated to performance report.
Cleanup: simplified code for triggering diet parsing.
BUG=
R=paulberry@google.com
Review URL: https://codereview.chromium.org/1806263004 .
If we aren't doing full analysis, then we can't use
`context.librarySources` to find out the set of library sources (because
it doesn't include sources that haven't been examined yet). Instead, we
have to query each source to find out its type.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1770323003 .
The path passed to "--packageMode" must be converted to an absolute path
because it is used to normalize file paths (which are automatically
converted to absolute paths by the PhysicalResourceProvider.
We should not call `resourceProvider.pathContext.absolute()`. This
seems (by its name) like it would convert its argument to an absolute
path. But in fact it simply prepends the path with
`resourceProvider.pathContext.current`, which is `.`, and this causes
Source objects to be created referring to non-canonical paths.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1762363002 .
I think the fix does the change needed to configure SDK for using
the strong mode summary, but I was not able to verify this fully
because of the exception with LibraryElementHandle.
R=paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/1734773003 .
When --package-mode is specified, this turns ON the single package
analysis mode. My initial idea was to accept a single path - the root
folder of the package and analyze the package completely as Dart
Analysis Server does. But later I decided to accept a list of files
to analyze, at least for now.
We still need the --package-mode-path option with the path to the root
folder of the package because we need to know which libraries are in
the 'lib' folder and write these libraries into the output summary.
The option --package-name is used to write the same URIs into
summary as the clients are going to use to refer the package
libraries, and also as the package references itself.
Multiple --package-summary-input=pkg,summary options can be specified,
one for each package. Every referenced package (except itself) must
be listed.
If --package-summary-output is specified, the output summary of
the package is written to the specified file. It is up to the client
to specify the correct X.spec.sum or X.strong.sum names.
R=brianwilkerson@google.com, paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/1720963003 .
It seems that we have a bug - when we analyze a SDK library during
running shared tests, we still parse it dietly so we don't actually
validate that bodies are warning-free.
And when we attempt to use SDK summary, we again parse a library
dietly, but then attempt to apply the full summary using
DeclarationResolver, which fails because we fail to bind some elements
to not parsed nodes.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/1689263004 .
1.13 stable builds of the SDK contain a version of server that fails catastrophically when analyzing source that imports packages that define embedded libraries. Since we can't pragmatically require more recent SDKs for flutter development we have been prevented from landing embedded libs in the flutter engine. By renaming the key we use to identify contributed libraries, this change avoids the issue. Old versions of server will simply ignore the new key and new ones will process it properly. Win-win!
BUG=
R=danrubel@google.com
Review URL: https://codereview.chromium.org/1643023002 .
Another stab. The rub, I *think*, to our failures are unexpected calls to `exit()` on the bots (that are not reproducing locally). These fixes should address that (and fix error stream handling along the way).
* fixes test setup and teardown to ensure exit handling is properly managed.
* fixes driver source to use the `exitHandler` and `errorSink` consistently
BUG=
R=keertip@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/1525623003 .
