This CL introduces
pkg/analyzer/lib/src/dart/analysis/experiments_generated.dart, which
will eventually be code generated from a YAML description of the
currently-allowed set of experimental flags.
Change-Id: Iabbefa8e5037573d4b4e7b7b4eb661c1698bd673
Reviewed-on: https://dart-review.googlesource.com/c/86220
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
AnalysisDriverResolutionTest is partially updated, about 30 failing
tests added. I will get back to it in a following CL, it is not
directly CFE integration, but updated understanding how we want to
resolve. For example we don't need types for non-expression identifiers.
Change-Id: I3daddbb6c66ffad7a726f3313a1199fd7387aa04
Reviewed-on: https://dart-review.googlesource.com/71883
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
(was reverted in https://dart-review.googlesource.com/c/sdk/+/40980
due to an analyzer bot breakage)
Original commit message:
Implement proper checking for callability of Function class.
There was some old (incorrect) logic for doing this, behind the flag
enableStrictCallChecks. This flag has been removed, since the new
behavior is now standard in Dart 2.0.
Fixes#31509
Change-Id: Ice5cf38bbc648badf7f2563ff930b69f9a799635
Reviewed-on: https://dart-review.googlesource.com/41120
Reviewed-by: Jonas Termansen <sortie@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This allows us to collect stats about language-style tests as follows:
./tools/test.py -m release -c dart2analyzer -r none --preview-dart-2 --report \
language language_2 corelib corelib_2
As of this morning, the command above has 87% of the tests passing.
Change-Id: I0f84211d5f33659d5923601267367be90c578107
Reviewed-on: https://dart-review.googlesource.com/3381
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
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 .
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 .
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 .
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 .
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 .
Paul Berry