The parser produces this diagnostic, so analyzer doesn't need to.
Change-Id: I39e2ade681e5580b6ca5493a334d87d66f51e1ea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170041
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Fixes https://github.com/dart-lang/sdk/issues/43941
TEST=Running four dart scripts in parallel that delete/watch thousands of file reproduces the failure after several minutes. After the fix it no longer reproduces.
Change-Id: I6a0a928838c676f44e747a822611b56f0ffc4841
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169601
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
This reserved space can only be allocated from after an allocation has failed from OutOfMemory, and once some portion of this space is used, refilling it is the first allocation performed after GC.
Also avoid greatly slowing down from ineffective scavenges as the memory limit is reached.
Bug: https://github.com/dart-lang/sdk/issues/43543
Bug: https://github.com/dart-lang/sdk/issues/43642
Bug: b/169880355
Change-Id: Ic7132cb34d7a7d13c67661f057f00dd74306251c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/165862
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Because this is only a warning the user can ignore it and the code will
compile and run without problem. Hence, the previous wording was a bit
strong.
Bug: https://github.com/dart-lang/sdk/issues/43189
Change-Id: Ibe4f048191b28230fede8e7e5d76943c5b56f31b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169962
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
analysis_options.yaml should be used instead.
Change-Id: I02a03667d5de5c9e764e30ff3c77b8df6deaa221
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169941
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Dart2js is changed to use the caching scheme in preparation for dart2js
to use the static types computed by the CFE instead its own custom
static type computation.
Change-Id: I1d45eda2f67ce4b23d669ec49e476ee357b37fc1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/166845
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
+ fix test to expect erasure of `S & int` to `S` also when bound is `dynamic`.
Closes#43591
Change-Id: I44cb4c726648d4065bdf89bb2dbf71b2753c6c84
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169340
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
This reverts commit a2ceec3e25.
Reason for revert: presubmit hooks are run very early (before CL description is edited), which breaks common workflows.
Original change's description:
> Require that all changes to VM have TEST line
>
> All changes touching one of the following directories will after this
> change be required to contain TEST= line.
>
> runtime/vm
> runtime/bin
> runtime/lib
> runtime/include
> runtime/observatory
> runtime/observatory_2
> runtime/platform
> sdk/lib/_internal/vm
> pkg/vm
>
> This line is supposed to describe in free form how change was validated,
> for example by listing existing or newly added tests.
>
> The goal behind this requirement is to remind both reviewer and change
> author that changes to the code base are in general expected to be
> covered by tests, especially when CL is addressing a regression which
> slipped through existing testing.
>
> Having TEST line in the description would allow both author and
> reviewer to take additional time to consider if validation was
> sufficient or additional test coverage is needed.
>
> The inspiration for this line comes from Chromium[1].
>
> [1] https://chromium.googlesource.com/chromiumos/docs/+/master/contributing.md#describe-testing-performed
>
> TEST=changed file in runtime/vm and run git cl presubmit
>
> Change-Id: Ie16cf7c14af18e3a22a17084c0aebb4d1dfd6d23
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169640
> Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
TBR=vegorov@google.com,kustermann@google.com,asiva@google.com
Change-Id: Ib2e198c322447e8d1166d5d05b2f3209d168f1e9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169887
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
The dart2js_2 version still exists.
Prior to null safety, it was legal to assign `null` to a `bool`, so
things like boolean operators and control flow constructs required
null checks on their inputs. `--omit-implicit-checks` removed these null
checks, so we had to specify what the behavior would be in these cases.
(In general, `null` was just treated as a falsey value, since that's
what happens in JS.)
With null safety, it is no longer legal to assign `null` to a
(non-nullable) `bool`, so the backend freely optimizes boolean
expressions under this assumption. It's possible to smuggle `null` in
via a cast to `dynamic` and an implicit downcast to `bool`. The downcast
ordinarily fails at runtime but can be removed with
`--omit-implicit-checks`. We do not want to specify the behavior in this
case. We do not guarantee the behavior under `--omit-implicit-checks` of
code which would have failed with checks enabled.
Maintaining the old behavior would likely require us to be pessimistic
about nullability and miss optimization opportunities.
Fixes: https://github.com/dart-lang/sdk/issues/43471
Change-Id: I7e8e7c66f777ef631ef4054a8dfe211e3e2bef55
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169820
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
This verifies that we no longer emit spurious errors/warnings in opted out
libraries when trying to compile with sound null safety.
Closes#42607
Change-Id: I89063003fb5140d9cd0a3ce937017976e2fdd1c7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169740
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
All changes touching one of the following directories will after this
change be required to contain TEST= line.
runtime/vm
runtime/bin
runtime/lib
runtime/include
runtime/observatory
runtime/observatory_2
runtime/platform
sdk/lib/_internal/vm
pkg/vm
This line is supposed to describe in free form how change was validated,
for example by listing existing or newly added tests.
The goal behind this requirement is to remind both reviewer and change
author that changes to the code base are in general expected to be
covered by tests, especially when CL is addressing a regression which
slipped through existing testing.
Having TEST line in the description would allow both author and
reviewer to take additional time to consider if validation was
sufficient or additional test coverage is needed.
The inspiration for this line comes from Chromium[1].
[1] https://chromium.googlesource.com/chromiumos/docs/+/master/contributing.md#describe-testing-performed
TEST=changed file in runtime/vm and run git cl presubmit
Change-Id: Ie16cf7c14af18e3a22a17084c0aebb4d1dfd6d23
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169640
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
In the beta release, we plan to recommend that people set their
pubspec SDK constraints to `>=2.12.0-0 <2.12.0`, so this change
updates the migration tool to have that behavior.
In the second beta release we'll change switch the upper bound to
`<3.0.0`.
Change-Id: Ib90e893bebaebea968b19e7de663cbbbca570f84
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169143
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Instead, produce `null /*no valid migration*/`. This should lead to
less user confusion (`null!` seems crazy, since obviously a null
literal will fail a `!` check). Note that this will be a static
error, which will give the user a better chance of noticing and fixing
the problem.
Fixes#43972.
Bug: https://github.com/dart-lang/sdk/issues/43972
Change-Id: Ibf83b786dc486b14c001c17ca2ba902dafcb8a18
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169600
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This was causing visual clutter by making informative regions offset
from regular code. Worse yet, there was a "double vision" effect
because the top of the underlying non-offsetted text could sometimes
be seen behind the informative region overlay.
Change-Id: I206c74b3d91f305a21494b767ec27f396a8513b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169700
Reviewed-by: Samuel Rawlins <srawlins@google.com>
First step in implementing non-function type aliases in the analyzer:
Just add the new back-references in types, such that they can refer to
a type alias which was used to obtain the type, if any.
Next step: Preserve the aliasElement and aliasArguments in summaries,
next again: Create `TypeAliasElementImpl` and ensure that the parser
can create them.
Change-Id: I1bfbc2c3893e32c5b1826552361a0238aa2b4058
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169380
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
