This implements FutureOr<T> in strong mode, otherwise it's ignored (treated as `dynamic`.
Also fixes strong mode's inference subtype function incorrectly treating `void` as a malformed type. This had the consequence of allowing `void` to be inferred as a type argument.
R=leafp@google.com, paulberry@google.com
Review-Url: https://codereview.chromium.org/2647833002 .
This ensures the runtime type is of the tear-off expression's static
type, even when accessed through a superclass.
I also moved the two tests into a subdirectory so they are easier to
find. (It is inscrutable to me why we would have a single directory
with 1,868 test files in it.) That involved enabling recursive
directory listing in codegen_test, which exposed a couple of things.
Fix#27484.
R=leafp@google.com
Review-Url: https://codereview.chromium.org/2641543003 .
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 .
Paul Berry