According to the specification:
Otherwise, it is a compile-time error if R
denotes a generative constructor and D is abstract.
Not sure why we have these constructors at al.
Change-Id: I0ec671245c9b482c6455f7f5725b83db63b3c9db
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175361
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
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 removes our temporary scaffolding support for JIT isolate groups
(which was implemented by creating a new isolate group, loading the
application kernel into it and then merging the heap into the original
isolate group - maintaining a different object store)
It makes all isolates within a group share the same object store, same
libraries and JITed code. It will be conservative to start with, only
allow running unoptimized code, etc.
We will gradually remove the restrictions imposed by this CL:
https://dart-review.googlesource.com/c/sdk/+/173970
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Tests using --enable-isolate-groups with JIT sharing.
Change-Id: I2bf69a6fe3c905067c4cec2e81613f731c52e5ee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175302
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Aprelev <aam@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>
If multiple threads want to obtain metadata they might both evaluate and
possibly cache the result of evaluation. Since the kernel loader
initialy adds metadata mappings (the value being kernel offsets) we use
the existing `IG->program_lock()` which the kernel loader already holds.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Tests using --enable-isolate-groups with JIT sharing.
Change-Id: I3b618f196abe9f7b584e4135a72a0017399ff2d5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175301
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This unifies handling of instance call miss handling on
{JIT,AOT}x{ICOneArgMiss,ICTwoArgMiss,SwitchableCallMiss}.
It changes the [PatchCallHandler] to work in 3 independent steps:
* Resolve target function
* Under IG->patchable_call_lock():
* Update type feedback
* Possibly cause call site transition
* Return data to miss handler to finish the call
This is a pre-requisite for sharing JITed code across lightweight
isolates, since in such a scenario any number of threads can go out to
any miss handler. The call site could then be transitioned several times
before they even return (which is currently not handled correctly).
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Tests using --enable-isolate-groups with JIT sharing.
Change-Id: I673a6cdc21040fe7577e1d658c300e560cc04b7a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175142
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Martin Kustermann <kustermann@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>
Daco Harkes