Some tests have more failures than I feel comfortable marking as failing.
I will triage them in following CLs.
StaticTypeAnalyzer2Test
StrictModeTest
StrongModeDownwardsInferenceTest
StrongModeStaticTypeAnalyzer2Test
TypePropagationTest
R=brianwilkerson@google.com
BUG=
Review-Url: https://codereview.chromium.org/2628743002 .
Adding a TypeProvider instance to TypeSystem to avoid needing to
thread it through the various APIs, and to avoid having to change
the API every time a method which previously did not need to
access the TypeSystem suddenly does.
BUG=
R=jmesserly@google.com
Review-Url: https://codereview.chromium.org/2590883004 .
After discussion with kmillikin@, sigmund@, and scheglov@, we decided
that specifying the patch files in libraries.dart is more complex (and
less flexible) than we'd like. This CL changes things so that the
patch files are specified in analysis options using a simple map from
library name (e.g. "dart:core") to a list of patch file paths.
Clients are now allowed to put patch files wherever they want; they
don't need to be inside the sdk directory.
Note that we no longer include the patch configuration in
encodeCrossContextOptions. This should be ok, since we don't have any
use case in which a single instance of analyzer needs to accommodate
multiple patch configurations.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2560323002 .
This CL creates top level accessor functions which may be used to map from AST data structures to their corresponding elements and types, and begins using those accessor functions throughout the SDK. It also adds empty interfaces ResolutionTarget and ResolutionType, which are implemented by Element and DartType respectively.
In a future CL, I will change the types stored in the AST to ResolutionTarget and ResolutionType, rather than specific element types; this will decouple the ASTs from the element model. The presence of the accessor functions will allow clients to continue accessing elements and types in a type-safe way.
R=asgerf@google.com, brianwilkerson@google.com, scheglov@google.com, vsm@google.com
Review URL: https://codereview.chromium.org/2551023005 .
This is the same as 1d028eed8d (which
was reverted) except that it doesn't remove the old AST factory
constructors (which broke dev_compiler). The removal of old AST
factory constructors will be done in a follow-up CL so that if it
unexpectedly breaks any other clients we will be able to revert it
without reverting this CL.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/2536373008 .
This required moving the following classes into front_end as well:
- CharSequenceReader
- SubSequenceReader
- JenkinsSmiHash
A small amount of the functionality of GatheringErrorListener and
AnalysisError had to be replicated, to avoid a dependency on the
analyzer package. In a future CL I will either refactor this code to
make it available to the rest of the front end, or, if
GatheringErrorListener and AnalysisError wind up getting moved into
the front end, I will un-do the replication.
I also took the liberty of addition functionality to JenkinsSmiHash to
make it easier to use.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/2508483002 .
AnalysisError implements CompilationError but provides additional
services, such as extensibility via the `getProperty` method.
Note: CompilationError.location has been renamed to
CompilationError.span to avoid confusion (since its type is
`SourceSpan`, not `SourceLocation`).
R=scheglov@google.com
Review URL: https://codereview.chromium.org/2498133002 .
Instead in DeclarationResolver build these local elements in the bodies.
As you can see, the summary_common tests are quite ugly now, we decided
that we still have to serialize everything in variable initialiers,
including local functions. So, this requires repurposing the tests to
using initializers, and also keep buildLabelElements() in
DeclarationResolver.
R=brianwilkerson@google.com, paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/2485043004 .
Several support classes also had to move to front_end along with the
scanner. Some of these support classes arguably don't belong to the
scanner itself, since they have other uses (e.g. SyntacticEntity,
ErrorCode, ErrorSeverity, ErrorType, and StringUtilities). They will
be reorganized into a more appropriate location in future CLs, at the
time that they become needed by other components of the front end.
In order to avoid dragging in a lot of dependencies, the following
changes were made:
1. Scanner no longer reports errors through Source and
AnalysisErrorListener objects passed to the constructor. Instead, it
provides an abstract reportError() method which clients may override
to perform error reporting in any way they wish. Analyzer contains an
override of Scanner that mimics the old behavior in order to maintain
compatibility.
2. Static members of ErrorCode (`values` and `byUniqueName`) have been
moved to top level, and remain in analyzer. To maintain
compatibility, these static members remain in ErrorCode (as deprecated
members that simply wrap the implementations in analyzer). This means
we have a reverse dependency (front_end depends on analyzer), but this
dependency will go away as soon as we publish the next breaking change
release of analyzer.
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/2486873003 .
Konstantin Shcheglov