I'm looking into enabling NullSafetyUnderstandingFlag in the next
analyzer breaking change.
test_function_void_to_function_object() fails, and it seems that
the test class should use legacy TypeProvider, because `Object` is not
assignable to `void`, but `Object*` is.
Change-Id: Ib867e0eec7a387ed3ed1379a7ef34a58b16e54ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168125
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
The file might be edited in one of a few ways, depending on what it contains.
Previously we read and edited pubspec, which is also YAML, so this
implementation borrows a lot of that, and renames several "pubspec" elements to
be "yaml" elements.
I try to cover in tests various odd existing analysis_options.yaml situations,
so that we try to never crash, or corrupt on weird input here.
Fixes https://github.com/dart-lang/sdk/issues/43806
Change-Id: Ifc57d583e98d798fd7bca748bbe4afef272edab5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/167862
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Rather than produce an error immediately upon encountering an
alredy-migrated library, we simply skip processing it; this causes its
elements to be added to the nullability graph on demand, just like for
already-migrated dependencies.
We still check for the possibility that *every* file in the user's
package has already been migrated, and issue an error if so (rather
than just doing nothing); this should help avoid user confusion if the
user tries to re-migrate an already-migrated package.
Bug: https://github.com/dart-lang/sdk/issues/42308
Change-Id: I8dd81a9c6ff2bb23ede91e89d1152bd7726dec32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/167202
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The packages 'analyzer' and 'nnbd_migration' tightly depend on each
other via MigrationResolutionHooks. I will publish analyzer 0.40.4
shortly after this CL lands.
Change-Id: I6f5e51f88e0020a1674ffb251712658e896170e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/164900
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
I see no reason why this would be useful.
But it might be harmful.
When we create file1 that imports file2, and call getFileSync(file1),
the analyzer will read both file1 and file2 while building the
file graph. So, when we then create file2, it will not be read unless
we call changeFile(file2). And we don't.
Actually, if we want to simulate how migration works, we should first
create all files, and then migrate them.
R=paulberry@google.com
Change-Id: I22ff994d346c4ad985e5d06a34e9fd854d451757
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158960
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
`FutureOr<T?>` is already nullable, because `FutureOr<T?>` ==
`FutureOr<T | Null>` == `Future<T | Null> | T | Null`. So the second
`?` is redundant.
Also fix a bug where we were treating a `Null` type as `Never` if we
couldn't find a reason to require it to be nullable; this was
inconsistent with how the FixBuilder was handling `Null` (which is to
leave it unchanged).
Change-Id: I5e0e4b7fb449988d8ff0dd87a2b4c3da4a6ecebb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155506
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Fixes https://github.com/dart-lang/sdk/issues/29731
This change produces UNUSED_ELEMENT hints for optional parameters
for which no arguments are ever explicitly given, under the following
circumstances:
* parameter is for a constructor, method, or top-level function which
is not accessible outside the library,
* function is never torn-off (all bets are off once its been torn off),
* method does not override a method in which the matching parameter is
required,
* method does not override a method with a matching paramter, in which
an argument is given for the matching parameter.
Change-Id: Idabf051f55140b62a440dc63ca0234f22598a5e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152730
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
There were two problems:
- EdgeBuilder wasn't handling the extension override syntax at all,
causing a crash.
- FixBuilder wasn't overriding the behavior of
ExtensionElement.extendedType, causing a star type to be used as a
context for the target expression; this prevented the fix builder
from realizing when it needed to insert `!` after the target
expression.
Fixes#42455.
Bug: https://github.com/dart-lang/sdk/issues/42455
Change-Id: I5a9f66f83db73a796e72708022faefd527667e32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152941
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Fixes https://github.com/dart-lang/sdk/issues/42375
EdgeBuilder wishes to do its own GLB type-joining, as does FlowAnalysis.
When FlowAnalysis pushes a promotion in ifNullExpression_rightBegin,
and then in write, and then pops those two promotions to join them in
ifNullExpression_end, EdgeBuilder is not given a chance to make its
own GLB node. Instead promotion never happens: the DecoratedType which
is the variable's type is promoted to non-nullable, for the left side.
The DecoratedType for the right side expression is not considered
non-nullable, so the FlowAnalysis.join will always fail to promote.
TypeOperations.adjustPromotedTypes solves this. It is a no-op in all
implementations except in EdgeBuilder.
Additionally FlowAnalysis.write's promotion fails for the same reason:
the only type of interest is the declared type made non-nullable, and
no matter what, the writtenType is not a subtype of this.
TypeOperations.forcePromotion solves this. It is a no-op in all
implementations except EdgeBuilder.
Change-Id: Iba6b9a69583af8fe1aa23124c7d66047acfff495
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152104
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Fixing the test that's causing the Windows bot to fail required updating
the MockSdk, which cause a lot of other changes. I would have done this
in two separate CLs if I'd known how big this was going to get, but I'm
hoping it isn't too big.
Change-Id: Idee56bab5e73a78ab7857e81177090493aa08b40
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151874
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Konstantin Shcheglov