Implement forEachParameter in closures, deal with not all closures being localFunctions, and point to the constructor head instead of body when calling "getConstructorBody"
This reverts commit b74f53aa74.
BUG=
R=sra@google.com
Review-Url: https://codereview.chromium.org/2999453002 .
We need this API to create a mock SDK in a way that makes
ProcessedOptions.validateOptions() to accept it - the SDK root
must exist.
Alternatively (or in addition to) we could make writeXYZ create parent
directories implicitly. So, to "create" a directory, you would need
to create a file in this directory.
R=ahe@google.com, paulberry@google.com, sigmund@google.com
BUG=
Review-Url: https://codereview.chromium.org/2994643002 .
For the migration script, I need a (less hacky) way of programmatically
modifying a status file. As a step along that path, I need the ability
to write a status file to disc given a StatusFile object.
With that, it was a small step to write a little "formatter" that turns
a status file into its canonical representation.
It removes unneeded parentheses in expressions, normalizes expectation
case, and normalizes whitespace. Seems useful.
R=whesse@google.com
Review-Url: https://codereview.chromium.org/2988383002 .
Summary:
Previously, the VM would crash when it encountered a ClosureCreation node
because it was not aware of the new type arguments field.
Now, it skips the type arguemnts field, which allows many tests to pass again,
even though it doesn't correct forward the type arguments at runtime.
Test Plan:
Removed expected failure lines for all the tests added in my prior
CL (introducing the new field).
BUG=
R=dmitryas@google.com, jensj@google.com
Reviewers: dmitryas@google.com
Review-Url: https://codereview.chromium.org/2987143002 .
Summary:
Previously, when a function parameter was captured both in an initializer and in
the body of a constructor, we would create two contexts: one created in a local
initializer and used by other initializers, and another in the body of the
function. This is incorrect, as it means that changes to the parameter in the
initializer's closure won't be visible in the body.
Now, to work around this problem we re-use the context created for the
initializers in the body of the constructor by moving the body into a new
constructor, and redirecting the original constructor to that one, passing the
context as an additional argument. This dance is necessary because local
initializers aren't visible in the body of a constructor.
Test Plan:
A few of the existing closure conversion tests were changed or fixed by this
revision. We also modify the 'closure_in_initializer.dart' test to hit this case
directly.
R=dmitryas@google.com
Reviewers: dmitryas@google.com
Review-Url: https://codereview.chromium.org/2991853002 .
+ split MemberData into MemberData interface and MemberDataImpl node based implementation and add ClosureMemberData objects
+ use SourceSpan instead of ir.Location for Class/MemberDefinition.location
+ register StaticUse.callMethod instead of StaticUse.closure
+ use DartType instead of ResolutionDartType in metadata_collector
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2992863002 .
This is an attempt to get DDC's bot (https://travis-ci.org/dart-lang/sdk) green and restore test coverage, without affecting the Analyzer --strong buildbot. DDC and Analyzer can generally use the same status entries, as they are running nearly identical strong mode analysis. This fixes DDC's test builder to understand status codes in the same way analyzer does, as that was causing mismatch in statuses.
This does not fix the problem that we're skipping tests instead of recording the status. So there is a bit of test coverage lost, but it restores most of DDC's coverage. We can tackle the skips either in a follow up, or as we migrate tests from *_strong to *_2.
This is a partial revert of "Revert status file changes from 58a6227198d2aa927df19f1b4862f8d0017d6da4" in commit 7be946cf3d.
Review-Url: https://codereview.chromium.org/2990213002 .
This only handles compile time errors & compiler crashes. It does not yet support status files at runtime, that is still hard coded in language_tests.js. Some preliminary support for runtime status is there, but it's not enabled yet.
This also updates *_strong.status to reflect current test behavior. It looks like those files have not been triaged in a while.
R=rnystrom@google.com
Review-Url: https://codereview.chromium.org/2987093002 .
