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 .
The AST getters/setters for `bestElement`, `propagatedElement`, and
`staticElement` having type `MethodElement` are moved to a common
interface class, `MethodReferenceExpression`.
The AST getters/setters for `staticElement` having type
`ConstructorElement` are moved to a common interface class,
`ConstructorReferenceNode`.
The overrides for `propagatedInvokeType` and `staticInvokeType` are
removed from `FunctionExpressionInvocation` and `MethodInvocation`,
since these overrides are identical to the corresponding declarations
in the base class, `InvocationExpression`.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/2536253002 .
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 .
In the long run, pkg/front_end/src/base is intended to contain code
that is useful to many components of the front end.
In this initial implementation, it contains:
- Source and the classes it references
- ErrorCode, ErrorSeverity, and ErrorType
- SyntacticEntity
Note that AnalysisTarget is included (even though strictly speaking it
is part of the analyzer task model) because it was too hard to
disentangle from Source.
Note that Token classes remain in pkg/front_end/src/scanner for now; I
plan to reorganize them at the time the parser is moved into the front
end.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/2486923007 .
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 .
Previously this was working for a few use cases by dumb luck, but it
wasn't well tested and became broken by
b29c6bf330. This CL fixes it for real
and adds tests to verify the fix.
Note that there is a change to how we represent an unresolved
import/export: instead of storing a URI_EXISTS modifier in the element
model, we simply mark the imported library element as synthetic.
(This library element existed anyway; we just weren't marking it as
synthetic). This makes it easy to tie in with summaries, since it is
easy for the resynthesizer to detect that the library doesn't exist at
the time the library handle is resolved.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/2235373003 .
Instead of a very slow .inDeclarationContext() method which determines
whether a given identifier is in a use position or not, we just create
a different subclass at parse time that encodes that fact directly.
Also, remove an unnecessary _validateElement() method.
On my Mac laptop, this takes benchmark/errors_in_all_libraries.dart
From: 0:00:05.673849
To: 0:00:05.193563 (91.53%)
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1833573006 .
Adds a `TimedAstVisitor` that wraps and times base visitors. The perf hit for collecting timing was neglible so I opted to NOT surface a way to not collect the data. We can add that if needed.
Once this is published in a new analyzer, I can bake client support into (for example) the linter.
More context and a client mock here: https://github.com/dart-lang/sdk/issues/24548
BUG=
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1807723002 .
This gets us roughly half+ way there. We should defintely consider automating this to speed up the rest. (Even with the quick-fix it's VERY tedious and slow going.)
Once we've done this in bulk, I'd like to add the `annotate_overrides` lint to analyzer and server `.analysis_options`.
BUG=
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/1749143003 .
Paul Berry