The issue is:
lib/src/logger.html, line 107, inserted !:
In this case the single reason detail reads "node with no info (type(2171))" with no destination.
The problem is that InstrumentationInformation.nodeInfoFor is only
considering a limited set of possible sources of nullability nodes
(the primary nodes of decorated types passed to the instrumentation
listener methods `implicitReturnType`, `implicitType`, and
`implicitTypeArguments`). It needs to also consider decorated types
passed to `explicitTypeNullability`, `externalDecoratedType`, and
`externalDecoratedTypeParameterBound`, and it needs to walk these
decorated types recursively to discover all the nodes they point to.
Additionally, the logic in InstrumentationInformation.nodeInfoFor is
inefficient; it walks through all the implicit types in every source
file, which means that it is O(N) in the size of the code being
migrated. Since it is called O(N) times, this is an overall runtime
complexity of O(N^2).
I've prototyped a possible fix using an expando to compute
NodeInformation for each node once at the time it's reported to
instrumentation. This is incomplete and intended as a starting point
for discussion. Work that still needs to be done:
- We don't produce a sensible description string for nullability nodes
associated with AST nodes, so we present unhelpful text to the user
like "A nullable value can't be used as the explicit type ???"; it
would be nicer to say something like "A nullable value can't be used
as positional argument 0 of Level.>=". We may want to consider
modifying the instrumentation API to make it easier to generate a
useful string here.
- I haven't verified that the description string we produce for
external decorated types is helpful.
- I haven't verified that the we produce a useful link for external
decorated types.
- We should probably get rid of the data structure
NodeInformation.explicitTypeNullability (which has similar
inefficiencies) and change over code that was using it to use the
new approach.
Change-Id: I2cf2fe47cd70d7e5cc6e3da309851288668e8a62
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124902
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The zero length regions are being produced when server indicates that
navigation ought to target an unnamed constructor, a closure, a library,
or any other unnamed element. This might be a bug in server's navigation
support, but I don't want to have to fix that before the preview tool
can be used in a UX study.
Change-Id: I35c9978d38937006ee00d76516f3ee607fca6850
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124860
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Promoted bounds are not reified and don't make any difference at run
time. However, promoted bounds are taken into account when comparing
DartType nodes (since 75dc8483ab).
As a result, types which are different only in promoted bounds are
treated as not equal and reusing of type arguments doesn't work for
such types, which results in failed assertions in the VM.
The solution is to erase promoted bounds from type parameter types in
bytecode generator.
Fixes https://github.com/dart-lang/sdk/issues/39240
Change-Id: Ifc39592aa4e87d6273dd7ccf3129a381791609ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124900
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This has at least three advantages:
- Type safety. Only a valid variance value can ever be passed in to any
of the methods.
- Encapsulation. If we ever need to change the representation of
variance it will only need to be done in one place.
- Brevity. Much of the code is shorter and easier to read.
Change-Id: I82756f48aedd09232e9b8cdda155da83793a155f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124580
Reviewed-by: Kallen Tu <kallentu@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Previously, generated bytecode was cached using metadata in kernel AST.
When serializaing kernel AST (for subsequent compilations) incremental
serialization was not used, so AST serialization was considerably
slower in bytecode mode compared to non-bytecode mode.
Apparently, metadata is not compatible with incremental serialization
(https://github.com/dart-lang/sdk/issues/39302).
This change reimplements caching of generated bytecode using a separate
'foo.dill.cache' file near the generated 'foo.dill' and 'foo.dill.ast'.
AST is now written using incremental serialization both in bytecode
and non-bytecode modes.
flutter_test_performance benchmark:
AST mode:
"without_change_elapsed_time_ms": 2615-2652,
"implementation_change_elapsed_time_ms": 6292-6394,
"interface_change_elapsed_time_ms": 6183-6484,
"with_coverage_time_ms": 2723-2834
Bytecode mode, before this change:
"without_change_elapsed_time_ms": 3246-3295,
"implementation_change_elapsed_time_ms": 7998-8068,
"interface_change_elapsed_time_ms": 7899-8029,
"with_coverage_time_ms": 3316-3378
Bytecode mode, after this change:
"without_change_elapsed_time_ms": 2689-2737,
"implementation_change_elapsed_time_ms": 7630-7677,
"interface_change_elapsed_time_ms": 7724-7917,
"with_coverage_time_ms": 2841-2949
Change-Id: I603d33f49949146cf6620226d810f2f3cb9853a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124592
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
When implemention the incremental serializer, I forgot to pass it on in
the incremental kernel generators "IncrementalKernelGenerator.fromComponent"
and only did it in "IncrementalKernelGenerator", meaning that when using
"IncrementalKernelGenerator.fromComponent" the incremental serializer wasn't
used properly, namely nothing got invalidated.
Now it gets passed correctly, things get invalidated and everything should
be fine.
Fixes https://github.com/flutter/flutter/issues/44384.
Change-Id: Ic2e7f7330dc6ee62dd8e7bf6684d7bee8ee328bb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124684
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
* Treat the assertion condition offset as a character offset in the file.
* Allow unrecognized characters to be replaced by a placeholder character. This
is unrelated to the fix but is just a precautionary measure.
Fixed: 39271
Change-Id: I4871ea41d3a46d26ecac5047265a1dbc1c889350
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124602
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Brian Wilkerson