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>
Previously, when the code being migrated referred to a nullable or a
non-nullable type in an already-migrated library, we would use the
`always` or `never` graph node to represent the nullability of the
type. This was problematic, because it made it difficult for
instrumentation to pinpoint precisely which element in an
already-migrated library was the cause of an expresion being
null-checked, or a type being made non-nullable.
We now create a fresh nullability node for each non-nullable type
coming from already-migrated code, with an edge to `always` or `never`
to ensure that the fresh node has the correct nullability, so that
instrumentation can see precisely which element it came from.
Since the migration tool doesn't traverse the ASTs of already-migrated
code, we can't report an AST node that caused such an edge, so an
`element` getter has been added EdgeOriginInfo to allow us to report
the element that caused the edge.
As before, types associated with already-migrated code are reported to
instrumentation via InstrumentationListener.externalDecoratedType. As
a new enhancement, bounds of generic parameters in already-migrated
code are reported to instrumentation via
InstrumentationListener.externalDecoratedTypeParameterBound.
Change-Id: Ided4e96e2920f8d9062688f5a6fda29b9b71dd12
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124000
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Also multiplex the service rather than the logger, so that we can
multiplex a crash reporting instrumentation service with a file logging
instrumentation service.
Change-Id: I7720c55e26225c27d2d9447a0156b2ca83da6598
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/122100
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
In moving to a pointer mixture network from a traditional language
model I had initially decreased model lookback to 50 tokens to
facilitate faster model training iteration. Now that we've landed
on a configuration that works well, increasing lookback to 100 tokens
improves accuracy further.
I also went ahead and followed a recommendation from Jacob to
oversample Flutter sources since they're greatly underrrepresented
in our training corpus compared to our users' code at prediction time.
Change-Id: I885ddb606270394198f3aca2554e381f4465bdae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124083
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Ari Aye <ariaye@google.com>
The goal is to stop implementing FunctionTypedElement in
FunctionTypeAliasElement, and keep only TypeParameterizedElement.
For some time we will have to keep implementing TypeDefiningElement, it
is used currently as a marker for top-level declarations.
Change-Id: I0062aaa66861a4d7dd5337eb9a44338ad49f5901
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123545
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
In the case where model doesn't find a CompletionSuggestion or
IncludedSuggestionRelevanceTag we previously created both in case
the client was holding a matching token in its cache. Now we instead
apply a contains check to includedElementNames and will create
an IncludedSuggestionRelevanceTag if a token exists client-side.
Otherwise we will create a CompletionSuggestion.
Bug: https://github.com/dart-lang/sdk/issues/37797
Change-Id: I558734b65d38d8833c414a4c2cc584d0a6d15b28
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123321
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Ari Aye <ariaye@google.com>
Latency had grown to over 100ms and after this change we're consistently
under 100ms https://i.imgur.com/CCo0iQa.png. In addition, I was able to reduce
the number of isolates to two from four, lowering the memory footprint of model.
The biggest change is that we're moving from taking a map of size |V| = 100k
like {"foo" => 0.2, "bar" => 0.3} and sorting it to find the top n completions
to simply filtering / selecting lexemes with probability greater than a min
threshold (set for now to be a percent of a percent, 0.0001).
Change-Id: I721e6de343add6b8ebcf3ef4fad20f136302808e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/122842
Commit-Queue: Ari Aye <ariaye@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Brian Wilkerson
