This reverts commit f63f7736c5.
Reason for revert: This somehow breaks the Windows bots. `python tools/test.py -n dartk-win-release-x64 standalone_2/io/process_shell_test`.
Original change's description:
> [cfe] Actually have both ansi and plain text formatted messages
>
> The CFEs FormattedMessage always had two getters to get the text inside
> one that would supposedly give an ansi formated version of the message
> and one that would supposedly give a plaintext formated version of the
> message. They both returned the same string, though, which would either
> be with ansi escape codes or plain text depending on the environment at
> compile time.
>
> This CL fixes that by having both messages, and letting the reporting
> (i.e. whenever the message is read) decide which to use. That way we
> can - for instance - report errors with color if the terminal supports
> it correctly when reusing a dill (and reissuing problems, but where the
> terminal support changes) and if printing the problem to an html <pre>
> field (like observatory does (1)).
>
> It also cleans up two different implementations of whether we think
> the terminal supports colors or not, by deleting one of them.
>
> (1) At least sometimes. It works - I think - only for 'evaluateInFrame',
> but that's another story (and will be fixed in a follow-up CL).
>
> TEST=Existing test suites.
>
> Change-Id: Iedaedd9a5c41458d40c23ed4b706324c004ae943
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/186291
> Commit-Queue: Jens Johansen <jensj@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
Change-Id: I0b53f943a61f76705badfead30d9e1ee35baff57
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/186941
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
The CFEs FormattedMessage always had two getters to get the text inside
one that would supposedly give an ansi formated version of the message
and one that would supposedly give a plaintext formated version of the
message. They both returned the same string, though, which would either
be with ansi escape codes or plain text depending on the environment at
compile time.
This CL fixes that by having both messages, and letting the reporting
(i.e. whenever the message is read) decide which to use. That way we
can - for instance - report errors with color if the terminal supports
it correctly when reusing a dill (and reissuing problems, but where the
terminal support changes) and if printing the problem to an html <pre>
field (like observatory does (1)).
It also cleans up two different implementations of whether we think
the terminal supports colors or not, by deleting one of them.
(1) At least sometimes. It works - I think - only for 'evaluateInFrame',
but that's another story (and will be fixed in a follow-up CL).
TEST=Existing test suites.
Change-Id: Iedaedd9a5c41458d40c23ed4b706324c004ae943
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/186291
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Most lists created when loading a dill file are growable.
That's not always needed, though, and a non-growable list is more compact than
a growable one.
When running dart2js in its "linker scenario" on a large internal app
this saves something along the lines of 90MB of memory.
Change-Id: I113a73ed150efb56a5172ac7e1daf1d28f4bc188
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/185825
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Make Extension.name non-nullable
Make Class.name non-nullable
Make Extension.onType late non-nullable
Make LabeledStatement.body late non-nullable
Make SwitchCase.body late non-nullable
Change-Id: Iccf21fc800faa620c5d4b7bea68f74eec8bf62e2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/185083
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This CL completes the migration of the first wave of
interdependent libraries in package:kernel, including ast.dart.
In order to ensure non-nullability on AST properties, the Transformer
has been split in 2 variants: Transformer which doesn't support
removal of nodes and RemovingTransformer which supports removal where
allowed by the context using 'removal sentinels'.
Start reviewing Transformer and RemovingTransformer in visitors.dart
since many of the changes are caused by the changes here.
Included in the migration are the mixin_deduplication.dart and
unreachable_code_elimination.dart since these needed porting to
the RemovingTransformer which was aided by opting in the libraries
which only depended on ast.dart.
TEST=existing
Change-Id: I9e63b985bd24896c25edd4ee51e37770187bcc17
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/184786
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This changes the CFE expectation test suites to use unsound null safety
as default to avoid passing --enable-experiments=no-non-nullable to opt
out old test folders.
This change removes most test folders from the 'strong' tester, since
this now only supports sound null safety, which requires all libraries
to be opted in. Instead, the 'weak' tester now runs all test folders.
Additionally the 'outline' tester is changed to use unsound null safety
so that it call be used on all test folders.
The 'fast_strong' tester is removed since it should just be run locally
and it can be run by passing an option to the other testers.
References to non-existing 'shaker' folder has been removed from
testing.json.
Change-Id: Ibcc306f7b27d06b9637c205238bc408194f1d062
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/184787
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This CL:
* Makes the standard filesystem more synchronous by default.
This makes reading files for normal compiles faster.
* Adds a more asynchronous version of `exists` and `readAsBytes`.
This potentially allows for reading files faster when in a context
where the files can actually be read in parallel. The client have
to make the choise though.
* Skips `Uri.base.resolveUri` when the uri has a scheme. This makes it
slightly faster in my tests, but does not remove any `.` and `..`.
Having those when having a scheme seems sort of weird though.
If this turns out to be a problem we can add it back.
* Re-orders what the standard filesystem checks in `exists` to assume files
which seems more likely to happen. This - for files - means less checks
and should make checking for existance faster. (This was noticed by Siggi).
Using the same measurement procedure as in
https://dart-review.googlesource.com/c/sdk/+/85442
timing how long fasta spends on *reading* files when compiling dart2js
(when compiling via the VM) I get a good speedup.
Note that the measurements are in microseconds:
Before this CL (run like `out/ReleaseX64/dart pkg/compiler/bin/dart2js.dart 2>&1 | grep "Read file (total)" | tail -n 1` 10 times):
Read file (total): 94678
Read file (total): 94232
Read file (total): 91726
Read file (total): 77472
Read file (total): 95582
Read file (total): 88113
Read file (total): 89245
Read file (total): 91575
Read file (total): 96291
Read file (total): 95730
With this CL (run like `out/ReleaseX64/dart pkg/compiler/bin/dart2js.dart 2>&1 | grep "Read file (total)" | tail -n 1` 10 times):
Read file (total): 68379
Read file (total): 69320
Read file (total): 72930
Read file (total): 69692
Read file (total): 68685
Read file (total): 73548
Read file (total): 64649
Read file (total): 71951
Read file (total): 73486
Read file (total): 70621
Difference at 95.0% confidence
-21138.3 +/- 4193
-23.111% +/- 4.5843%
(Student's t, pooled s = 4462.56)
Furthermore, using an internal benchmark (discussed in an email thread)
I get these numbers (note that the measurements are in milliseconds):
before:
4453
4249
4187
4190
4216
after:
2310
2379
2449
2467
2407
Difference at 95.0% confidence
-1856.6 +/- 131.443
-43.5924% +/- 3.08625%
(Student's t, pooled s = 90.1257)
Using the asynchronous versions of exists and readAsBytes and checking for
existance and reading in parallel on the same internal benchmark it gets to
1137
1185
1067
1089
1189
For completion, comparing to using "raw" `File` (again using the internal benchmark):
sequential standard
2377
2419
2485
2373
2431
sequential io_sync
2279
2182
2237
2312
2324
io_sync faster:
-150.2 +/- 76.3122
-6.21432% +/- 3.15731%
(Student's t, pooled s = 52.3245)
sequential standardasync
4865
4915
4753
5185
4760
sequential io_async
4746
4834
4989
4840
4891
No difference proven at 95.0% confidence
parallel standard
2526
2563
2652
2616
2685
parallel io_sync
2335
2184
2244
2341
2401
io_async faster
Difference at 95.0% confidence
-307.4 +/- 111.037
-11.785% +/- 4.25691%
(Student's t, pooled s = 76.1341)
parallel standardasync
1137
1185
1067
1089
1189
parallel io_async
1105
1088
1145
1048
1113
No difference proven at 95.0% confidence
TEST=Existing tests.
Change-Id: I8ba56ab0768df8672bcdb693782d3f1eec86b683
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/185101
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Gary Roumanis <grouma@google.com>
package:vm "clones" an old incremental compiler when creating a new one
for a new isolate. It does that by calling .computeDelta on the first
available compiler. If that compiler is already compiling, though, things
can go bad.
The risk of that happening was made bigger by awaiting in the standard
filesystem instead of using the sync filesystem operations, but it can
happen either way.
If it has any practial importance (outside of tests) is an open quesiton
but this should nevertheless fix the issue by only letting the
incremental compiler allow one compile at the time (creating an implicit
queue when more is tried).
TEST=Existing test suites + added test.
Change-Id: I694e360aa4bce604db41908730c66ef3b96e6d8b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/184788
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Aprelev <aam@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>
This is in preparation to migrate package:kernel to null safety.
For the visitor interfaces to support non-nullable return types, the
implementations must avoid using `null` as return value in its base case.
TEST=Refactoring
Change-Id: Ie8fa5d41b99850d9e4abb59634c72920c64128d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/183691
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This is in preparation to migrate package:kernel to null safety.
For the visitor interfaces to support non-nullable return types, the
implementations must avoid using `null` as return value in its base case.
TEST=Refactoring
Change-Id: Ie5e4153f8d3779d94957bb13b3d2d2a942040ff2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179760
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This CL:
* Adds a "reordering fuzzing step", i.e. it tries to sort the fields,
procedures etc in both ascending order and descending order
to verify that there are on crashes and no changes in error vs
no error. This has been tested on http://dartbug.com/34803
before the fix landed.
* Introduces an attempt at "visiting the outline" of the "direct from
parser ast".
Change-Id: Ic3f5a776839030bb48a35eeee8575b37c19be453
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/182504
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This CL updates the parser so that it allows annotations of the form:
`@` <constructorDesignation> <argumentPart>
Where <argumentPart> can contain type arguments. Previously this was
prohibited at parse time.
Generic annotations are still prohibited in the current language
version, but the error is now generated by the parser listener
(BodyBuilder in the case of CFE, AstBuilder in the case of analyzer);
this should open the door for future CLs to add support for generic
annotations when the `generic-metadata` experimental flag is supplied.
Bug: https://github.com/dart-lang/sdk/issues/44838
Change-Id: I90604f38bcb378fc798c5737e486fb26589d4d1e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/182668
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Bug: https://github.com/dart-lang/sdk/issues/44797
This check was previously introduced without a language version,
and therefore lead to a breaking change on SDK update. It's now
versioned for releases >= 2.13, allowing users to migrate easier.
It also adds a hint for the error, providing alternatives for
users whose code triggers this check.
Change-Id: I4f61066a917ddb18071508291cde00710802fc5d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/182920
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@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>
This converts `return e` in async methods in opt-in libraries into
return let v = e in v is Future<FTV> ? await v ; v
where FTV is the future value type of the enclosing function.
Closes#44395Closes#44396Closes#44397Closes#44399
TEST=existing tests
Change-Id: I59687039bfe4a97ffdaa55ac0f193ca4fb208f44
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175310
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
For instance one could pass something like
```
--wantErrorOnReload="Error: The getter 'axis' isn't defined for the class 'Constraints'" --noTryToDeleteEmptyFilesUpFront
```
to reproduce https://dart-review.googlesource.com/c/sdk/+/180341
(the --noTryToDeleteEmptyFilesUpFront part might not be neccessary,
but was at one point doing the reproduction / development of this).
Change-Id: I943b715c56f3e1103c6287ed9529aa29c0e74f07
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/180360
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Currently - i.e. without this CL - (almost) every test run by the strong
test suite verifies the platform libraries as well. That's basically a
waste of time.
This CL makes the suite skip it for the platform.
Runtimes changes (on my computer) as follows:
With -DskipVm=true:
With this CL: ~1:55
Without/before this CL: ~8:30
Without -DskipVm=true:
With this CL: ~4:35
Without/before this CL: ~11:30
Change-Id: I6c46b86935bea29911775cbc0544ea7a0b60b779
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/180562
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Dmitry Stefantsov