This is a reland of fd2a6c6815
Original change's description:
> Flow analysis: Track expression variables separately from promotion info.
>
> Previously, we used a single class hierarchy, ExpressionInfo, to store
> all the information that flow analysis needs to know about a variable,
> including:
>
> 1. What is known about the program state if the expression evaluates
> to true/false
>
> 2. Whether the expression is a `null` literal
>
> 3. Whether the expression is a reference to a variable.
>
> However, in order to address
> https://github.com/dart-lang/language/issues/1274 (Infer
> non-nullability from local boolean variables), we'll need #3 to be
> tracked orthogonally from #1, so that when a local boolean is referred
> to later, we can track information of type #1 and #3 simultaneously.
>
> However, it makes sense to keep #1 and #2 in the same data structure,
> because future work is planned to represent them in a more uniform
> way, as part of addressing
> https://github.com/dart-lang/language/issues/1224 (Using `if (foo?.bar
> == somethingNotNull)` should promote `foo`).
>
> Change-Id: I432f6e2e80543bb1d565b49403180c520eef66a5
> Bug: https://github.com/dart-lang/language/issues/1274
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175008
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Commit-Queue: Paul Berry <paulberry@google.com>
Bug: https://github.com/dart-lang/language/issues/1274
Change-Id: I002adbde782887def50dc80ab6673411b321c341
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175362
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This introduces a way to see what paths have been searched for by
the `BazelWorkspace` and adds a polling-based watcher to detect
when files generated by Bazel appear (or have changed). This allows
us to re-analyze things automatically instead of, e.g., restarting
the server.
Change-Id: I60eae29b0e4fcc3a91d8d2275c6898e45548ea03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168649
Commit-Queue: Michal Terepeta <michalt@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Before Null Safety, `_EventStreamSubscription.cancel()` used a trick
to run with synchronous timing even though it was typed to return a
`Future`. During the migration of the SDK to support Null Safety it
kept the synchronous timing in weak mode, but was changed to
asynchronous in sound mode so that the behavior matched the method
signature. In hindsight, changing the timing when opting into Null
Safety is problematic:
* A shared package has no control over what mode it runs in. Libraries
may be opted in and run their tests with sound null safety but the
apps they are used in could still be running in weak mode. This
results in library unit tests that behave differently than the
production app that deploys the code.
* This codepath can be triggered by EventTarget.dispatchEvent() from
dart:html which should have synchronous timings for the event
listeners before returning to the calling code. The asynchronous
timing when running with sound null safety is inconsistent with the
browser API.
This change reverses that migration decision and keeps the synchronous
timing in both modes. To support this in sound mode it returns a
special future value that is internal to the SDK and known to be used
for synchronous timing.
This change also removes the workaround introduced in DDC to avoid
warning/failing when `_EventStreamSubscription.cancel()` returned
null and the extra warnings/errors features were enabled in weak
null safety mode.
Change-Id: I6b08a2ada5b10120bea787ad59d1d58e6e181de5
Fixes: https://github.com/dart-lang/sdk/issues/44157
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175323
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Removes API migration from the description and ensures the disclaimer appears when run in a help context.
Sample output:
```
$ dart bin/dartdev.dart fix
Fix Dart source code.
This tool looks for and fixes analysis issues that have associated automated fixes.
To use the tool, run either 'dart fix --dry-run' for a preview of the proposed changes for a project, or
'dart fix --apply' to apply the changes.
Note: The `fix` command is provisional and subject to change or removal in future releases. Feedback is
welcome!
Usage: dart fix [arguments]
-h, --help Print this usage information.
-n, --dry-run Preview the proposed changes but make no changes.
--apply Apply the proposed changes.
Run "dart help" to see global options.
$ dart bin/dartdev.dart fix -n
Note: The `fix` command is provisional and subject to change or removal in future releases. Feedback is welcome!
Computing fixes in dartdev (dry run)... 15.2s
Nothing to fix!
$ dart bin/dartdev.dart fix --help
Fix Dart source code.
This tool looks for and fixes analysis issues that have associated automated fixes.
To use the tool, run either 'dart fix --dry-run' for a preview of the proposed changes for a project, or
'dart fix --apply' to apply the changes.
Note: The `fix` command is provisional and subject to change or removal in future releases. Feedback is
welcome!
Usage: dart fix [arguments]
-h, --help Print this usage information.
-n, --dry-run Preview the proposed changes but make no changes.
--apply Apply the proposed changes.
Run "dart help" to see global options.
```
Change-Id: I2fc03651d8a1605a9729bb4d62e382f533509d99
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175343
Commit-Queue: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Devon Carew <devoncarew@google.com>
This CL makes use of the now included constant constructor coverage
in the dill file.
It works like this:
* When the CFE evaluates constants, every constant constructor
invocation evaluated saves the reference to the constructor in the
`Source` (from the Components uri to source table) for the callers
Library.
* This data is loaded into the VM in a "raw" format.
* When a request for coverage comes in, the VM - on top of the normal
coverage processing - goes through all scripts to find constant
constructor coverage for the requested script and offset. Note that
all scripts must be checked because library A can have evaluated a
constructor from library B - so even if only coverage for library B
was requested, library A has to be checked.
For all constructors found the start and end position is reported as
covered. Note that this does not mark any initializes and there are
(at least currently) no good way of marking which initializes were
evaluated (because it has to be stable across edits even when the
`advanced invalidation feature` is enabled).
* Note that the reason for the coverage to work on references - as
hinted above - is because we want it to be stable across hot reloads
even if/when advanced invalidation is enabled. This means, that
library A cannot record "positional coverage" for library B because
library B might get (for instance) new comments that will make any old
offsets invalid. By using references we always lookup in the current
world and use the correct offsets.
https://github.com/dart-lang/sdk/issues/38934
TEST=Existing test suite, new tests for the new coverage added.
Change-Id: I29531247a4b91a99d9a459cfdefbb9798e9c948f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175246
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Previously, the special casing was only performed when creating
a new member. In a follow up, the combined member signature type
will be used for override inference also for legacy libraries and
thus need in [combinedMemberSignatureType].
Change-Id: I23036c0282cdcd633ffe2e9c524e9554cb9dc5ee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175249
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Emphasize that the operation is going away,
and mark constructor as deprecated.
TEST= Refactoring+deprecation only, covered by existing tests.
Change-Id: I82aa044cd2cf7bf347b624371399f44bda8f4a07
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/173261
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Previously, we used a single class hierarchy, ExpressionInfo, to store
all the information that flow analysis needs to know about a variable,
including:
1. What is known about the program state if the expression evaluates
to true/false
2. Whether the expression is a `null` literal
3. Whether the expression is a reference to a variable.
However, in order to address
https://github.com/dart-lang/language/issues/1274 (Infer
non-nullability from local boolean variables), we'll need #3 to be
tracked orthogonally from #1, so that when a local boolean is referred
to later, we can track information of type #1 and #3 simultaneously.
However, it makes sense to keep #1 and #2 in the same data structure,
because future work is planned to represent them in a more uniform
way, as part of addressing
https://github.com/dart-lang/language/issues/1224 (Using `if (foo?.bar
== somethingNotNull)` should promote `foo`).
Change-Id: I432f6e2e80543bb1d565b49403180c520eef66a5
Bug: https://github.com/dart-lang/language/issues/1274
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175008
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Devon Carew