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