This update the position used for reporting a mixin class primary constructor with a primary constructor by declaration with initializers or an explicit body. Since mixin classes can have simple constructors, it makes more sense to report the error on the offending syntax than on the primary constructor itself.
The CL also updates the offset used for field initializers to the field name rather than the `=`. This align the offset with what is used for property sets.
Change-Id: Id5ccd55536b2c3b9d9336d2854772c1bcc5a175a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/490800
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Not removing from any file with a language marker.
Also not touching anything in `tests/language/primary_constructors`
or `.../private_named_parameters`, which are both assumed to be
primary constructor feature aware.
Two files rewritten from multi-test to error-test.
Change-Id: I43d444a35a41c7734f266794e9f167655692473f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480640
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
When a class declares the same instance field name more than once, the
"not initialized by this constructor" diagnostics are inherently
cascading. The root problem is the duplicate definition, and there is no
single unambiguous field declaration for the constructor verifier to
reason about.
Track duplicate field names per interface and suppress constructor
field-initialization diagnostics for those names (both final and
non-nullable). This avoids emitting misleading `finalNotInitialized*`
errors in code that is already invalid due to a duplicate field.
Update language/diagnostic expectations accordingly, including the
constructor regression and PrNP collision annotations.
Change-Id: I1095bae9ce0aaa876cbacaa970d7379ed70d7568
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/475560
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This moves checking of arguments on initializers to the inference visitor. This prepares for separating ArgumentsImpl from Arguments by ensuring that checking is always performed on ArgumentsImpl.
Change-Id: I41e96377d141034adecf03bc7d0f130eb260fb72
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/466061
Reviewed-by: Erik Ernst <eernst@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
The new feature 'declaring constructors' will change the syntax such
that it is an error for a non-declaring formal parameter declaration
to have the modifier `final`, and it is an error to use `var` as a
replacement for a type annotation (but the type annotation can still
be omitted entirely). This CL removes those modifiers such that the
tests will not start failing on things that aren't errors any more.
Change-Id: Ie6628f66eca696b28900759d8234b814033b4027
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/456740
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
This adds `LookupResult.isInvalidLookup` to the handle invalid lookup
results and uses this to avoid a lot of cascading error messages.
This is a step towards removing ProblemBuilder, AmbiguousBuilder and
reliance on `NamedBuilder.isDuplicate` in lookups.
Change-Id: Ia9d558ce55b45567607282295dd1e54e6187f9c5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/441880
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
The new formatter supports opting a region of code out from being
formatted. I'm applying this marker to all of the multitests since
those tests are often very sensitive to formatting and easily broken.
This way, anyone touching a multitest (including me when I reformat
the tests) doesn't have to remember to not run the formatter on it.
Unfortunately, this doesn't opt out 100# of the multitests. There are a
handful of multitests that also contain "@dart=" comments and are thus
formatted using the old style where the "// dart format off" marker has
no effect. For those, we'll have to still be careful to not accidentally
format them.
Change-Id: I257d0ee1eb44eee57047be06b8520f0ccc7b56d3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/396162
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Collects files from `package:async_helper` and `tests/language`
that are generally useful, so that all test-related helpers are
in `package:expect`.
Moves the two libraries from `package:async_helper` into `package:expect`,
and the `tests/language/static_type_helper.dart` file too.
Deprecates `async_minitest.dart`, to follow `minitest.dart`,
expecting the Flutter use of it to have been fixed to not break
on deprecation (I believe Flutter no longer breaks builds on deprecations at all).
Patch 1 is the actual change.
Patch 2+4+8 is changing all existing references to the files.
Patch 6 ignores deprecation in files still using `async_minitest.dart`.
3+5+7+9 are updating this text to make the numbers match.
Then it's just test-expectations and small tweaks from there.
Change-Id: I1b665135b5fef9b9a0c3b340ffe9daf874d0174c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373120
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Devon Carew <devoncarew@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
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>
Johnni Winther