It seems like the "missing" analysis error is a strong mode error, so I
don't think the error should even appear without strong mode turned on?
In any case, a "missing" error for non strong users is not something I
would expect to be blocking. Better to fix the build
Change-Id: I5f56b5847b655b501e8146200ab4b84fddbf21cc
Reviewed-on: https://dart-review.googlesource.com/56600
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Detect the following conflicts:
- declaring a method and inheriting a setter or getter with the same
name
- declaring a getter or setter and inheriting a method with the same
name
- inheriting both a method and a getter or setter (or both) with the
same name
Declaring a method and a getter with the same name is already
detected. Declaring a method and a setter with the same name is not
yet detected, because it should be done in the same way as
method/getter declaration conflicts.
Bug: https://github.com/dart-lang/sdk/issues/32613
Change-Id: I2d168894453d7032372388faa0872d3fc7aa9ef7
Reviewed-on: https://dart-review.googlesource.com/53803
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Also fix the type inference algorithm so that when it explores
multiple alternatives (as a result of the use of FutureOr<>), if one
alternative generated some constraints but failed to produce a match,
it rewinds those constraints and tries the other alternative.
(Previously, it erroneously assumed that if any constraints were
generated, the alternative matched successfully).
Also add unit tests to verify the proper operation of the subtype
match algorithm.
Fixes#32305.
Change-Id: I060b5d6d5247a68d2b27bba78819bae172e43d97
Reviewed-on: https://dart-review.googlesource.com/53685
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Since there were already non-negative tests with the same numbers, I
gave them meaningful names.
Merged a couple of tests into the same file when it made sense since
multitests let us do that.
Deleted prefix1_negative_test, because it essentially tested only that
a random identifier does not resolve, which is not particularly related
to prefixes.
Change-Id: I91718f6df5126f123d9a8ea3abbc6898797db2db
Reviewed-on: https://dart-review.googlesource.com/52985
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Found two mistakes in the tests:
- label2_negative_test had no labels whatsoever.
- label8_negative_test called an undefined function, doAgain().
Change-Id: I4d17c969a2b1422ff96cf68996225ecaaf5fe829
Reviewed-on: https://dart-review.googlesource.com/52868
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
In the process, I discovered multitests can't handle imports to
non-existent libraries. So I fixed that and cleaned up the code.
Change-Id: I9a8557e84f91ba7858bdf98f8732cd0ded55aa1a
Reviewed-on: https://dart-review.googlesource.com/52869
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
All fixes are related to the requirement that a concrete class must
implement its entire interface or have a non-trivial noSuchMethod
implementation.
Change-Id: I015e0565e5dd9cfa324c38bb43696e365c58329a
Reviewed-on: https://dart-review.googlesource.com/51880
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
* Preserve empty lines in the file header.
* Add empty entry to the tool's newly created sections.
* Remove extra empty line at the end of the file.
Change-Id: I271583774d5f5497025a9d85bcadf8b0b9e39e81
Reviewed-on: https://dart-review.googlesource.com/37600
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
This CL changes the way linker type inference works. Instead of
walking the operations in an UnlinkedExpr in order and inferring types
directly, it first builds an AST for the expression using ExprBuilder,
then uses ResolverVisitor to resolve the AST and perform type
inference.
This helps ensure that summary type inference and ordinary AST-based
type inference produce the same result, since they now use the same
core algorithm. In particular, this means that summary type inference
now does downwards inference properly.
Since the ResolverVisitor makes greater use of the element model than
the rest of the linker, this required implementing additional methods
in the linker's element model.
This CL includes some minor fixes to ExprBuilder that were uncovered
during testing. It also contains some minor changes to
ResolverVisitor to make it work during linking.
Fixes#32525.
Fixes#32394.
Change-Id: I5ec9b2bf5565ad30b8cc856475334323dc118da8
Reviewed-on: https://dart-review.googlesource.com/48741
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The changes to the CQ bot should take effect immediately. The changes
to the other bots will take effect once those bots are switched over
to use the test matrix.
Change-Id: Ibfe59817a11f730fd1847cdc60b3244b4a71a480
Reviewed-on: https://dart-review.googlesource.com/45300
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, we were setting `expression` incorrectly after generating
the implicit tear-off of .call, so if an implicit downcast was needed
as well, it was not attached to the proper kernel node, and the
resulting kernel representation was invalid.
Addresses the front end manifestation of #32426.
Change-Id: Ibd86b75c54a53db1fc4606b7583910c57e1c4aae
Reviewed-on: https://dart-review.googlesource.com/45522
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Original description:
Change front_end handling of callable classes.
This CL is the first in a series of CLs to change the handling of
callable classes in Dart 2.0.
For purposes of this description, a "callable class" is a class whose
interface contains a `.call` method.
In Dart 1.0, a callable class was considered to be a subtype of the
`.call` method's function type. This allowed the user to create
custom objects with similar behavior to closures, but with additional
fields and methods.
In Dart 2.0, a callable class is just an ordinary class, with no
subtype relation to any particular function type. (Note however that
it is still permissible for a class to declare that it "implements
Function").
To reduce the amount of code broken by this change, a piece of
syntactic sugar is being added: if an expression whose static type is
a callable class appears where a function type is expected, an
implicit tear-off of the `.call` method is inserted.
Note that it is still possible at compile time to invoke an expression
whose static type is a callable class, and it is still possible at
runtime to invoke an expression whose runtime type is a callable
class; in both cases, this is considered an implicit invocation of the
class's `.call` method. This is unchanged from Dart 1.0 behavior.
This CL introduces test cases for the new behavior, and implements the
implicit tear-off of `.call` in the front end.
Still to be implemented in future CLs:
- Spec text needs to be written.
- DDC/analyzer code needs to be written to perform implicit tear-offs
of `.call`.
- The subtyping algorithm in DDC, analyzer, VM, and dart2js needs to
be changed so that callable classes are no longer considered
subtypes of any particular function type.
- A small corner case involving type parameters still needs to be
addressed (see TODO in
pkg/front_end/lib/src/fasta/type_inference/type_inferrer.dart).
Fixes#32064.
Change-Id: I0d397c608321e25ba42cc02aa8a516aa77aa7c9d
Reviewed-on: https://dart-review.googlesource.com/41280
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This reverts commit f0a6330db0.
Reason for revert: Broken bots
Original change's description:
> Change front_end handling of callable classes.
>
> This CL is the first in a series of CLs to change the handling of
> callable classes in Dart 2.0.
>
> For purposes of this description, a "callable class" is a class whose
> interface contains a `.call` method.
>
> In Dart 1.0, a callable class was considered to be a subtype of the
> `.call` method's function type. This allowed the user to create
> custom objects with similar behavior to closures, but with additional
> fields and methods.
>
> In Dart 2.0, a callable class is just an ordinary class, with no
> subtype relation to any particular function type. (Note however that
> it is still permissible for a class to declare that it "implements
> Function").
>
> To reduce the amount of code broken by this change, a piece of
> syntactic sugar is being added: if an expression whose static type is
> a callable class appears where a function type is expected, an
> implicit tear-off of the `.call` method is inserted.
>
> Note that it is still possible at compile time to invoke an expression
> whose static type is a callable class, and it is still possible at
> runtime to invoke an expression whose runtime type is a callable
> class; in both cases, this is considered an implicit invocation of the
> class's `.call` method. This is unchanged from Dart 1.0 behavior.
>
> This CL introduces test cases for the new behavior, and implements the
> implicit tear-off of `.call` in the front end.
>
> Still to be implemented in future CLs:
>
> - Spec text needs to be written.
>
> - DDC/analyzer code needs to be written to perform implicit tear-offs
> of `.call`.
>
> - The subtyping algorithm in DDC, analyzer, VM, and dart2js needs to
> be changed so that callable classes are no longer considered
> subtypes of any particular function type.
>
> - A small corner case involving type parameters still needs to be
> addressed (see TODO in
> pkg/front_end/lib/src/fasta/type_inference/type_inferrer.dart).
>
> Fixes#32064.
>
> Change-Id: I6a86491047ae467a5e767cb3cc7cecb570b29308
> Reviewed-on: https://dart-review.googlesource.com/40508
> Commit-Queue: Paul Berry <paulberry@google.com>
> Reviewed-by: Kevin Millikin <kmillikin@google.com>
> Reviewed-by: Leaf Petersen <leafp@google.com>
> Reviewed-by: Erik Ernst <eernst@google.com>
TBR=paulberry@google.com,lrn@google.com,leafp@google.com,dmitryas@google.com,eernst@google.com,kmillikin@google.com
Change-Id: Ia3d3a6e46ceee2b2c55938bec95d09d50bbf06a7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/41240
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
(was reverted in https://dart-review.googlesource.com/c/sdk/+/40980
due to an analyzer bot breakage)
Original commit message:
Implement proper checking for callability of Function class.
There was some old (incorrect) logic for doing this, behind the flag
enableStrictCallChecks. This flag has been removed, since the new
behavior is now standard in Dart 2.0.
Fixes#31509
Change-Id: Ice5cf38bbc648badf7f2563ff930b69f9a799635
Reviewed-on: https://dart-review.googlesource.com/41120
Reviewed-by: Jonas Termansen <sortie@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Aske Simon Christensen