Dart 2 shipped a year ago, so we're pretty well past a "preview". :)
Change-Id: I6c5d21ae4181e4228cc1fc49b6344cdb8fc43794
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115544
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Previously we were doing a deep comparison, but this wasn't
sustainable. The reason _variableInfosEqual exists is to verify the
logic used by FlowModel.restrict() to determine whether to re-use a
previous variableInfo structure. Since that logic is based on a
shallow comparison, the logic in _variableInfosEqual needs to do a
shallow comparison as well.
Change-Id: Id0f48a3f450a9210d4f6e6d919bb7a3e311ad458
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115621
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
So, the type of `a?.b.c` is nullable, but the type of `c` is not.
Everything after `a?` is just not executed if `a` is null.
R=brianwilkerson@google.com
Change-Id: I705051080b8cc2bb5014355688561b0f3dccc0d8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115660
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Handle allocation is extremely common, and it always already has a call to VMHandles::Allocate[Zone]Handle, so we save a lot of binary size by avoiding inlining the TLS and initialization code.
-488k (-2.04%) out/ProductX64/exe.stripped/dart
-256k (-5.07%) out/ProductX64/exe.stripped/dart_precompiled_runtime
Change-Id: I677005c9653c87597ba20144b4326b66d0bf0ee5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115608
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Issue https://github.com/dart-lang/sdk/issues/38141
On Windows and OSX, we dynamically link against libc++, so there is no issue.
On Android we already hide symbols from libc++.
Change-Id: I17debc4d0efec3cebc203672333afb44390b0e0b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115403
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Samir Jindel <sjindel@google.com>
Change-Id: I48ac4ab6ec1b60a4b6ecec3976a1bba7483f6e12
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115682
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Karl Klose <karlklose@google.com>
Generated rethrow statements do not require a 'DebugCheck', but explicit rethrow
statements do, so that user breakpoints can be set on rethrow.
Add a IsDebuggable flag on bytecode closures and set it properly.
Remove unused code in a service test.
Add verbosity to debugger.
Change-Id: Ia436cbe62e38cfaec6f9fdf7f8cc2ee5607228e6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115602
Commit-Queue: Régis Crelier <regis@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Rationale:
Two safe non-speculative cases were missing,
causing AOT to crash on some fuzzing sessions.
Note fuzzer is regression test here.
https://github.com/dart-lang/sdk/issues/38145
Change-Id: I12c633d66e387c703f1bcf0b6eebd50165bb2970
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115445
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Aart Bik <ajcbik@google.com>
When running from a dill file with AST on the VM with bytecode, we should
ensure that bytecode class declarations are loaded when class is referenced
from a type in AST. Otherwise we could attempt to finalize a type without
proper class declaration.
This change fixes pkg/vm/test/transformations/protobuf_aware_treeshaker/treeshaker_test
with bytecode.
Change-Id: I7a9975e1af6b9e04575f41c5e78b1c2154106e31
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115460
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Rationale:
Control flow collections are already the default for
a while, but this TODO was still there. We are now
testing all features of CFC fully. Also did some
comment cleanup and removed old-style "new" syntax.
Moved constructors into try-catch just in case
we will add code into constructors in the future.
Change-Id: I557650575f41d7501a0c6f37c07756ca47ad54fd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115444
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Aart Bik <ajcbik@google.com>
Two changes:
- Rather than remember to call `FlowAnalysis.finish` at the end of
each test, we now have a `_Harness.run` method that calls it
automatically.
- Variables are created using `_Harness.addVar` and their declarations
are reported to flow analysis using `_Harness.declare`. This allows
us to more easily test scenarios where a variable might be
referenced before its declaration site is encountered (which might
occur due to analyzer error recovery).
Change-Id: I0eff619840aeb057dcce8d64b6c6d23a265f81bd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115421
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Fixes ~22 exceptions with a stacktrace containing the line:
DecoratedClassHierarchy.getDecoratedSupertype (package:nnbd_migration/src/decorated_class_hierarchy.dart:59:10)
Change-Id: I59bfcf19044f2bd985ec9bd4b33f307f9ab5bb24
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115121
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The first bug was that we were assigning an empty map to
`_genericSupertypeDecorations[class_]` prior to computing the supertype
decorations, and then updating the map in place. This meant that if
an exception occurred while computing the supertype decorations, then
any subsequent requests for supertype decorations on the same class
would lead a partial result. This led to a lot of weird
counterintuitive behavior.
The second bug was that `Variables.decoratedDirectSupertypes` wasn't
updating the `_decoratedDirectSupertypes` object when an entry wasn't
found; as a result, we were doing a lot of redundant computation.
This should address ~184 exceptions whose stack trace includes the line:
DecoratedClassHierarchy.getDecoratedSupertype (package:nnbd_migration/src/decorated_class_hierarchy.dart:59:10)
Change-Id: I7b7e5191f77c0e1d299923a99d841b6c11ca28c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115075
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
