This reverts commit 67f0d4daf0, and further optimises constructor contexts by preventing empty contexts.
Reason for revert: Includes fix for Flutter engine unit test failures.
Fixes https://github.com/dart-lang/sdk/issues/53506
Original change's description:
[dart2wasm] Replace `struct.new_default` with `struct.new` for object allocation.
When using the `struct.new_default` instruction for object allocation,
fields are always nullable and mutable. By using the `struct.new`
instruction instead, class fields can now have the same mutability and
nullability in Wasm as declared in Dart. In addition, the class ID and
type parameters (which are also stored in an object's struct), can now
be immutable and nonnullable as well.
To do this, object construction is now split into three functions:
(1) Initializer: evaluates initializers for instance fields and
constructor initializers (this constructor before super constructor).
(2) Constructor body: executes the constructor body (super constructor
before this constructor), with `this` pointed to the constructed object.
(3) Constructor allocator: which calls (1), allocates the object using
`struct.new`, then calls (2).
Because fields now have the correct mutability and nullability in Wasm,
this removes unnecessary null checks for nonnullable fields, and may
allow for better optimisations by Binaryen.
Fixes https://github.com/dart-lang/sdk/issues/51492
Change-Id: I13499bdc412f474bc76473115b6e63d6954f4d23
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326080
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Jess Lally <jessicalally@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
evaluateConstructorCall now returns a Constant, which means evaluation may be cut early in some places if there's an error. However, some code generators rely on _InstanceCreationEvaluator to complete, and so there's no _major_ changes to the design right now (and some small additions to avoid breaking many tests).
This CL is just the framework for the "return Constant" design and will be the base for reporting better errors in constructor invocations.
These changes already show that we cut some amount of over-reporting in our existing language and unit tests, which is a step in the right direction.
Bug: https://github.com/dart-lang/sdk/issues/47603, https://github.com/dart-lang/sdk/issues/47351, https://github.com/dart-lang/sdk/issues/49389
Change-Id: I5ba7f1282658884c18a32d5e98c7804bbfeac0f6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312347
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Mark tests that contain errors about using a class as a mixin to use
language version 2.19 where that's not an error.
This may not fix all of the tests because it's the language version of
the library where the class is declared that matters, not where the
class is used as a mixin. But most tests have all of their declarations
in the same library, so this should fix most.
Change-Id: I910439ebd2f10f731418dc588b7e4619a0841c16
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/285923
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
New language features made `futureOr(null) = 1` a syntactically
correct pattern assignment, so it should not be expected to cause a
syntax error. This CL changes that test case such that it is still an
assignment to a syntactically correct function invocation, but not a
correct pattern assignment (so it's again a syntax error).
Added more tests with similar properties: The 3.0 grammar causes some
test cases to be wrong, and this CL makes changes such that they will
continue to test "the same thing" as far as possible in the new
language.
Change-Id: Ie0166f1a599ffeebfd352f4fadc01abc0950bd0b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/279169
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@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>
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>
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>
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>
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 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>
Now that we have an AST and visitor support for the FunctionReference
structure (which represents `Expression<TypeArguments>` for various
kinds of expressions), we no longer need to error recover this as a
FunctionExpressionInvocation with synthetic arguments. The resolver
still doesn't resolve the syntax properly, but that's ok because it's
not permitted in valid code (for now we just treat it as having type
`dynamic`).
Fixes#46150.
Change-Id: I357175cc16bcf2f9027be2e1da66bb6ca70a9400
Bug: https://github.com/dart-lang/sdk/issues/46020
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/199682
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This CL adds parser support for use of `<typeArguments>` as a
selector. This allows expressions like `List<int>` (type literal with
type arguments), `f<int>` (function tear-off with type arguments),
`C.m<int>` (static method tear-off with type arguments), `EXPR.m<int>`
(instance method tear-off with type arguments), and `EXPR<int>`
(tear-off of `.call` method with type arguments).
I will add parser support for `.new` as a constructor name in a
follow-up CL.
Change-Id: I157e732276421e8c3fd20c38c67ae9643993bd85
Bug: https://github.com/dart-lang/sdk/issues/46020, https://github.com/dart-lang/sdk/issues/46044.
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/197102
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
I started doing this the normal way, but the two codes appear to differ
only based on whether the field was final, and I don't think that factor
is important to the nature of the error, so I think a single code is
sufficient.
Change-Id: I693dcfb1a2a4b47a8b82fe4860e7a61c82ca062e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/196880
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Add a test where a class that has no generative constructors
declares an instance variable which is final and has no initializing
expression. With https://github.com/dart-lang/language/pull/1130 this
is an error, and that error is expected by the test. Also test that
it is not an error to have an uninitialized final variable which is
abstract or external.
Change-Id: I6c4a46393f46587448612bd91fb99fa65f89704c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157490
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Jess Lally