Replace it with TypeSystem from lib/dart/element/type_system.dart,
or (internally) with TypeSystemImpl.
We keep the old TypeSystem where its is exposed from API:
- ResolveResult.typeSystem
- AnalysisSession.typeSystem
- AnalysisContext.typeSystem
We will make changes to these as a breaking change later.
Change-Id: I40ca53ea77e440457c6d0f3832ec3b6286bacdf0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/125770
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
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>
Konstantin Shcheglov