Subclasses of the _Function class are generated on the fly as fields
with function types are encountered. Therefore, this class must be early
in the initialization order.
Change-Id: Ia0b998c443af9f6bdb4af512f6da99e6e3767c1f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/237681
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
It had bit rotted slightly: we were not properly accounting for
variance when gathering type inference constraints from the comparison
of two interface types.
Also, some of the tests needed to be updated to account for follow-on
errors.
Change-Id: Ife9feae3e2180a179ebc8503751690789dc1483e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/235941
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This adds formatting support for upcoming language features:
- Named arguments anywhere
- Enhanced enums
- "super." parameters
It doesn't change the formatting of any existing code, so it should be
safe to roll this in without coordinating a pre-built SDK roll.
I also went ahead and ran the formatter on the related language tests
since before now they couldn't be formatted. (And I incidentally ran
the formatter on the other enum tests sitting in the same directory.)
Edit: Actually there is one small change to existing formatting: enum
declarations will now get a blank line inserted before them. Most hand
authored enums already have this so will be unchanged but I see a few
diffs when formatting generated code.
Change-Id: Icefd9f10bedc589312396cf0ddb8eafc418f8dbf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/235284
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: William Hesse <whesse@google.com>
Currently, we decide whether to insert an implicit `.call` tearoff on
an expression based on the type the expression is being assigned to,
whereas the spec says that we decide it based on the context type.
In most cases, these are the same type, however when assigning to a
promoted variable, the context type is the promoted type, whereas the
"type being assigned to" is the unpromoted type.
Previously, we had no language tests of this behavior; it just emerged
naturally from the way it was implemented in the CFE. This test locks
down the behavior so that we won't change it by mistake.
We may, at some future time, decide to change it on purpose though.
Discussion about this behavior is ongoing on the langauge team.
Change-Id: I82f54c8875fd3b5829c5f75a676fdaf5eea64703
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233650
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL makes a lot of small corrections in enhanced_enums_basic_test,
e.g., references to variables whose name is slightly different in the
declaration and at the use site.
[Edit: This CL no longer adds a new test, `enhanced_enums_error_test`
already covers all the situations tested by that new test.]
Change-Id: I9d2aabd5ab740b91463eff12a5c676136bf4ec04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233384
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
The tests check that expected errors actually happen.
There might be *too many* error markers in the tests,
since it's not clear *where* an error is reported.
Is a naming conflict reported for one or both conflicting declarations?
Is a conflict reported on the class declaration or on a conflicting
declaration?
The front-ends might need to remove themselves from some of the errors,
when the error reporting strategy is decided, but they should report
at least *one* error for each problem.
Also fixed bugs in the non-error `enhanced_enum_basic_test.dart` file.
Change-Id: I673244d1d5a8803e5b49d53150a2b3ab47522c89
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/231950
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Currently, all the language tests that exercise implicit call tearoff
do so using expressions that are either instance creation expressions
(e.g. `new C()`, where `C` is a class containing a `.call` method) or
simple identifiers.
This test exercises all of the syntactic constructs which are capable
of undergoing implicit call tearoff.
This will help ensure that some upcoming analyzer changes don't break
implicit call tearoff support.
Change-Id: I3e6471a3ba22fb3e3be38f2721db549da631668a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232920
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
I'm not 100% sure we have a spec for precisely when we do implicit
call tearoffs and when we don't, but the CFE and analyzer agree on
this behavior, and I'm about to reorganize some of the analyzer code
that handles it, so I'd like to be sure the behavior is tested.
Change-Id: I1afee375181fde7b3a304aa8b71b23a45a337be0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232784
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Additionaly this CL moves the arguments checks for redirecting and
super initializer invocations from the early stage of their creation
to a later stage of their addition to the list of constructor
initializers, after the possible modifications to the arguments of the
invocation are performed.
Change-Id: I87a3710c885926a74c844288bdf266e7127a9c40
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/229967
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
In certain error recovery situations, it's possible for code to refer
to a variable whose declaration has been lost by error recovery
mechanisms. To prevent flow analysis from crashing when this
happened, it assumed that any reference to a variable whose
declaration had not yet been seen was valid, and implicitly added that
variable to the flow analysis state.
This created a subtle problem: if a function contained a closure that
declared (and assigned to) a local variable, at the time the closure
was entered, flow analysis would get confused and temporarily put the
variable in the "write captured" state (because it hadn't yet seen the
declaration of the variable, so it didn't realize it was local to the
closure). Then, a boolean variable might capture that incorrect
state. Later, upon seeing the declaration of the variable, it would
fix the incorrect state, however it was possible that a later
reference to the boolean variable would re-vivify the old incorrect
state. This is precisely what happened in issue #47991.
This CL fixes the problem by giving flow analysis the ability to
detect, at the time the FlowAnalysis object is constructed, all
variables that are referred to but not explicitly declared, and add
them to the flow analysis state. This allows it to safely assume that
any variables that are not yet in the flow analysis state haven't been
declared yet (and hence can be ignored), so no variable is every
erroneously placed into the "write captured" state.
Fixes#47991.
Bug: https://github.com/dart-lang/sdk/issues/47991
Change-Id: I8d84fab96fad063f1d3ade3b8b9a6e9af88c3737
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/227361
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
For `asyncExpectThrows`, instead of taking a function,
then checking if that function can be called with zero arguments,
and then immediately calling it and checking that it returns a future,
just take the future as argument.
Since synchronus errors from calling the function were not caught
anyway, doing the entire `Future` computation directly shouldn't
change behavior.
Also make `asyncExpectThrows` and `Expect.throws` return the caught error,
so that you can use normal `Expect.something` checks on it afterwards,
instead of doing that in the `check` function.
That basically makes the `check` function unnecessary (but hard to remove
with the existing test corpus using it heavily).
This makes some uses of the `asyncExpectThrows` function slightly more
complicated, those that have no other way to create a future than calling
the argument function anyway, but other uses become simpler
when they can avoid adding the function wrapper.
TEST= Refactoring. If the tests keep running, it's successful.
Change-Id: I983eb65ea4805760339073fabc27f78c57f9a471
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/226102
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Every AOT user out there has been using bare instructions mode
and continuing to maintaining non-bare instructions mode simply
adds costs (both in terms of time spent making changes to work
in a mode that is not used and CI resources spent on testing it).
This change removes FLAG_use_bare_instructions and changes the code
to assume that FLAG_precompiled_mode implies bare instructions.
TEST=ci
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-debug-x64c-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-dwarf-linux-product-x64-try,vm-kernel-precomp-obfuscate-linux-release-x64-try,app-kernel-linux-release-x64-try,app-kernel-linux-debug-x64-try
Change-Id: I5032b13bfcb613f79865f2cfa139cca8d1b42556
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/220964
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Remove messages referring to expired `non-nullable` experiment.
Remove occurrences of --enable-experiment with expired experiments.
TEST=Flags were expired. If existing tests still run, it's a success.
Change-Id: Id66d78eb0a3191ec5e31375faf0effd9ea7b768f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/219789
Auto-Submit: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
The JavaScript-to-JavaScript async transform had an inconsisent
handling of switch statements that contained an await, but only in the
expression.
For now the special handling of the expression-only case is disabled.
Change-Id: Ia79ff3951d681ba933df638da7e0e518d401ed9a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/219746
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Fixes https://github.com/dart-lang/sdk/issues/45958
Move check out of old checker.dart, into (less old) error_verifier.dart
and move test case out of old checker_test.dart. Add valid test case.
Rename INVALID_SUPER_INVOCATION to SUPER_INVOCATION_NOT_LAST, and
correct comment on that code (it has a parameter).
Do not duplicate report that code with MULTIPLE_SUPER_INVOCATIONS or
with SUPER_IN_REDIRECTING_CONSTRUCTOR.
Change-Id: I26e28b345fd8cef8ed2c9ec89ab12b56ea1c2f37
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/218982
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
In async/async* methods synthetic :try_finally_return_value variable
(which is used to hold return value across finally) could be
captured, so flow graph builder needs to have correct context_depth_
in order to access it using LoadLocal(finally_return_variable)
when building flow graph for return statement.
Previously, flow graph builder left context in an unspecified state
and depth after TranslateFinallyFinalizers(NULL, -1), which caused
incorrect code being generated for LoadLocal(finally_return_variable).
This change fixes this problem by
* passing correct target_context_depth to TranslateFinallyFinalizers
so context is adjusted to a known depth regardless of context
depth which is used by finally;
* setting context_depth_ for LoadLocal(finally_return_variable)
and then restoring it (to be able to continue building flow graph
for the enclosing AST nodes).
TEST=tests/language/async_star/regression_47610_test.dart
Fixes https://github.com/dart-lang/sdk/issues/47610
Change-Id: Id15ea719ddda892eaff0b06f6450b1a8de36e8da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/219283
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This is a preparation CL to remove the --enable-isolate-groups flag in
the VM.
The following tests were only running in --no-enable-isolate-groups and
are therefore obsolete now:
- runtime/tests/vm/dart/regress_47468_test.dart
- runtime/tests/vm/dart_2/regress_47468_test.dart
- tests/lib/isolate/illegal_msg_function_test.dart
- tests/lib_2/isolate/illegal_msg_function_test.dart
TEST=Changes tests only.
Change-Id: I6257cb667eebca66a649614d3010139dd2cdd3ab
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/219100
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Deprecates the class and makes it implement `Error` (more specifically
`UnsupportedError`).
Code throwing `IntegerDivisionByZeroException` should be migrated to
throwing `unsupportedError` directly, code catching the exception class
should start catching `UnsupportedError` immediately (or reconsider why
they are catching at all).
Integer division by zero also covers other ways that a double division
can give a non-number result (any infinity or NaN result of the division prior to calling `truncate()` on the result, will cause `~/` to throw).
Fixes#46776
Bug: https://github.com/dart-lang/sdk/issues/46776
Change-Id: Idf2657153dd16542e72c6ba921f587dd9fc9032a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208643
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
The WebSQL standard was abandoned more than 10 years ago and is not
supported by many browsers.
The `dart:web_sql` library was marked as deprecated in Dart 2.14. This
CL makes the library inaccesible, removes support for `dart:web_sql` imports,
and removes the `Window.openDatabase` API. The old code for `dart:web_sql` is
still generated by the html generators. Removing that will be handled by a
separate change.
Closes https://github.com/dart-lang/sdk/issues/46316
Change-Id: I892107396b3b227b4f33344377585aa5e5328288
Bug: https://github.com/dart-lang/sdk/issues/46316
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216080
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
These tests are updated to match the behavior which was specified in
dart-lang/language#1833. The change is valid for both language_2 and
language because it isn't tied to a language version. This should not
break any existing code because it only changes programs with
compile-time errors into programs with no errors.
(If we agree on this change then I'll approve the failures.)
Change-Id: I49f41fd1b1575c237c9c619c912de3e8de53356f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217016
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Previously, if a piece of code inside an extension tried erroneously
to refer to a static class member using instance access, the error
CompileTimeError.UNQUALIFIED_ACCESS_TO_STATIC_MEMBER_OF_EXTENDED_TYPE
would be reported. This change corrects the error to
CompileTimeError.INSTANCE_ACCESS_TO_STATIC_MEMBER.
In addition, the responsibility to report the error
CompileTimeError.INSTANCE_ACCESS_TO_STATIC_MEMBER is shifted fully to
the resolver (previously, it was split between the resolver and the
error verifier).
Change-Id: Idcd1a3b8a1e226fed692900838c3d2d3c0585d4f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217020
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Field::RecordStore inspects the object being pointed to. However,
it is not guaranteed that that objects has been initialized in
*DeserializationCluster::ReadEdges, that depends on the order of the
clusters.
In the reproduction, the TypedDataView cluster comes after the cluster
containing the instance. This leads to doing a field store while the
length field of the TypedDataView has not been read yet and is 0. This
causes a Field::RecordStore with value 0, which subsequently gets used
in compilation causing RangeErrors.
This CL delays the Field::RecordStore from ReadEdges to PostLoad so that
all objects are initialized before they are inspected by RecordStore.
TEST=tests/language/vm/regress_flutter_89584_test.dart
Fixes: https://github.com/flutter/flutter/issues/89584
Change-Id: I1d5fe25c4084d62d5e492446123987aee10200bb
Cq-Include-Trybots: luci.dart.try:vm-kernel-optcounter-threshold-linux-release-x64-try,vm-kernel-linux-debug-x64-try,vm-kernel-mac-debug-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-linux-debug-x64c-try,vm-kernel-reload-linux-debug-x64-try,vm-kernel-reload-rollback-linux-debug-x64-try,vm-kernel-nnbd-win-debug-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216181
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Aske Simon Christensen