Prior to this change, old problems (warnings, errors, etc) would not be
re-issued for files not actually recompiled when recompiling.
As an example, not making any change and recompiling it would seem like
everything was good.
With this change, all problems should be issued again.
Change-Id: Ia410edba27438d8a2f1842d9f4d81d0592571101
Reviewed-on: https://dart-review.googlesource.com/c/91747
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Fasta can generate synthetic libraries.
Previously we didn't include them when serializing, but that leaves
references in the binary to libraries that doesn't exist which isn't
ideal.
This change includes them, and adds a flag to kernel Libraries such that
we know they are synthetic.
Change-Id: Ied25a21cd1f384d318347021bc7ec18dae3a4e05
Reviewed-on: https://dart-review.googlesource.com/c/91722
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Prior to this change, problems issued in hierarchy.mixinInferrer could
be swallowed up because it was reported through a wrong loader that
had already issued the error.
Change-Id: Iecbc180ca8a0bfaa73db202e4cba9755812d1e3b
Reviewed-on: https://dart-review.googlesource.com/c/91746
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
If - for instance - a file (say 'main.dart') tries to include a part
(say 'lib.dart') that is not part of that file (i.e. doesn't state
something like 'part of "main.dart"'), and the file ('lib.dart') is not
otherwise used, before this change, the library ('lib.dart') would be
included in the first comile, but on subsequent re-compiles wouldn't
include it because it's not referenced, nor ever cleaned up
(and would thus be re-compiled.)
This change garbage-collects the library as it's not referenced.
Change-Id: I8fa90b3ae6fc3d99af9fec780abe62855e653ddb
Reviewed-on: https://dart-review.googlesource.com/c/90385
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
If, for instance, including something that is not a part of the file
you include it from, previously we would copy things over anyway, and
other libraries wouldn't be able to use it
(for instance including it would fail).
Now, instead, we don't include it, structurally pretending the "part of"
line wasn't there (that is, we don't copy things over and other libraries
are free to include it).
As before, an error is given, but errors doesn't 'cascade' into other
libraries that (before this change) couldn't use the included file.
Change-Id: Ica6225c437ea7dd66f9e8955e638f442b2df8f97
Reviewed-on: https://dart-review.googlesource.com/c/90380
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Get an error saying something like
"The argument type 'dart.core::String' can't be assigned to
the parameter type 'dart.core::String'"
Change-Id: I327c613a2070495653e4089475a4f3edf550e9d4
Reviewed-on: https://dart-review.googlesource.com/c/91228
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
These versions don't run the VM on the generated .dill files.
These tests are still "Slow" in status-file lingo, as they run for
about 30 seconds on a fast machine.
Change-Id: I7bd326a14c8f1f1905d4c6b4d5f850a95b135325
Reviewed-on: https://dart-review.googlesource.com/c/88967
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Notice that no conflict is reported when an inherited
setter is in conflict with an inherited member. This is
implemented in a later CL.
Before we would only use InheritedMembersConflict when merging
interfaces, but as the new test cases demonstrate, that's not
sufficient.
Change-Id: I690dde1b59499d3ee0967b3f118b0b3b58898442
Reviewed-on: https://dart-review.googlesource.com/c/88941
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
The criterion for an empty set/map literal without type arguments to
become a set literal was implemented as "superclass of Set and not
superclass of Map". This CL changes it to the rule now stated in the
spec: "subtype of Iterable and not subtype of Map".
Change-Id: I52d3a11e29ed9b1feb0f2b52a3f4beebe3833e31
Reviewed-on: https://dart-review.googlesource.com/c/88828
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
The test exposes three problems:
- The disambiguation criterion in the type inference is incorrect, as
it infers a map when the context is a LinkedHashSet. This will be
fixed in an upcoming CL.
- Assigning a map literal to a LinkedHashMap produces a static error
("isn't of expected type") due to exact types. Rules for exact types
are currently unspecified, and the language team has expressed some
interest in allowing this case. See also
https://github.com/dart-lang/sdk/issues/33307
- Type arguments for the map literal are not inferred from the context
when the outer context type is a LinkedHashMap. This is consistent
between the CFE and analyzer. If the LinkedHashMap case is to be
supported, this must be fixed as well.
Change-Id: I1519c844dae1f599306446c992cfe4825e4f20d4
Reviewed-on: https://dart-review.googlesource.com/c/88726
Reviewed-by: Peter von der Ahé <ahe@google.com>
Set literals can be disabled in individual suites by putting
"enableSetLiterals": "false" into the environment given to
FastaContext.create.
Also fixed a missing file offset on inferred empty set literals
which would trip up the front-end tests.
Change-Id: I76ad03e6ed03eb80045055f83fa0ab9acd62eed6
Reviewed-on: https://dart-review.googlesource.com/c/88722
Reviewed-by: Peter von der Ahé <ahe@google.com>
Add Kernel syntactic support for constants constructed by
bool.fromEnvironment, int.fromEnvironment, and String.fromEnvironment.
These values are not necessarily available at compile time. Because
constants can depend on these values, there is also an unevaluated constant
that represents an expression depending on environment values.
This syntax is not yet produced by the Fasta compiler.
Change-Id: Ie96ea7f60a7efcd35ac802b320a00f398d41232e
Reviewed-on: https://dart-review.googlesource.com/c/88827
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
A new approach to building the class hierarchy based on
Declarations/Builders. The new approach is that we perform
all kinds of override checks while building the hierarchy.
This is the first step of many, and it only builds the
hierarchy for class members (including superclasses, but not
interfaces).
The checks implemented so far are missing implementations,
and conflicts (can't override a method with a setter).
As I plan to reimplement most of Dart 2.0 semantics using a
bottom-up approach to type inference based on legacy mode,
I've changed the severity of MissingImplementationNotAbstract.
Change-Id: I002e0d0000aabe1623349d0c8119ca577c80ad01
Reviewed-on: https://dart-review.googlesource.com/c/87581
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Peter von der Ahé <ahe@google.com>
Kevin Millikin