The CFE implementation of "why not promoted" functionality for
non-promotion of `this` doesn't associate the context message with any
location information, because there is no relevant location to cite.
For example, the output can look like this:
tests/language/why_not_promoted/this_error_test.dart:16:10: Error: Property 'isEven' cannot be accessed on 'int?' because it is potentially null.
Try accessing using ?. instead.
this.isEven;
^^^^^^
Context: 'this' can't be promoted.
See http://dart.dev/go/non-promo-this
The test runner assumes that all messages have a location, so it
wasn't picking up on this context message at all. This CL avoids the
problem by having the test runner associate any location-less context
message with the error above it.
(Note that the analyzer doesn't have this problem; all of its context
messages have locations).
Change-Id: Ied52daa8b0090f28617e7d3784233aa44dcc897a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/195301
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Marks `Function` as an extensible type so that DDC knows to use the
symbolized version of the equals operator.
The `Function` class at runtime already has its equals method attached
as the "symbolized" version. Consider `a == b`. When DDC knows `a` is
statically a raw `Function` and non-nullable (more likely with sound
null safety) the generated code should call the symbolized equals
member ex: `a[$_equals](b)`. Without this change the generated code
would be `a.equals(b)` and fail at runtime because the method does
not exist.
With this change co19_2/LibTest/core/Function/operator_eq_A01_t01
starts passing.
Change-Id: I80dd2abbbb04f1b7ab7e21dd14561a45f6e81459
Fixes: https://github.com/dart-lang/sdk/issues/45601
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/194204
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Previously, if a type mismatch occurred on a named argument, e.g.:
int.fromEnvironment('foo', defaultValue: 'BAD')
the error would be reported on the entire NamedExpression
(`defaultValue: 'BAD'` in this example). Now, the error is just
reported on the expression (`'BAD'` in this example). This makes the
analyzer behavior more self-consistent (since now assignability errors
are now consistently reported at the site of the expression that can't
be assigned). It also makes the analyzer behavior more consistent
with the CFE.
This will make it possible, in a follow-up CL, to eliminate a lot of
the inconsistencies between analyzer and CFE in the "why not promoted"
ID tests.
Change-Id: I17db256959d730a22a5766f65d5c0736b627f244
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/195489
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
While deserializing AOT snapshot, Code objects which do not contain
valuable information besides entry point and stack maps are discarded
and not allocated on the heap (they are replaced with
StubCode::UnknownDartCode()).
PC -> Code/CompressedStackMaps lookup is implemented using a separate
table (InstructionsTable).
Flutter gallery in release-sizeopt mode:
Heap size of snapshot objects: arm -26.89%, arm64 -27.68%
Large Flutter application in release mode with --dwarf-stack-traces:
Heap size of snapshot objects: -24.3%.
Discarded Code objects: 72.5% of all Code objects.
Issue: https://github.com/dart-lang/sdk/issues/44852.
TEST=existing tests; "--dwarf_stack_traces --no-retain_function_objects
--no-retain_code_objects" mode is enabled for a few tests.
Change-Id: I5fe3e283630c8e8f4442319d5dcae38d174dd0d8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/189560
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This is clearer because:
- The use of "could not be promoted" is consistent with the other "why
not promoted" messages.
- We avoid speculating about whether the variable might be assigned a
null value; this should help avoid confusion in cases where the user
can see that assigning a null value is impossible, but promotion
still fails.
- We avoid the phrase "intervening write", which is a little too
erudite.
Bug: https://github.com/dart-lang/sdk/issues/44898
Change-Id: I0b8a2132dc99dd06769677f98e6257e9b55ad9d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193820
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
This changes the span reported from the _receiver_ to
the _use_ (method name, property name, operator token).
I think this change is overall an improvement.
Specifically, its a great improvement for cmdline
output, where the receiver and the "use" are on
different lines.
One possibly weird change is that if the operator is `[]`,
then I only highlight the `[` character. I don't know if
there is a better place, and I think this is fine.
Fixes https://github.com/dart-lang/sdk/issues/43708
Change-Id: Ie66ddf04b4904a367575193106385dd63ee39985
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/188680
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Before value is stored into Float32List, it is converted to 32-bit
float using DoubleToFloat instruction. If allocation sinking
eliminated the allocation of Float32List but we need to deoptimize,
the list is materialized and elements are filled. In such case,
we shouldn't perform double->float conversion as it already happened.
This change also updates the assertion in DoubleToFloatInstr::Canonicalize
which verifies that DoubleToFloat instruction can be used only
in certain cases.
TEST=tests/language/vm/allocation_sinking_arrays_test.dart
Fixes https://github.com/dart-lang/sdk/issues/45547
Change-Id: I9a1bd28a9fc09bccad6aa3c91a7880abd002f7c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193831
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Elimination of redundant type cast 'x as Function' where x is
a function type (such as 'void Function(int)') is not correct because
it changes semantics of a function call if such expression is
used as a receiver.
"Function" static type of receiver allows arbitrary function calls,
while known function type of the receiver means the call doesn't
need to check parameter types. Static type of receiver is currently
not stored in kernel AST but calculated from the receiver node,
so replacing 'x as Function' with 'x' changes static type of
the receiver from "Function" to function type.
TEST=tests/language/regress/regress45428_test.dart
Fixes https://github.com/dart-lang/sdk/issues/45428
Change-Id: If7148450526703daa63a442adf67a9e7a2dcea54
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193524
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Now they are only retained if one of the following is true:
* The parent is Future.wait or Future.timeout.
* The local function is a generated body of an async/async*/sync*
function.
* Symbolic stack traces are enabled.
When a local closure's parent is dropped, the parent name will
be printed as `<optimized out>` in places like exceptions.
Changes in Flutter gallery in release-sizeopt mode:
* ARM7: ROData -1.41%, Isolate snapshot -2.35%, Total snapshot -0.54%,
Isolate heap -1.38%, Total heap -1.38%
* ARM8: ROData -1.55%, Isolate snapshot -2.34%, Total snapshot -0.65%,
Isolate heap -1.41%, Total heap -1.41%
TEST=Existing tests on CI.
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-nnbd-linux-release-x64-try, vm-kernel-precomp-dwarf-linux-product-x64-try
Change-Id: I9d05f9e0e30e9f428eff16a15b0f1eeb974419c8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/190023
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Brian Wilkerson