A field typed 'FutureOr<T>' may contain an instance of a Number type at runtime.
This fixes issue #35542 and adds a regression test.
Change-Id: Idd19dff3edc5e061da28ab2906c34b3133ea8bd8
Reviewed-on: https://dart-review.googlesource.com/c/88280
Commit-Queue: Régis Crelier <regis@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
So, that type inference that updates staticInvokeType later, in
StaticTypeAnalyzer._inferGenericInvocationExpression() also implicitly
updates methodNameType. This fixes the new set of exceptions that we
saw right before holidays. I'm running them now, most are green,
no reds yet.
R=brianwilkerson@google.com, paulberry@google.com
Change-Id: I53030a1a62a2a669549a47680c6c0c98b4031383
Reviewed-on: https://dart-review.googlesource.com/c/88227
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
... and rename endExpressionStatement to handleExpressionStatement.
This is needed for the next step in NNBD.
Change-Id: Ibed51f15a4e2d93d2b16a50e4e22e912f22d2171
Reviewed-on: https://dart-review.googlesource.com/c/88301
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
In future CLs, we'll switch from using the UnlinkedConst RPN
representation to the string representation. Making ExprBuilder.uc
private will help isolate the necessary changes to just one class.
Change-Id: I44c32c48d6275e3b4fd900a45a396876ed388ee2
Reviewed-on: https://dart-review.googlesource.com/c/88284
Auto-Submit: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Change-Id: I1c6cad6822d5528172e3ba036774fa58e7fd6432
Reviewed-on: https://dart-review.googlesource.com/c/88185
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Change-Id: I854a7d35b05f95d05f0b13f67677d2e512db4eeb
Reviewed-on: https://dart-review.googlesource.com/c/87844
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
Change-Id: Icb0f839defa96de186707a8cdc1046281d96fa6c
Reviewed-on: https://dart-review.googlesource.com/c/86931
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
This is preparatory work for #35418. The string representation is
produced, and tested via unit tests, but not yet used. In follow-up
CLs we will begin modifying the analyzer to make use of the string
representation, guarded by a flag at first to avoid incompatibilities
with older summary files. When it is safe to do so we'll hardcode the
flag and remove the old RPN representation.
Change-Id: Iab92ff742930f39761a9df6630f199359d76fcf6
Reviewed-on: https://dart-review.googlesource.com/c/88231
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In some cases, we could replace a binding instruction like a
InstanceCall with a subgraph that would end with a non-binding
instruction like a StoreInstanceFieldExpr. When the inliner attempted
to replace the uses of the former, the lack of an SSA temp in the latter
would cause weird results.
Change the code to check that the new replacement has an SSA temp, and
if it doesn't, use the temp assigned to the null constant in the flow
graph.
Closes https://github.com/dart-lang/sdk/issues/35481
Change-Id: Id90717b6a906703fb442f9cd0cacc3bc14fb4887
Reviewed-on: https://dart-review.googlesource.com/c/88321
Commit-Queue: Stevie Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
It currently compresses the empty fragment to zero bytes. However, RFC 7692
"Compression Extensions for WebSocket" 6.2.3.6. "Generating an Empty
Fragment" says that if the compression library produces no data, then an
empty uncompressed deflate block is used for this purpose. The 0x00 block
has the BFINAL header bit set to 0 and the BTYPE header set to 00 along with
5 bits of padding. This block decodes to zero bytes.
Chrome aborts the "Invalid frame header" when it receives a compressed
websocket frame with a zero length payload. This change fixes the websocket
implementation so it sends the 0x00 byte instead which decodes to the empty
data.
Bug: https://github.com/dart-lang/sdk/issues/35540
Change-Id: I581bf2cd362a25c5d88c9d9e31e8499a99f5fd13
Reviewed-on: https://dart-review.googlesource.com/c/88187
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Jonas Termansen <sortie@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>
It has implementation consequences to refer to classes that are not
declared in dart:core, and it increases the library/spec interaction surface.
This change removes all references to `LinkedHashSet` from the spec.
It changess the rule for when a `{}` is a set to be
context type is a subtype of `FutureOr^\inf(Iterable<Object>)`
and not a subtupe of `FutureOr^\inf(Map<Object,Object>)`.
That should *work* for
* `Iterable<X>`
* `Set<X>`
* `LinkedHashSet<X>`
* `HashSet<X>`
* `FutureOr<Set<X>>`
(with likely exect-type issues as usual).
Change-Id: I3074da27b36093075c8c83e9672bf2fdec135c1c
Reviewed-on: https://dart-review.googlesource.com/c/87972
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
The length is redundant if the list is delimited. Serializing the
length had the slight advantage of preallocating a list of the correct
size and the disadvantages of being harder to maintain by hand and
ugly to read.
Instead, delimit lists. The empty list is naturally ().
Change-Id: I17c14f4e0ca4934cfd3dcdf2a0047f87df80bb79
Reviewed-on: https://dart-review.googlesource.com/c/88320
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Daniel Hillerström <hillerstrom@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
In Dart2, the type relation "is more specific than" is no different than "is
subtype of". Since Dart1 is not supported anymore, type checking in the runtime
can be simplified and cleaned up.
Change-Id: I8e95b9e47146315c9a6f6c29b732ecbeb4e9ae97
Reviewed-on: https://dart-review.googlesource.com/c/88221
Commit-Queue: Régis Crelier <regis@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Example Dart file:
```dart
import 'package:meta/meta.dart';
@immutable class Foo {}
class Mutable {
int a;
bool b;
}
class Bar = Mutable with Foo;
class Baz extends Foo {
int a;
bool b;
}
class Quux extends Mutable with Foo {}
@immutable class Mut extends Baz {
int c;
bool d;
}
```
Error messages now look like:
Analyzing a.dart...
hint • This class (or a class which this class inherits from) is marked as @immutable, but one or more of its instance fields are not final: Baz.a, Baz.b at a.dart:12:7 • must_be_immutable
hint • This class (or a class which this class inherits from) is marked as @immutable, but one or more of its instance fields are not final: Mutable.a, Mutable.b at a.dart:17:7 • must_be_immutable
hint • This class (or a class which this class inherits from) is marked as @immutable, but one or more of its instance fields are not final: Mut.c, Mut.d, Baz.a, Baz.b at a.dart:19:18 • must_be_immutable
3 hints found.
Bug: https://github.com/dart-lang/sdk/issues/29394
Change-Id: Ib7aba7a4eb3f0ad35e459990558ad1866d5dd7d8
Reviewed-on: https://dart-review.googlesource.com/c/87860
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Bytecode generation doesn't work on incremental components as they
omit core libraries. As a temporary workaround, this CL disables
incremental compilation in bytecode mode in order to be able to run VM
with '--use-bytecode-compiler --observe' and get profiles.
Change-Id: Id843a03871d959e11acfb8f046019aa756ee7c65
Reviewed-on: https://dart-review.googlesource.com/c/88233
Commit-Queue: Alexander Aprelev <aam@google.com>
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
This reverts commit 5d3fb9f140.
Custom element constructors should not be involved in this
optimization since the fields should be assigned in the upgrade
constructor. It worked accidentally for 'null' since unassigned fields
were 'undefined'.
TBR=johnniwinther@google.com
Change-Id: I802673f1b92dad6b8f628473070278819adcd159
Reviewed-on: https://dart-review.googlesource.com/c/88232
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Auto-Submit: Stephen Adams <sra@google.com>
Serializing Let requires us to serialize variable declarations which are
complicated. They require us to support optional values because they
have an optional initializer. This is done by using a _ for none.
Having support for Let will allow us to support variable get and set.
Change-Id: I207183730389de70409ae6ca5017510420e36830
Reviewed-on: https://dart-review.googlesource.com/c/88182
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Daniel Hillerström <hillerstrom@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Use separate tags for the non-const and const versions of these
literals, just like the binary serializer does.
Change-Id: I3fabf02ce758a46ce55ff258723dd3ae11e6d497
Reviewed-on: https://dart-review.googlesource.com/c/88181
Reviewed-by: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
