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>
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>
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>
This is one of the rare cases where the comment was correct
and the code was wrong. If we've typed class FooB^ then the
query should be ['class'] whereas typing void main(^ should
result in the query ['void', 'main', '('].
Change-Id: I5f53fa70c1ddfd1803e5697cdaaaf7d3b73f5ae2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/121778
Reviewed-by: Jaime Wren <jwren@google.com>
Commit-Queue: Ari Aye <ariaye@google.com>
Here we can see the mixture network is assigning probability mass
to a new, project-specific name by reference https://i.imgur.com/6Zbs2qf.png.
I also took this opportunity to decrease model size targeting 100M, in line
with our original size goals.
My initial strategy was to implement a separate pointer network
in https://dart-review.googlesource.com/c/sdk/+/117005 but having
a single network that can assign probability mass across local
references and vocabulary lexemes is better since
1) only one network and model file
2) no need to coalesce predictions from multiple models
Change-Id: I23cfc2ece61ce30bb69785149a5a6cf1604af18d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/121461
Commit-Queue: Ari Aye <ariaye@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
* NavigationTargets which are ConstructorDeclarations should point to the
constructor's name or its return type for unnamed constructors.
* Details which don't included useful targets, like "this parameter is
optional and has no default value", should just have detail descriptions,
but not be links.
Change-Id: I3562bb708c40aa1fcf1de5df5519f1f4037517cb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/120761
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This makes trial_migration.dart report two new exceptions:
_EdgeBuilder&GeneralizingAstVisitor&_AssignmentChecker._checkAssignment (package:nnbd_migration/src/edge_builder.dart:2169:14) (x30)
_EdgeBuilder&GeneralizingAstVisitor&_AssignmentChecker._checkDowncast (package:nnbd_migration/src/edge_builder.dart:2351:14) (x7)
30 & 7 is not great but not terrible. These also do not break path, logging, or
charcode.
Failing tests show why we cannot correctly cover remaining cases without
a larger CL.
Change-Id: I6e510db147f60cc8ee047d45e4ce2d95d26cccc4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119533
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Paul Berry
