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>
Chloe Stefantsova