Previously, trying to access a static member of a class using '?.' was
not allowed. But the spec was changed in
b11670f899 so that
'ClassName?.staticMember' is now equivalent to
'ClassName.staticMember'.
This CL updates analyzer to follow the spec, and updates the tests in
"tests/language" accordingly. VM and dart2js still need fixing
(see #23794 and #23795).
Fixes#23464.
R=scheglov@google.com
Review URL: https://codereview.chromium.org//1255293005 .
As of commit 67b99e4b33, it is now
consistently a compile error for a prefix not to be followed by '.'.
(Previously, there were two exceptions in which a prefix not followed
by '.' was treated as though it was preceded by "this.")
This CL updates analyzer to be consistent with the new spec langauge,
and modifies the tests in tests/language accordingly.
Dart2js and the VM do not yet produce the correct compile-time error
in all circumstances. See issues #23611 and #23612.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1186033004.
The tests for e?.v++ and e?.v-- validate the spec text added in
58708e3 (as clarified by 1ab7736).
The tests for ++e?.v and --e?.v weren't mandated by any spec change,
but since these expressions weren't previously tested, it seemed
reasonable to add tests for them.
All tests pass under the current implementation of "?." in analyzer
and dart2js.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1177043010.
If 'p' is an import prefix, then 'p = ...' is treated as synonymous
with 'this.p = ...', and 'p()' is treated as synonymous with
'this.p()'. In all other circumstances where 'p' is not followed by
'.', the spec calls for a compile time error.
Previous to this CL, 'p' not followed by '.' was being treated as
synonymous with 'this.p' under all circumstances. This CL brings
analyzer in line with the spec, and updates the tests in
tests/language accordingly.
The VM and Dart2js currently fail to implement the compile-time error
properly. See issues #23611 and #23612.
Fixes issue #23461.
R=scheglov@google.com
Review URL: https://codereview.chromium.org//1173523002.
This CL adds the implementation of all null-aware operators to dart2js. In
particular:
* a?.b: represented as 'isConditional' in the Send ast, and dispatched
separately by the semantic visitor using visitIfNotNull* methods.
* a ?? b: represented as an operator, and dispatched separately by the semantic
visitor using the `visitIfNull` method.
* a ??= b: represented as a compound operator.
All except 2 tests are passing with the SSA backend (those 2 tests fail for
unrelated reasons). I've marked the CPS ir tests as failing for now.
BUG=
R=johnniwinther@google.com, paulberry@google.com, sra@google.com
Review URL: https://codereview.chromium.org//1151163004
Intestingly, the VM, dart2js/SSA and dart2js/CPS all fail the new test
in three different ways.
This CL fixed the SSA and CPS backends, and leaves a status line for
the VM.
When a constructor A redirects to B, it is B that should evaluate
declaration-site initializers (unless B also redirects).
Thus, this should happen after the arguments to B have been computed.
In SSA: Fields were initialized at A instead of B
(i.e. before redirect).
In CPS: Fields were initialized at both places, just horrible.
In VM: There seems to be a problem with redirecting constructors
called using super().
VM bug report: https://code.google.com/p/dart/issues/detail?id=23488
BUG=
R=floitsch@google.com
Review URL: https://codereview.chromium.org//1129693006
This test did not work as a multitest, because the
deferred_redirecting_factory_lib1.dart imports the main file - it will not
find it after the splitting and renaming.
Luckily it is not strictly required for the test (though somewhat cleaner)
to have a multitest.
BUG=
Review URL: https://codereview.chromium.org//1127023003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@45643 260f80e4-7a28-3924-810f-c04153c831b5
Wrap the await-for loop in a try-finally statement that ensures that
the stream is cancelled. Also adding the ability to the
AsyncStartStreamController class to return a cancellation future.
The cancel() call at the end of the await-for loop is not awaiting
the cancellation future yet. This is not part of the spec at this
point.
R=regis@google.com
Review URL: https://codereview.chromium.org//1014273003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@44689 260f80e4-7a28-3924-810f-c04153c831b5
When inlining code from a finally block before return or jump
instructions, do not restore the saved_try_context since the
inlined code is running in the context of the return or
jump instruction.
This is an old bug that surfaced in async code, since async code
deals with captured variables (contexts) much more than regular
code.
R=srdjan@google.com
Review URL: https://codereview.chromium.org//1006463003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@44465 260f80e4-7a28-3924-810f-c04153c831b5
Siva Annamalai