Rather than have each PotentialModification keep track of its own
source, it's less wasteful to keep track of a map from each source to
a list of the potential modifications for that source.
Change-Id: Ib579f5159100195496a850fbf795b073fc927110
Reviewed-on: https://dart-review.googlesource.com/c/93466
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
If a named parameter has no default value, the default behavior is now
to assume that the parameter is meant to be nullable, even if no code
path can be found that passes null.
This was inspired by discussion with Matan and Ferhat--they were
concerned that users would see the migration tool changing parameters
to required that shouldn't actually be required, and react by adding
special sentinel default values. This is not what we want to
encourage users to do; if the parameter is truly meant to be optional,
it is sensible for it to be nullable.
I will soon add logic that allows non-null intent to override this
behavior; this means that if the user asserts that the parameter is
non-null, or uses the parameter in such a way that a null value would
guaranteed to cause an exception, we'll take that as an indication
that they really mean for it to be required.
Change-Id: Iff388d0316b922d2bacae330d94bec65478d8ee0
Reviewed-on: https://dart-review.googlesource.com/c/93366
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
If a method parameter is used in unconditional control flow in a way
that a `null` value would directly lead to an exception (i.e. by
dereferencing it, or by passing it to a method that requires a
non-nullable value), this is treated as implying that the method
parameter is intended to be non-nullable.
Change-Id: I4f55e4c95b3cfaee0a2ba9367b47d51083e0b7b1
Reviewed-on: https://dart-review.googlesource.com/c/93363
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
When the migration tool is run in permissive mode, its visitors try to
catch exceptions and continue running. This means that when the
visitors make temporary state changes before recursive calls, they
have to restore the state inside `finally` blocks.
This should hopefully result in slightly saner behavior when running
the migration tool in permissive mode.
Change-Id: I46e07684526314befad860c4e065ec2c7f6d8b11
Reviewed-on: https://dart-review.googlesource.com/c/93127
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
If a named parameter is annotated as `@required`, then this overrides
the NamedNoDefaultParameterHeuristic; the parameter is considered
required regardless of what happens at call sites. A duplicate
`@required` annotation is not inserted.
Change-Id: Ib1385d0a65dd9001bb7abede9de2a319f65a1f86
Reviewed-on: https://dart-review.googlesource.com/c/92844
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Currently assuming that the language team chooses option 2 for
https://github.com/dart-lang/language/issues/156#issuecomment-460525075.
To handle the case where the user does not specify a default value,
and all call sites supply the named parameter, there are two possible
heuristics:
- assumeNullable: mark the parameter as nullable, since the implicit
default is `null`, even though the implicit default is never used.
- assumeRequired: consider the parameter to be `@required`, ensuring
that the implicit default will never be used.
I've provisionally chosen `assumeRequired` as the default behavior.
Functionality not yet implemented:
- If `@required` is already present in the source code, this should
override the heuristic; also it should not be added again.
- If the parameter is already marked as nullable in the source code,
this should override the heuristic.
- Uses of `@required` should be translated to `required`.
- If `@required` is already present in the source code, and a default
value is supplied, the default value should be removed.
- If the parameter is used in a way that demonstrates it was intended
to be non-nullable (i.e. it appears in a place in unconditional
control flow that would cause an exception to be thrown if it was
null), this should override the heuristic and cause it to be marked
as `@required`.
Change-Id: I9f2ec63787fdb6215e6075ecfcc830ed9942b8b5
Reviewed-on: https://dart-review.googlesource.com/c/92532
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Sometimes there is no difference between 'relevance' and 'relevanceBoost',
for example for enum constants. But for primitive constants, there might
be multiple `double` constants, in different libraries with their own
different relevances. And it would be nice to keep relative relevances
of these libraries in primitive type constants.
R=brianwilkerson@google.com
Change-Id: I3641a4709e09f5c5dd979f5ca8df7b0235c708d2
Reviewed-on: https://dart-review.googlesource.com/c/92623
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
At this point the migration tool is beginning to make assumptions
about decisions the language team hasn't made yet, so I've created a
class to document those assumptions and allow us to test variants.
Change-Id: I4638d7f534cfa2dbd8460277351045c370377ff8
Reviewed-on: https://dart-review.googlesource.com/c/92394
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This allows us to try it out on substantial codebases (e.g. the
analyzer itself) without crashing, even though a lot of the underlying
logic is not yet complete.
Change-Id: I24a45eea1889f7d9afa30c0398f359d32ffb52ad
Reviewed-on: https://dart-review.googlesource.com/c/92404
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Konstantin Shcheglov