This newly introduced test currently fails on the analyzer buildbot due
to transitive import dependencies on
dart_style/lib/src/dart_formatter.dart and
dart_style/lib/src/source_visitor.dart, which have known warnings.
TBR=danrubel@google.com
Review URL: https://codereview.chromium.org/1504713007 .
If the JS ast contains an initializer list:
var x = foo(), y = await x;
It would be retained as a single statement and generate invalid output
that awaits 'x' before it has been defined.
CLOSES=23997
BUG=
R=sigurdm@google.com
Review URL: https://codereview.chromium.org/1427593003 .
This CL reworks the task model grapher (formerly at
pkg/analyzer/tool/task_dependency_graph.dart, now at
pkg/analyzer/tool/task_dependency_graph/generate.dart) so that it
works similarly to the code generation in the analysis server.
Namely, the output file is stored in source control
(pkg/analyzer/tool/task_dependency_graph/tasks.dot), and a test run by
the buildbots verifies that it is up to date. If it is not, the test
outputs the command necessary to update it.
This carries the benefit that:
- Anyone with access to an installation of graphviz can generate the
task model graph easily from its .dot file.
- Any time a change occurs that affects task model dependencies, a
test failure will prompt us that we need to generate a new .dot
file.
- If a change ever occurs that breaks the ability of the task
dependency grapher to produce the graph, a test failure will prompt
us.
The downside is that when making a change that affects task model
dependencies, it is now necessary to re-run the script
pkg/analyzer/tool/task_dependency_graph/generate.dart to avoid a test
failure.
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/1408743006 .
Type propagation, shrinking reductions, and let sinking each took
more than 2 minutes on a stress test, where now they take a few
seconds.
Huge hash tables (Map/Set) were a big problem, especially when used as
worklists.
Let sinking had an issue with a linear-time search for the enclosing
continuation of an expression. This has been replaced with a visitor
state.
The stress test was:
tests/co19/src/LibTest/collection/ListBase/ListBase_class_A01_t02
This was only slow because negative constants get translated to
intercepted calls. That itself should be fixed, but the IR should
still be able to handle the stress.
The change in shrinking reductions altered the redex priority from
FIFO to LIFO which has a negative effect on code quality in
unwrapException (in any test case with a try/catch). It seems like
an existing issue that has surfaced.
Since I am going on vacation, I ask that someone would please
commit this on my behalf (assuming things are looking good).
--asgerf
BUG=
R=karlklose@google.com
Review URL: https://codereview.chromium.org//1252883003 .
Without reflection, redirecting factory constructor invocations are shortcut at the instantiation site. With reflection, code like
reflectClass(Foo).newInstance(const Symbol(''), [])
can hit a redirecting factory constructor and we need to emit a function that does the redirection and type substitution.
R=asgerf@google.com
Review URL: https://codereview.chromium.org//1227873004 .
Commit f8ce36df55 introduced an SDK
class called "Resource", causing warnings to appear in any files that
reference the analyzer class with the same name. (Fortunately there
was no regression in functionality since the spec requires the name
conflict to be resolved in favor of the definition that is outside the
SDK).
As a short term workaround to avoid the warnings, we are explicitly
importing 'dart:core' and hiding the new Resource class. In a future
CL, we plan to rework analyzer's Resource class in order to make some
changes necessary for ".packages" file support; when that happens we
will probably rename the class to avoid the name conflict.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1215753003.
Support try/catch/finally by pretending it is macro-expanded into
try/catch and try/finally:
try S0 catch (ex, st) S1 finally S2
==>
try { try S0 catch (ex, st) S1 } finally S2
The duplicated code for try/catch and try/finally is abstracted into a
function parameterized over translations for all the parts that
differed.
R=asgerf@google.com
Review URL: https://codereview.chromium.org//1207703002.
Try/finally is implemented by inlining. There is a try/catch to catch
exceptions in the try block. The catch body contains the finally code
followed by a rethrow. The code for finally is translated again after the
normal exit of the try block. Break, continue, and return exits in the try
block have the finally code inlined just before the exit is taken.
Try/catch/finally is not yet supported, it requires some changes to the
assigned variables analysis.
R=asgerf@google.com
Review URL: https://codereview.chromium.org//1201983002.