This CL removes the redundant/specialised implementation of
`isSubtypeOf` whose sole purpose was to enable prettier error messages
as printing of function types weren't particularly pretty. With
@askesc's work on prettier error printing (and being post the Dart 2.1
release) there is no longer a need to have special logic for
redirecting factories.
Change-Id: If9b20f0b304b970da42a495b0ed3e82494d82ed0
Reviewed-on: https://dart-review.googlesource.com/c/82067
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Change all the places that still used old-style asynchronous async in
Fasta. These were mostly in testing.
Change-Id: I102209aa54c7c6e658b9d6ec98167af62bf12f3e
Reviewed-on: https://dart-review.googlesource.com/c/87074
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
In Dart2, mixin application classes are generated by kernel and type resolution
is performed by kernel. In Dart1, using the VM parser, these tasks were done
during class and type finalization.
Change-Id: I927b1446d906ffd76ed9591c96e0d974df09f3bf
Reviewed-on: https://dart-review.googlesource.com/c/87025
Commit-Queue: Régis Crelier <regis@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
In Dart2, type bounds checking is either performed by the common front-end or
by explicitly generated code, but not by type finalization or runtime anymore,
as it was done in Dart1.
Consequently, the class BoundedType is not needed anymore, and malbounded or
malformed types are not seen by the runtime either.
Change-Id: I5d6e4c68d153d6730fa7ff7f6d9dcfa611299c16
Reviewed-on: https://dart-review.googlesource.com/c/86687
Commit-Queue: Régis Crelier <regis@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Samir Jindel <sjindel@google.com>
We get an AmbiguousBuilder if there are more than one redirecting
factory with the same name. We shouldn't crash though.
Fixes#35266.
Bug: 35266
Change-Id: I1ac0babdde49c4ca3966e6af5c580191baac0873
Reviewed-on: https://dart-review.googlesource.com/c/85390
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Before this CL, running fasta compile on these 3 tests would make it
crash in type inference because the enclosingClass on a constrcutor
is null:
tests/language_2/const_error_multiply_initialized_test.dart
tests/language_2/constructor_duplicate_final_test.dart
tests/language_2/field3_test.dart
Note that these tests are all multi-tests and they are here run
unprocessed. The compiler crashes only after issuing errors.
The crash likely happens because of multiple definitions of
constructors with the same name.
This is a cut-down version that crashed prior to this CL:
```
class C {
final d;
C() {}
C(this.d) {}
}
```
Fixes#35258.
Change-Id: I350c55428932ef0ae76f78875177b08acf95cdfc
Reviewed-on: https://dart-review.googlesource.com/c/85363
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Without this CL we end up putting a null-reference in the tree because
the parent is never set on the redirecting constructor we try pointing
to.
Fixes#35259, #35260.
Change-Id: I8ad520453742ff1de8dd9ca5e619f9edbff9971c
Reviewed-on: https://dart-review.googlesource.com/c/85384
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Type variable bound violations on constructor/factory invocations
now mention just the class name (which is the one that has the type
variables) instead of the constructor/factory name.
Change-Id: I65330f1921451fef0157be01b4a5086855d80439
Reviewed-on: https://dart-review.googlesource.com/c/85291
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Tests that bounds are printed when printing a generic function type,
and that the printer correctly distinguishes between no specified bound
(no bound printed) and explicit Object bound (Object printed as bound).
Change-Id: I747743d902a9eaf66cf65c579051175216960c63
Reviewed-on: https://dart-review.googlesource.com/c/84606
Reviewed-by: Peter von der Ahé <ahe@google.com>
This gets rid of the useless '#lib1::' prefixes on types in error
messages and instead adds a line to the error message for each
interface type appearing in the message stating where that type
originates.
Name clashes are disambiguated by appending markers like '/*1*/' and
'/*2*/' to the types whenever two interface types with the same name
appear in the same message.
The commonly used core types 'bool', 'num', 'int', 'double', 'String'
and 'Null' are excluded from the origin list unless they take part in a
name clash.
Change-Id: I017ea376d4f6ff2d4f3b36487774463f03bb3301
Reviewed-on: https://dart-review.googlesource.com/c/84604
Reviewed-by: Peter von der Ahé <ahe@google.com>
Previously we had several places where different uriToSource was used.
This was both weird and led to errors when something refering to
some state was used to look up in another state.
This CL makes it so we only have one source of truth.
To not include sdk sources when serializing a component that only mixes
something from the sdk in, (or extends it or...), the serialization is
changed slightly to keep track of which uris come from actual
implementation. Before the sdk sources was explicitly removed in the
incremental compiler, but we want to limit those kinds of things,
which is why we're doing it differently here.
Fixes#35215.
Bug: 35215
Change-Id: Iaa5618fcb0ea42b13aba7720f34a87a85144e047
Reviewed-on: https://dart-review.googlesource.com/c/85175
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
In the incremental compiler, if asking to invalidate a file via a file
uri, where the corresponding file is a part that has been used via its
package uri (as in "part 'package:foo/whatever.dart'"), we should still
invalidate it.
Before we didn't because we 'translated' the part uri to a 'file uri'
except it was still a package uri.
Now we do.
Change-Id: I276c6e7c772d6167178fa8b6594417d37d1dd1c4
Reviewed-on: https://dart-review.googlesource.com/c/85344
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Mixin declarations cannot be instantiated or extended, so they should
not have constructors. Adding a compiler-generated constructor causes
us to try to add an invocation of the default superclass constructor.
Because the superclass constraint is encoded as a superclass this can
cause a spurious error that is impossible to fix.
Fixes https://github.com/dart-lang/sdk/issues/35011
Change-Id: Ia8f99d00b1a5b042da233d54f3cc1f0c6345e779
Reviewed-on: https://dart-review.googlesource.com/c/82447
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Peter von der Ahé