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>
Change-Id: I04368d00010e81148c608ba0d8f0371a516862e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213966
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Erik Ernst <eernst@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>
Fixes#47190
TEST=None, only markdown files where edited.
Change-Id: Ife204f9c792b6bce30d0cd7bf2260ced11c8f2b4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213049
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Alexander Thomas <athom@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>
Change-Id: Ia1c5b6b2365849a6c69b1db2bf1878ca64dfd65b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211420
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@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>
Previously, initializers of implicitly typed variables did not
contribute to the SSA tracking performed by flow analysis (see
https://github.com/dart-lang/language/issues/1785). This change fixes
the bug, however the fix is conditioned on the "constructor tearoffs"
language feature to avoid compatibility issues (we don't want someone
to publish a package taking advantage of the fix, without realizing
that it makes their package unusable on older SDKs).
TEST=standard trybots
Bug: https://github.com/dart-lang/language/issues/1785
Change-Id: I1143440c7a9795b059e8f4b84e3f4125cd80732c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211306
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Change-Id: I3ea0be4032c3f9999239f2ae58514d21df9045d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211281
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Change-Id: I750345600d3b47de44c060511be35aea8744eca3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211140
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
https://github.com/dart-lang/language/issues/1785 has a wide enough
impact that its fix will have to be bundled in with a language version
(i.e. future versions of Dart will have to reproduce the old buggy
behavior for code that's not opted in to the latest language version).
Therefore, we'll have to maintain tests of the behavior both before
and after the fix. This CL is the first step in that process, adding
tests that validate the current (buggy) behavior.
Bug: https://github.com/dart-lang/language/issues/1785
Change-Id: I78f17999ac1cbc096a312ef977db24654e06a263
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210400
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@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>
On one hand this is less precise, OTOH this tells which feature and
the language version it requires.
Change-Id: I1d24a2d7cf2c7b7ca305d5bfc9f094fce0734bc4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210644
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: 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>
This CL changes the test
language/generic_methods/explicit_instantiated_tearoff_test.dart
such that it no longer expects a generic instantiation of a local
function tearoff to be notEqual to another function object which is
the same local function, same enclosing invocation, same type
arguments.
The rationale is that we should not preclude an optimization whereby
these function objects are canonicalized (at run time, or if they
can be lifted to the top level even possibly at compile time).
Change-Id: I5845a19ce9ccf931c4d3abe4ab619f3ed2a2fbc4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209860
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
This should handle all cases of constructor reference w/ explicit type
args; there aren't too many cases:
* named and unnamed constructors
* referencing class and referencing type alias
* prefixed class names and not-prefixed
* null-aware access (weird)
* bound on type parameter of class, and on type parameter of alias
error cases:
* cascade
* wrong number of type arguments
Bug: https://github.com/dart-lang/sdk/issues/46020
Change-Id: If257eb561a9ad854709b6e9a7d81faa9d084d6ee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209622
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The instantiation at runtime implies non-constant type expressions
but canonicalization is unspecified so backends should be allowed
to optimize by canonicalizing types.
Change-Id: I2f1cab6ac68a1ce156b15af0b99e02d03b7b3dca
Issue: https://github.com/dart-lang/sdk/issues/46837
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209663
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
We might get different flags on lhs and rhs of a subtype check as
lhs might come from a tear-off which has generic-covariant-impl type
parameters and rhs is a standalone function type.
TEST=language/regress/regress46816_test
Fixes https://github.com/dart-lang/sdk/issues/46816
Change-Id: Ic0f1b4a9fdf0f4c9ae65c8c372d12c1e51ad8050
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209265
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This CL restores the equality related tests in
tests/language/closure/identity_equality_tearoff_test.dart that we had
in https://dart-review.googlesource.com/c/sdk/+/202243, but removed
in order to finalize language team discussions about equality of
function objects, based on language issue #1712.
Note that these additional test cases do not include any cases involving
tearoffs of extension methods, they will be dealt with separately.
Change-Id: I84daaf91229bd0d0f4c64446bb71cb87f32eedfc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205081
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Said test expects a raw type literal (e.g., `Direct`) to evaluate to an
instantiation where the type argument is `Object?` (`Direct<Object?>`),
but the type argument is actually chosen by instantiation to bound,
so the resulting type argument is `dynamic` (`Direct<dynamic>`). This
CL adjusts the test to expect `dynamic`.
Bug: https://github.com/dart-lang/sdk/issues/46811
Change-Id: I06af0bf87ccb5e980e88416085921948dd5234d1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209081
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Replace bogus body created for redirecting factories with a
normal body which calls target factory or constructor and
forwards all arguments. Such a body can be used by back-ends
if they choose to treat redirecting factories as ordinary
factories.
TEST=ci
Fixes https://github.com/dart-lang/sdk/issues/41915
Issue https://github.com/dart-lang/sdk/issues/46231
Change-Id: I62c83bcc9005995e85de049d3d929ca86a75297f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208681
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The test aliased_constructor_tear_off_test.dart expected torn off
constructors to be unequal even in cases where the same constructor
is torn off and instantiated with the same type argument (albeit a
non-constant type). That equality _should_ hold, and this PR makes
the change needed to give the test that expectation.
The test tear_off_test.dart was adjusted similarly.
Change-Id: I79c8dbd312a393b4f509aa28fc46c06ffc77da5d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208658
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Extension method closurizations are specified to be unequal unless they
are identical (because the extension itself may have different type
arguments, so it's not enough that it is "the same method").
This CL changes the test
language/generic_methods/explicit_instantiated_tearoff_test.dart
such that its expectations match that property.
Change-Id: Ife31646623099ad5d1b970d0097d37d6b00c5814
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208645
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
We were lacking tests for doing a `null` lookup in const maps and sets.
Also, we were lacking tests for having type literals with user-defined
classes in const maps and sets.
Bug: https://github.com/dart-lang/sdk/issues/45908
Change-Id: I1665420ddcc71df7b47a87ee9e16d7ebbe9e13f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208080
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Previously, prologue builder omitted loading of delayed type arguments
from closure object in case of inling. This would effectively switch
from using delayed type arguments of an instantiated generic closure to
type arguments passed on the stack (null/all-dynamic if none), which is
not correct.
The fix is to load delayed type arguments from closure object even
in case of inlining.
TEST=tests/language/regress/regress46550_test.dart
Fixes https://github.com/dart-lang/sdk/issues/46550
Change-Id: Ibe50b0bc2ebda1d3638c4940fe9a26cd5ba7ce32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207704
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
Two different const functions should not be identical.
Change-Id: I3974574c8d0cb34b9cf886532c41e1a77ae632a4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206422
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
