Erik Ernst
0579a9250a
This is the "next step" mentioned in https://dart-review.googlesource.com/c/sdk/+/141240. `List<UnresolvedType> typeArguments` were dropped (and null was passed) in several cases in `handleSend`, but they are needed in BodyBuilder.buildConstructorInvocation in the case where the receiver of the constructor invocation is a type alias. This CL ensures that the `typeArguments` are passed when needed, and a named parameter `isTypeArgumentsInForest` is passed in order to preserve the information about whether or not they have been to the `forest`. The CL also adjusts tests '{generic_,}usage_type_variable_*' to fit the decision made in language issue 848 that a type alias cannot be used for constructor invocations when it (directly or indirectly) denotes a type variable. Change-Id: I8d831457e35a7455f8fcfe461a10872c61555748 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141543 Reviewed-by: Dmitry Stefantsov <dmitryas@google.com> Commit-Queue: Erik Ernst <eernst@google.com>
Front end for Dart
This package provides a low-level API for use by compiler back ends that wish to implement the Dart language. It is intended for eventual use by dev_compiler, dart2js, and the Dart VM. In addition, it will share implementation details with the analyzer package--this will be accomplished by having the analyzer package import (and re-export) parts of this package's private implementation.
End-users should use the [dartanalyzer][analyzercli] command-line tool to analyze their Dart code.
Integrators that want to write tools that analyze Dart code should use the [analyzer] package.
Note: The APIs in this package are in an early state; developers should be careful about depending on this package. In particular, there is no semver contract for release versions of this package. Please depend directly on individual versions.