Most clients of _PhysicalFile read the file by translating it into a
Source object using createSource() and then reading it using
FileBasedSource.contentsFromFile, which normalizes newlines using
FileBasedSource.fileReadMode.
However, a few clients read the file directly using
_PhysicalFile.readAsStringSync(), which wasn't doing the
normalization. This CL adds the normalization to that code path.
One such client was the code generation logic for summaries; this
caused code generation to produce different results on Windows, which
led to a test failure.
Fixes#25470.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1584313010 .
After inlining, test expectations have changed. A few tests have
starting unexpectedly passing --- this could be because inlining
implements the correct semantics, or the could be passing for the
wrong reason. In any case, the underlying bug in the compiler has not
been fixed.
I will look into all these issues after the Christmas holidays.
BUG=
Review URL: https://codereview.chromium.org/1546943002 .
Perform a depth-first postorder traversal of the call graph of known
functions. Make an inlining decision based on the vector of argument
types at the call site, and cache inlining decisions. For positive
inlining decisions, cache the optimized function body specialized to
the receiver and argument types at the call site.
Future work:
* Real inlining heuristics.
* Propagate result types of inlined calls.
* Specialized for constant arguments when it makes sense.
* Performance improvements.
R=asgerf@google.com, sra@google.com
Committed: https://github.com/dart-lang/sdk/commit/d63053fea8731d2fb380022c1c3d296489d1c017
Review URL: https://codereview.chromium.org/1537663002 .
Perform a depth-first postorder traversal of the call graph of known
functions. Make an inlining decision based on the vector of argument
types at the call site, and cache inlining decisions. For positive
inlining decisions, cache the optimized function body specialized to
the receiver and argument types at the call site.
Future work:
* Real inlining heuristics.
* Propagate result types of inlined calls.
* Specialized for constant arguments when it makes sense.
* Performance improvements.
R=asgerf@google.com, sra@google.com
Review URL: https://codereview.chromium.org/1537663002 .
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 .
Paul Berry