This reverts commit 4bb83e9311
This reverts commit f1b07b2789.
Reason for revert on analyzer bots:
Analyzing pkg/analyzer...
error • Undefined name 'source' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:625:9 • undefined_identifier
error • Undefined name 'CompileTimeErrorCode' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:625:18 • undefined_identifier
error • Undefined name 'source' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:626:13 • undefined_identifier
error • Undefined name 'source' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:635:9 • undefined_identifier
error • Undefined name 'CompileTimeErrorCode' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:635:18 • undefined_identifier
error • Undefined name 'source' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:636:13 • undefined_identifier
error • Undefined name 'source' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:645:9 • undefined_identifier
error • Undefined name 'CompileTimeErrorCode' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:645:18 • undefined_identifier
error • Undefined name 'source' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:646:13 • undefined_identifier
error • Undefined name 'source' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:655:9 • undefined_identifier
error • Undefined name 'CompileTimeErrorCode' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:655:18 • undefined_identifier
error • Undefined name 'source' at pkg/analyzer/test/generated/compile_time_error_code_kernel_test.dart:656:13 • undefined_identifier
12 errors found.
Change-Id: Ie2035bf40e50c48f85b514c7a3786141cd0f2453
Reviewed-on: https://dart-review.googlesource.com/14061
Reviewed-by: Martin Kustermann <kustermann@google.com>
1. Instead of using a single lib/lib.dart, use a couple of small shared
libraries, and special libraries for each case we want to test.
2. Give tests meaningful structured names, with "source_*" tests
testing that we take into account referenced *from* somewhere.
And "target_*" tests for testing that we include referenced entities.
And "transitive_*" tests for including complete transitive closure
of referenced entities.
We don't yet include full transitive closure, this CL is just for
tests and results produced at the moment. Implementation and test
fixes will follow.
We also don't yet take exports into account.
R=ahe@google.com, paulberry@google.com, sigmund@google.com
BUG=
Review-Url: https://codereview.chromium.org/3011663002 .
This mode was needed in the early days of the front end when we were
contemplating the idea of building the analyzer AST representation of
code first, and then converting it to kernel. Now that we build
kernel directly, it is no longer needed.
Further CLs will follow to remove code that is no longer used after
this change.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2980013002 .
This CL lays the groundwork for integrating the front end with
analyzer by creating a mechanism to copy resolution and type inference
information (produced by the front end's type inference engine) into
analyzer ASTs (produced by AstBuilder).
The general technique is to parse each function twice: once with
BodyBuilder as a listener and once with AstBuilder as a listener. The
BodyBuilder generates a kernel representation of the function, but
this isn't used; instead, type inference and resolution information is
captured using ResolutionStorer (which is a TypeInferenceListener).
Later, this information is applied to the analyzer AST generated by
AstBuilder using ResolutionApplier (which is an analyzer AST visitor).
At the moment the intermediate data exchanged between ResolutionStorer
and ResolutionApplier is simply a list of types (one for each
subexpression, in a post-order traversal of the program syntax). For
debugging and validation purposes, this is augmented with a list of
file offsets, so that if the ResolutionStorer and ResolutionApplier
get out of sync we can diagnose the problem easily.
In later CLs, more data will need to be exchanged between
ResolutionStorer and ResolutionApplier (e.g. a list of elements to
which identifiers are resolved).
This CL doesn't tackle the problem of translating between the kernel
and analyzer representation of types; for now we simply map each type
to `dynamic`. This is sufficient for early development, since it is
still enough to let us verify that ResolutionStorer and
ResolutionApplier stay in sync.
R=ahe@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2981693002 .
Aske Simon Christensen