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 .
Update command line arguments processing so that any analysis options
flags specified on the command line (e.g. --supermixin) take precedence
over corresponding flags in the analysis_options.yaml file.
R=brianwilkerson@google.com
Review-Url: https://codereview.chromium.org/2598523003 .
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 .
Unlike the previous AstFactory (now called AstTestFactory), this class
is not just for testing; it is intended to be able to create all
analyzer AST objects used in production. Also, its methods are
non-static.
For now, all users of the new AstFactory access it using the final
variable `astFactory` in standard_ast_factory.dart. In future CLs I
intend to plumb a reference to the AstFactory through various analyzer
classes so that it can be used in a dependency injection style.
Also, the classes CommentType and UriValidationCodeImpl have been
moved out of the AST implementation file
(pkg/analyzer/lib/src/dart/ast/ast.dart) and to their own files so
that the AST interface will be able to continue to use them without
depending on the AST implementation.
In follow-up CLs I will change the analyzer and its clients to use the
AstFactory rather than the redirecting constructors in the AST
interface file, and then remove those redirecting constructors.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/2522143003 .
Example error messages include:
/analysis_options.yaml(10..27): The include file other_options.yaml in /analysis_options.yaml cannot be found.
/analysis_options.yaml(10..27): Bad options file format (expected String scope key, got YamlScalar) in /other_options.yaml(0..0)
/analysis_options.yaml(10..27): Warning in the included options file /other_options.yaml(47..49): The option 'ftw' isn't supported by 'errors'.
Since the included options file may not be part of the project,
the error is reported on the initial include statement
and includes the needed location information for the user to track down the problem.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/2502233004 .
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 .
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 .
As I understand, we infer all types during linking.
So, there is no reason to re-infer types.
And AFAIK ensuring type inference is the only client of library cycle
information.
With the new analysis context we link and have types for all libraries,
including the one we are resolving unit for.
Removing library cycle computation makes analysis almost 40% faster.
R=brianwilkerson@google.com, paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/2473443005 .
Auxiliary classes ElementGatherer, ElementMismatchException, and
ExistingElementResolver, which were only used by DeclarationResolver,
are also moved.
(No functional change; just code motion).
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/2406863003 .
Konstantin Shcheglov