Files
sdk/pkg/analysis_server/test
Paul Berry 12265c4e42 Hacky prototype of how to fix the seventh item from #39247
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>
2019-11-12 22:18:01 +00:00
..
2019-07-10 22:49:10 +00:00