We currently run our leak tests weekly.
This extends it so we also run leak tests with advanced invalidation,
as well as our strong and weak tests with fuzzing enabled.
Change-Id: I2c941f58594791d1981c6b6612db2205b68f5e19
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/192682
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
History:
* Back in (pre June) 2018 worktrees in git just worked.
* https://dart-review.googlesource.com/c/sdk/+/48091 made it not work.
* https://github.com/dart-lang/sdk/issues/33619 was filed.
* https://dart-review.googlesource.com/c/sdk/+/127485 was created to
work around the problem.
I don't know when it happened, but I can't make the above workaround
work (at least not anymore) --- adding a `default_git_folder` to my
`args.gn` has no effect.
This CL builds on it and automatically sets the correct path based on
a call to `git rev-parse --resolve-git-dir .git` which gives the
correct dir for both worktrees and non-worktrees.
This is the 2nd try which should also work on Windows.
The original CL is in patchset #1.
This reverts commit 7e2cc73da8.
Change-Id: I298aef8ac9095ce3ef4f827218675584b68a02c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/191362
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
AOT in PRODUCT mode with --dwarf_stack_traces performs more aggressive
optimizations of snapshot contents (compared to other modes).
This mode is now used in certain internal apps, so it should be
tested more thoroughly.
This change adds new builders which would enable testing of
--dwarf_stack_traces mode.
Change-Id: I866ef5b0dae2f0d5cbf0cfbc1c161259b7b4a523
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/188140
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Since parse_args() returns None in case parsing failed we should
check for this and bail.
Previously we'd still try to run RunGnOnConfiguredConfigurations
on None and crash with an unrelated issue.
This would overshadow the otherwise nice error message.
Change-Id: If9e267c8eedaaacb388fd8f8475ec0e861060ed5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/187900
Auto-Submit: Clement Skau <cskau@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Since the flag is now enabled by default, there should be no mention of it.
There are still some uses in front_end/testcases that are not just removable
(it also uses `no-non-nullable`). There migth be more uses that are not
as easily found as grepping for `--enable-experiment
Removes two VM tests where fixing them meant they were just duplicating
the corresponding non *_2/ tests.
Fixes#44941
TEST= Large number of tests chaged.=(no-)?non-nullable`.
Change-Id: Ief755981ccde9a5482fcdf408c2929c74433a710
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/183688
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Defines a configuration for -O0 and for --no-legacy-javascript and adds
a run for a small test suite with these configurations on existing bots
as a smoke test.
Change-Id: Ib63602e0066d48e154a7527b229831c82b37bf95
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/182440
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
This CL implements the core flow analysis infrastructure for tracking
reasons why an expression was not promoted. It supports the following
reasons:
- Expression was a property access
- Expression has been written to since it was promoted
I expect to add support for other non-promotion reasons in the future,
for example:
- `this` cannot be promoted
- Expression has been write captured
- Expression was a reference to a static field or top level variable
These non-promotion reasons are plumbed through to the CFE and
analyzer for the purpose of making errors easier for the user to
understand. For example, given the following code:
class C {
int? i;
f() {
if (i == null) return;
print(i.isEven);
}
}
The front end now prints:
../../tmp/test.dart:5:13: Error: Property 'isEven' cannot be accessed on 'int?' because it is potentially null.
Try accessing using ?. instead.
print(i.isEven);
^^^^^^
Context: 'i' refers to a property so it could not be promoted.
Much work still needs to be done to round out this feature, for example:
- Currently the analyzer only shows the new "why not promoted"
messages when the "--verbose" flag is specified; this means the
feature is unlikely to be noticed by users.
- Currently the analyzer doesn't show a "why not promoted" message
when the non-promotion reason is that the expression is a property
access.
- We need one or more web pages explaining non-promotion reasons in
more detail so that the error messages can contain pointers to them.
- The analyzer and front end currently only show non-promotion reasons
for expressions of the form `x.y` where `x` fails to be promoted to
non-nullable. There are many other scenarios that should be
handled.
Change-Id: I0a12df74d0fc6274dfb3cb555abea81a75884231
Bug: https://github.com/dart-lang/sdk/issues/38773
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/181741
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This CL shards the CFE try bot tests better.
* co19_2 runs was previously made faster, so using 10 shards on that is
way too much.
* sdk_test runs was previously made faster, so using 5 shard on that is
way too much.
* unit_tests was taking ~10 minutes and wasn't sharded. This CL shards
it. Note that this sharding is semi-complicated because a few tests
use git which is not usable on shard-runs. To overcome this a previous
CL renamed the tests that use git and here the sharded runs only run
the tests that doesn't require git. Then the "main bot" runs the tests
that require git.
* unit tests suites was taking ~12 minutes and wasn't sharded. This CL
shards it. Note that this sharding is semi-complicated because a few
of the suites use git which is not usable on shard-runs. Also a single
suite uses many more files that it is reasonable to include in the
fileset for the shards. In both cases these are run on the "main bot"
instead. The suit runnier was already "threaded", but simply launched
all threads (say around 20 or something like that) at the same time.
That's not ideal if having, say, 8 cores to work with (which is what
the bots seem to have) - or 12 (which is what my computer has).
Now only 'cores - 1' "threads" are run at any one time, and most
"sub-suites" are sharded, so that if one finishes early that core
can start another "sub-suite" - hopefully utilizing more of the
resources avaiable on the computer running it.
In total - in my 'benchmarks' (i.e. try bot runs) - the
front-end-linux-release-x64-try bot previously rook around 35 minutes
to complete, and with these changes it takes around 15 minutes to
complete. The biggest entry in the timeline is now building dart which
takes almost half that time. It does so with fewer shards than before,
but each might be utilized for longer.
Change-Id: Ie034058d8f33aafd21bc49f2bc878484563ba01c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/181383
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This CL is a warm-up to a follow-up change that will make running the
CFE trybot faster.
This CL:
* Rename tests that require git (because when working with filesets
and shards in the test system, the "checkout" is not a git checkout
and git commands thus doesn't work properly.
* Filters the front-end unit test setup on the front-end bot the way
it was probably intended, i.e. run tests in pkg/kernel, pkg/front_end
and pkg/fasta (actually, the last one doesn't exist, but still)
instead of just in folders inside the "suite" 'pkg' that somewhere in
the path has something called 'kernel', 'front_end' or 'fasta'.
* Split unit_test_suites.dart into a "forwarding shell" and a impl.
In a follow-up CL the impl will be converted to nnbd to allow for
using 'required' on named parameters, but if the entry point was
nnbd it would run in sound nnbd mode and nothing would compile
because all imports are not nnbd.
Overall this CL should change very little, mostly just run a few less
tests, i.e. for instance skip tests that live inside a folder called
'fasta' somewhere inside the analyzer directory path.
Change-Id: I3226c7261cff8b68cc287cff07dc1715dfd85159
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/181381
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Our build infrastructure uses simarm to build for the ARM architecture.
Because of that, building the full sdk with dart2js and dartdevc was
too expensive. In the past there wasn't as much need for the web
compilers in ARM, so we defaulted to exclude the web compilers from
the ARM SDK builds.
We are seeing more use and interest in using these tools in ARM, for
example, from users of modern Apple MacBooks and Raspberry Pi.
This change adds again the web compilers to ARM, but uses kernel
snapshots instead. We believe doing so will be more affordable in
our build infrastructure.
Fixes https://github.com/dart-lang/sdk/issues/43776
Change-Id: I81094f2c51941b0af1dedaf238601c91b0b9dbeb
Bug: https://github.com/dart-lang/sdk/issues/43776
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178960
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Auto-Submit: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
The `url` argument is changing from `Object`, accepting either `String`
or `Uri` at runtime, to `Uri` for better static help.
https://github.com/dart-lang/http/pull/507
- Switch to using `Uri` for requests. Where sensible push this type into
the signature of the surrounding method.
- Make some updated method private where they were unnecessarily public
which makes it harder to have confidence when looking for usages.
Rename a method with an unnecessary `get` name.
Change-Id: Ibf075741d6b9d292349b15f1dc84004981729aca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179368
Auto-Submit: Nate Bosch <nbosch@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
This does not include enabling the FFI on Fuchsia. So these tests will
fail without the dependent CL.
This CL adds an `all_positive.dart` test file to be packaged in the
.far file, such that it is easier to run all FFI tests in one go.
We don't run tests on the bots, but we do build this test package on
the bots.
To build the .far files locally:
```
tools/build.py --os=fuchsia -m debug fuchsia_ffi_test_package
tools/build.py --os=fuchsia -m debug -a arm64 fuchsia_ffi_test_package
```
Issue: https://github.com/dart-lang/sdk/issues/44434
Change-Id: Iec418e0c10d77afbf811fb83151664bcc2710b99
Cq-Include-Trybots: luci.dart.try:vm-fuchsia-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175484
Reviewed-by: Liam Appelbe <liama@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>
Cf. language issue #1341: The grammar rule in Dart.g for <metadata> is
wrong, it does not allow `@x` where `x` is the name of a variable
which is not a `<typeIdentifier>` (in particular, a variable can have
a name like `required` even though it's a built-in identifier).
This CL changes `qualifiedName` such that it only includes the cases
with a '.', and then the remaining case is added where `qualifiedName`
is used. We add `identifier` in `metadata` such that it allows
`@required` and such, and we add `typeIdentifier` in
`constructorDesignation`, because that's required to be an import
prefix or a class name, which are both `typeIdentifier`s.
Change-Id: Ia22d9d9842b995c4ebaa8e18e1c2ccbce1c30e62
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174540
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Jens Johansen