Breadth first is theoretically slightly slower due to less locality of
reference, however it has the benefit of ensuring that the user sees
the shortest possible trace when investigating the cause of a change.
Without this change, it's possible to get some really confusing
traces, e.g. a trace suggesting that a type in some
previously-migrated library is nullable due to a cause within the
library currently being migrated.
This CL also adds tracking of why a node was determined to have
non-null intent, which I plan to expose to the user in follow-up CLs.
Change-Id: I43025ca0ab825d178a28555f85ad9eea43eadfe9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/139140
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This establishes the base functionality. A lot of follow-up work is
needed from here:
- Each trace should have an entry at the top of it pointing to the
thing that was made nullable.
- The source code links in traces don't include lengths, so we can't
highlight whole identifiers when the user clicks on a link.
- Description strings are currently generated by running toString() on
the individual nullability nodes and edges, resulting in long-winded
and useless descriptions.
Change-Id: Ibb370bae6bedc7a8c86092462785023002a48ac3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/138481
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The principal cause may be displayed by invoking the "postmortem" tool
using the "trace" subcommand, followed by the id of the node for which
a trace is desired.
Change-Id: I5868b4bc979320bb46698b02c7b43b317205c487
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/137429
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
A compound node represents a logical OR ("this node is nullable if and
only if one or more of its components is nullable"). Therefore, if
*all* of the components of a compound node have non-null intent, we
should consider the compound node itself to have non-null intent.
This fixes a problem that was preventing the migration tool from
respecting a "/*!*/" hint applied to the type parameter of a typedef.
Change-Id: Iec2f9d6968378707ba692be7b97f750cf53a8b85
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/135786
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This serves two purposes:
1. It makes it easier to be confident that we're resetting the
necessary state when re-running graph computation in
`NullabilityGraph.update`.
2. I'm planning some changes to the graph propagation algorithm (in an
upcoming CL). Having the propagation state separate from the rest
of the graph state will make it easier to reason about these
changes.
Change-Id: I5e101bbce6e5ad382dd754bfbb9b72e20df23fd1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133337
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
This CL combines the EdgeOrigin and EdgeOriginWithLocation classes, so
that all EdgeOrigin objects are associated with source locations. And
it separates the EdgeOrigin and PotentialModification roles of the
ExpressionChecks class into two separate classes.
This will enable a follow-up CL that switches the EdgeOrigin class
over to track source locations via AST nodes rather than offsets,
which will in turn allow rich information to be delivered to the
client about how the nullability graph relates to source code.
Change-Id: I736f60f93681fbbfbd5f9ee9a5589f99f819b9aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/117282
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
A nullability node of `null` will be discarded during a substitution.
For instance, attempting to substitute `T=int?null` into `T?1` will
produce `int?1`, rather than `int?2` where `2` is a substitution node.
We will need this functionality in order to compare function types for
equality, which is in turn needed to integrate with flow analysis.
Change-Id: Ife5e3761b083d4584b2aff760dcb104529e7f9d4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/112745
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This allows us to properly handle contraviariant uses of generics,
where the nullability of a generic parameter needs to be propagated in
the reverse of the usual dependency direction.
Change-Id: Id31f906bb7e3fbbf0846144a4715b9a6591aceda
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/111303
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In follow-up CLs this should allow us to simplify the generation of
fixes (since each fix is associated with one or more unsatisfied
edges) and to streamline tests.
Change-Id: I997f704aac41f270756adcdf8d382fb2263273eb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/106180
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This will simplify some situations where nullability migration would
otherwise have to visit the source code in a very careful order. For
example, when analyzing top level fields undergoing type inference, we
can simply create a node for the nullability of each top level field,
and then later use the "union" operation to hook up those nodes to the
nodes resulting from analyzing their initializers. Without the union
operation, we would have to be careful to visit the top level fields
in dependency order.
Change-Id: I3b07e1abccc5b1c9f1c7c9fa7b13fb6af60c07d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105800
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, they were static, which made them easier to access, but
made it difficult to track their edges (because we couldn't safely
mutate them, so we had to store their edges in special fields of
NullabilityGraph). Now that we're passing NullabilityGraph all over
the place anyhow, there's no benefit to making them static anymore.
Change-Id: Ia3e7d32ae479f40f505621e5d6df04060e39b1c7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105723
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Paul Berry