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>
This currently fails for the CFE with:
static error failures:
- Unexpected error at line 137, column 14: A value of type 'int?' can't be assigned to a variable of type 'int' because 'int?' is nullable and 'int' isn't.
- Unexpected error at line 137, column 25: Operand of null-aware operation '!' has type 'int' which excludes null.
Bug: https://github.com/dart-lang/sdk/issues/47338
Change-Id: Ia55e19a0bf296a8427f6510d6ddda5016acdecea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215101
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
The name being passed to the constructor didn't match the name of the
declaration. I chose to favor the name of the declaration, since it
more closely matched the similar error
`ParserErrorCode.TYPE_PARAMETER_ON_CONSTRUCTOR`.
Change-Id: I74e3c2a6411db85695ef6d9b4851602a29209a09
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214820
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL adjusts the test
language/constants_2018/constant_types_test
such that it expects no error when a type variable is used as a
potentially constant expression.
This feature was added for consistency as part of the constructor-
tearoffs feature bundle (because it can now be expressed anyway).
Change-Id: I5b58f2439699b24e3e3036cb0e3a0fcc9430d4c0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214644
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
It's clear from the comments that the first case was meant to test the
variable `v` (which has type `Object?`), and the second was meant to
test the variable `d` (which has type `dynamic`), but they
accidentally were both referring to `v`.
Change-Id: I1c36350689d20fa8d86c7d1c66918307f5fe2253
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214132
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
We use an extension getter instead of an instance getter because
it doesn't conflict with any potential existing or future enums
which want an element named `name`.
Keeping the namespace for enum elements open is a priority.
We currently only reserve `index` and `values`.
BUG: https://github.com/dart-lang/language/issues/1511
Fixes language issue #1511, which is a long-standing request,
and should replace a number of alternative implementations
which are based on parsing the `toString()`.
This version has two fields on the shared superclass, the index
and private name, and has a separate `toString` for each `enum` class
which hard-codes that enum's class name.
An earlier version had both `"name"` and `"ClassName.name"` as fields
to be able to reuse the same `toString` method on all enum classes,
but that cost too much for JS compiled code.
Even having just `ClassName.` as a field and then combining inside
`toString` requires more code to create the enum instances.
Instead this version hardcodes the `ClassName.` string once
in the `toString` method, which means each enum class has its own
toString (which can *potentially* be tree-shaken then.)
This still tree-shakes slightly worse than the previous implementation
where every enum class had its own `index` and `_name` fields
independent of each other, which could then be tree-shaken independently.
However, the `index` was already made an interface member with the
addition of the `Enum` interface, so code which accesses `.index`
on something of the `Enum` supertype could prevent tree-shaking of
all enum classes' `index` fields.
Likewise any general access to the "name" of an enum would necessarily
do the same for the name.
This CL makes up for some of that by sharing more implementation
between enum classes.
DartVM AOT CodeSize impact: ~0.15% regression on gallery (little less on big g3 app)
TEST= New tests added to enum_test.dart
Change-Id: Id25334e6c987f470f558de3c141d0e3ff542b020
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210480
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Previously we had identified this error with the analyzer error code
CompileTimeErrorCode.WRONG_NUMBER_OF_TYPE_ARGUMENTS_CONSTRUCTOR, but
they're not the same error at all. As a result, code like this:
var x = new a.b.c<C>();
would lead to the bogus analyzer error text "The constructor '{0}.{1}'
doesn't have type parameters." (with the placeholders "{0}" and "{1}"
visible to the user).
With this change, the error text is the same as that from the CFE: "A
constructor invocation can't have type arguments after the constructor
name."
Change-Id: Ib69d1ff8f7089e59b71d2dcd9a8ec51edffd94dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213621
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
1. Make unwrapException pure. This allows it to be removed if the
exception is unused, and ensures that the catch does not unnecessarily
invalidate locations. This is helpful since, by itself, this change
causes some test failures due to the load elimination bug (#47166).
2. Invalidate locations on entry to catch and finally blocks. This is
a conservative fix for #47166.
Bug: 47166
Change-Id: If3b4113b538978095d59814c16bd8375bbd70696
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213414
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
This test used `..` as a continuationToken (that is, it did not expect
a syntax error for `g(C<int, int> .. toString())`). This CL changes the
test to expect that to be a syntax error, and also eliminates the
static warning caused by using `?.` on a receiver with a known non-null
value (that's not relevant to the topic of this test, I just didn't
avoid it when the tests were written).
Change-Id: I275de6423710c3a598bedd2f54f4e9e7463a6d04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212587
Auto-Submit: Erik Ernst <eernst@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
1) double.truncate() now simply calls toInt(), omitting
truncateToDouble() call.
2) double.floor() and ceil() are now intrinsified on arm64 and AOT/x64
and generated using DoubleToInteger instruction.
3) DoubleToInteger instruction is extended to support floor and ceil.
On arm64 DoubleToInteger is implemented using fcvtms and fcvtps
instructions. On x64 DoubleToInteger is implemented using roundsd
under a check if it is supported (with a fallback to a stub and a
runtime call).
AOT/x64:
Before: BenchFloor(RunTime): 318.82148549569655 us.
After: BenchFloor(RunTime): 133.29430189936687 us.
TEST=ci
Closes https://github.com/dart-lang/sdk/issues/46876
Closes https://github.com/dart-lang/sdk/issues/46650
Change-Id: I16ca18faf97954f8e8e25f0b72a2bbfac5bdc672
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212381
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
This allows local variables and other expressions, as long as the
static type is a generic function type, to be explicitly type
instantiated.
* Expressions with a non-generic function type cannot be type
instantiated.
* Expressions with a type of `Function` cannot be type instantiated.
* Expressions with other non-function types cannot be type instantiated.
This results in doubling-up of errors in a few situations. I think these
are generally rare occurrences, and tricky to prevent double reporting,
so I've left them for now.
Bug: https://github.com/dart-lang/sdk/issues/46020,
Change-Id: Iad212fd95773f39f3202480b3fa71f6a28c7698f
https://github.com/dart-lang/language/issues/1812
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211941
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
E.g. if reporting a missing ";" after a SyntheticStringToken (e.g. a
inserted identifier) before this CL it would go to the next token and
say we expected the ";" after that, when really we expected it *before*
that token.
Change-Id: I2c358e017edb2f661e307eba03dddaee889086d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205799
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
* This message should only be reported by the parser; the
error raised in the analyzer was strictly duplicate.
* This message theoretically used to mention "async*" or
"sync*" depending on the modifier that the function in
question listed. However, listing one modifier or the
other is a red herring, and may confuse the user; any
function declared with one or the other is a "generator",
and the error applies equally to a "generator" using one
or the other modifier.
Bug: https://github.com/dart-lang/sdk/issues/43665
Change-Id: I6ef1f5c055473170e7563222f6f0a6c56a4ad5f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210801
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Previously, when encountering identifiers in metadata on a class's
type parameter, the analyzer would resolve them using the type
parameter scope, but then fall back on using implicit `this`. The CFE
would resolve them using the class body scope. In both cases, the end
result was that the annotation could refer to static class members.
This change brings the behavior of both the analyzer and the CFE in
line with the spec, by preventing the use of implicit `this` in these
annotations, and resolving them in the type parameter scope.
This is not expected to break any code in practice, because
annotations on type parameters are rare, as are annotations referring
to static class members, and the overlap between these two should be
negligibly small.
Fixes https://github.com/dart-lang/language/issues/1790.
Bug: https://github.com/dart-lang/language/issues/1790
Change-Id: Ibe5a421e04a53d29074a8b1509e1390658ed72e5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210040
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
language/covariant/type_parameter_test.dart performed a tearoff which
should incur a run-time error (because the dynamic type of the
tearoff is not a subtype of the static type, so it would be a
soundness violation to pass that value on to the next step of
evaluation).
Change-Id: Ia4ec813606e711cab0bdcc68d24bbac3c9a2d8c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209910
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Johnni Winther