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>
The new rules for null-safe number promotion apply to both operators
and ordinary method calls, so I'll be implementing them in terms of
MethodElement.name rather than an operator TokenType. To make this
possible, we need to pass the method element to
TypeSystem.refineBinaryExpressionType.
I'm doing this as a separate CL from the main implementation so that I
can verify that it doesn't introduce backward compatibility issues.
Bug: https://github.com/dart-lang/sdk/issues/42629
Change-Id: I6be9086553ee0ea9994994c903880fe9bb4477fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158480
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The new logic classifies the LHS and RHS of the equality check as
either null, non-nullable, or potentially nullable, and then either
promotes, treats the expression as equivalent to a boolean, or does
nothing, as appropriate.
This means, for example, that a comparison between a non-nullable
value and `null` is now known to evaluate to `true` for reachability
analysis.
Note: as part of this change, it was tempting to trigger promotion
whenever a varialbe is equality compared to an expression of type
`Null`, but this would be unsound (consider `(int? x) => x == (x =
null) ? true : x.isEven`). So we still only promote when the variable
is compared to a literal `null`.
Fixes#41985.
There's a corresponding spec change out for review:
https://github.com/dart-lang/language/pull/1134
Change-Id: Id7f1d4eaa3b0fa57124445bb8352eef32c304feb
Bug: https://github.com/dart-lang/sdk/issues/41985
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155926
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@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>
Previously this class was marked `@visibleForTesting`, but we need
clients to be able to create instances of this class in order to drive
the migration process.
Change-Id: Ibb8a4cda342942dcb15e6fd7625387d246b41f84
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153800
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The current output indirectly advertizes premature out-of-order migration,
which would be bad if it happened widely.
We can keep the flag, but should not advertize it.
Change-Id: I8bde10489cef8e1104e2e5216e03aed61bc95ba0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153612
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Commit-Queue: Michael Thomsen <mit@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>
These height changes caused the overlay containing highlighted regions
to lose alignment with the underlying text, making the preview output
nearly unreadable for files with a lot of informative regions.
Change-Id: Ie6d0e9e58d28bc63dea5ae1e0a6a630f00c814ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152729
Reviewed-by: Samuel Rawlins <srawlins@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>
- Update header text and buttons
- Add Roboto font
- Add Roboto Mono font
- Add Material icons font
- Update color scheme
- Move help button to header
- Change "Report a problem" button to "Send Feedback"
- Update button colors
Change-Id: Ia4d8b71ae8ec7a7c04ab8c238ffb0499becc9620
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151663
Commit-Queue: John Ryan <ryjohn@google.com>
Reviewed-by: 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>
Paul Berry