The WebSQL standard was abandoned more than 10 years ago and is not
supported by many browsers.
The `dart:web_sql` library was marked as deprecated in Dart 2.14. This
CL makes the library inaccesible, removes support for `dart:web_sql` imports,
and removes the `Window.openDatabase` API. The old code for `dart:web_sql` is
still generated by the html generators. Removing that will be handled by a
separate change.
Closes https://github.com/dart-lang/sdk/issues/46316
Change-Id: I892107396b3b227b4f33344377585aa5e5328288
Bug: https://github.com/dart-lang/sdk/issues/46316
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216080
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This CL removes async markers where await wasn't used.
In a few cases this also meant the ability to make the procedure not
return a future at all.
Also - at least on the VM with my benchmark run on my PC - returning
new Future.value(whatever) in a non-async procedure is faster than
returning whatever in an async procedure.
TEST=CI and existing tests.
Change-Id: I4ba888313c87de76bb0ca02c19eb1ab45f168a85
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213480
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This reverts commit 659fdae898.
Reason for revert: Broke the HHH bots.
The fix according to zra@ should be:
"The new dependencies should be added as dependency overrides to flutter_frontend_server's pubspec.yaml: https://github.com/flutter/engine/blob/master/flutter_frontend_server/pubspec.yaml"
Original change's description:
> Move most of the code from u/b/kernel_worker.dart to p/frontend_server
>
> This should allow us to import the code in cases when we want to
> implement the Bazel worker loop ourselves. This opens some possibilities
> of extra optimizations for internal use cases.
>
> I'm leaving some of the code (e.g., `main`) in the old location, so that
> we do not break anything that depends on it.
>
> The only thing that I've done is to pass the input-digest map to
> `computeKernel` instead of using `Input` objects directly, this way
> we can avoid the dependency on `package:bazel_worker` from
> `frontend_server`. So now, if we're using the worker loop, the map will
> be computed by `kernel_worker.dart` (in non-worker mode, we rely on
> the default empty map).
>
> Bug: http://b/187910394
> Change-Id: I408407ebdebc17c7898552c053a8e1c269cf2df5
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/201187
> Commit-Queue: Michal Terepeta <michalt@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: http://b/187910394
Change-Id: Ieb44d61b668a7d4629a27eef5a6ef61d0db9deaf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/201880
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Auto-Submit: Jake Macdonald <jakemac@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Commit-Queue: Phil Quitslund <pquitslund@google.com>
This should allow us to import the code in cases when we want to
implement the Bazel worker loop ourselves. This opens some possibilities
of extra optimizations for internal use cases.
I'm leaving some of the code (e.g., `main`) in the old location, so that
we do not break anything that depends on it.
The only thing that I've done is to pass the input-digest map to
`computeKernel` instead of using `Input` objects directly, this way
we can avoid the dependency on `package:bazel_worker` from
`frontend_server`. So now, if we're using the worker loop, the map will
be computed by `kernel_worker.dart` (in non-worker mode, we rely on
the default empty map).
Bug: http://b/187910394
Change-Id: I408407ebdebc17c7898552c053a8e1c269cf2df5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/201187
Commit-Queue: Michal Terepeta <michalt@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Previously there *could be* lots of failures caused by the compiler
auto-detecting nnbdmode (and as a consequence setting a specific nnbd
mode based on the first file compiled).
That means that the ordering of the files - which seems to be different
on the bot and on my local machine for instance - decides the nnbd mode
and as a consequence if there are errors because of it.
This CL splits compiles up into weak and strong and compiles those in
chunks, thus avoiding the errors.
Change-Id: If796458782fdbf4f7da4ebc98f6110f0279a12cd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/201565
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This change adds toString transformation to gen_kernel and
frontend_server tools in Dart SDK.
The implementation and tests are derived from
pkg/frontend_server/lib/src/to_string_transformer.dart and
https://github.com/flutter/engine/tree/master/flutter_frontend_server/test.
In addition to _KeepToString in dart:ui, toString transformation
now supports @pragma('flutter:keep-to-string') to exclude
certain toString methods from the transformation without depending
on dart:ui.
pkg/frontend_server/lib/src/to_string_transformer.dart is not
cleaned up in this change yet as it is still used by Flutter
engine. Cleanup will be done after Flutter engine is cleaned up,
after it is switched to the implementation of toString transformer
added in this change.
This is also a step towards a unified kernel compiler
(https://github.com/dart-lang/sdk/issues/39126).
TEST=pkg/vm/test/transformations/to_string_transformer_test.dart
Issue: https://github.com/dart-lang/sdk/issues/46022
Issue: https://github.com/dart-lang/sdk/issues/39126
Change-Id: Icbfd3fa193d54f1fc6b2d7fa0bace82b3704f91f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/200525
Reviewed-by: Dan Field <dnfield@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
In each library where an import is removed, the library uses some elements
provided by the import, BUT there is another import which provides all of the
same elements, and at least one more which the library uses.
In this change, we remove the imports which can be simply removed in favor of
the other already present imports.
See https://github.com/dart-lang/sdk/issues/44569 for more information.
Change-Id: I3d4fea152048232b44db2f931a5be2c17b5c0f18
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/199463
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Samuel Rawlins <srawlins@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 adds a new messages kind 'info' to the CFE for showing general
information during compilation. A 'configuration' options is added
to `CompilerOptions` for telling the CFE how it is run.
The configuration 'compile' is added for when the CFE is invoked to
produces an "executable" as when running `dart compile`. When
configuration is set, the CFE emits an info message about the
null safety compilation mode.
Support for `dart compile exe` and `dart compile js` is added in this
CL. Support for `dart compile kernel|app-jit|aot` is not included.
In response to https://github.com/dart-lang/sdk/issues/44234
TEST=pkg/dartdev/test/commands/compile_test.dart
Change-Id: I08f51e2a3f5ad4841c4d703bcd266b7afb63c7c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178982
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@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>
Document some of the API stability guarantees that are required for the command line
API of the frontend_server binary. This will allow package:test and the webdev CLI to
begin using the frontend_server
Change-Id: I4bf05757c527e491b1059489b5dda53dfda876a4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174840
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Jonah Williams <jonahwilliams@google.com>
- Define private symbols load without reloading the module
and knowing module format
- Remove libraryName->moduleName map from ExpressionCompiler's
compileExpressionToJs API as a result of above
- Make ddc tolerate null locations on kernel loaded from dill
during assert insertions for nullability
- Disable asserts in expression compilation worker
due to ddc reading source for assert statement compilation
- Remove unused test configuration for expression compiler worker
- Add and update expression compiler tests
Part of: https://github.com/dart-lang/webdev/issues/1174
Change-Id: Idf8f508308915a5487fa0e9810b5674140393fed
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170028
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Even when non-nullable is enabled by default, enabling the experiment
explicitly should result in the experiment release version (and not
the experiment enabled version) to be used for opting in.
For this change, the semantics of parseExperimentalFlags was change
to _not_ normalize the flags to a full mapping including default values.
For this reason all uses of such maps are renamed to
'explicitExperimentalFlags'.
Closes#43879
Change-Id: I0d0262e68ec1403549abcfd305ae3a4404fe93e3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168654
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Front-end server prints all dependencies after compilation, which could
result in a lot of output when AOT compiling a large application.
This change adds --no-print-incremental-dependencies option which
suppresses extra output. This skips printing dependencies which
takes time and avoids I/O which may be blocked.
Issue: https://github.com/dart-lang/sdk/issues/43299
Change-Id: I7779d3b5f1b513c2370978a5384a71cff371f017
b/154155290
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/167860
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Most of the time a hot restart will bail out due to the changed libraries,
but since the operation is pointless anyway it is better to short-circuit.
Change-Id: I86d3266f1502f612b0dd7cc6b7409c05bd7456c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/165381
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Jonah Williams <jonahwilliams@google.com>
- Move expression evaluation to ddc in preparation for google3
- Added server to ddc to handle update and compileExpression requests
- Added tests
- Added 'experimental-output-compiled-kernel' option to ddc to generate
full kernel files only for compiled libraries, and store with
'.full.dill' extension
- Added AssetFileSystem to communicate to the asset server in the
debugger
- Made expression_compiler_worker work with full kernel files,
so removed invalidation of current file to improve performance
- Made expression_compiler_worker reuse already loaded imports
to avoid reading them from source in the incremental compiler
- Updated tests to work with DDC (for simulating webdev)
- Disabled tests that work with bazel kernel worker for now
as it does not generate full dill files yet
- Addressed code review comments from the prototype version:
https://dart-review.googlesource.com/c/sdk/+/157005
Details:
Currently, in flutter tools, expression evaluation is supported via
expression compilation, which is done by the incremental compiler in
the frontend server. The same incremental compiler is used for initial
application compilation, incremental code compilation for hot reload,
and any number of expression compilation requests.
In google3, the apps are typically too large to be compiled as a whole
in memory by the frontend server. Build in google3 is currently done by
blaze, as a distributed build using a task dependency graph. Build tasks
output kernel outline files as an interface between components produced
by individual tasks.
We are proposing an implementation of the expression compilation in
google3 that is taking advantage of full kernel files produced by the
build (supporting build changes to follow). This change introduces a
small server based on dev_compiler, which can handle following requests:
- update: load full kernel for given modules (done on app start)
- compileExpression: compile expression in a given library and module
(done when paused on a breakpoint)
Expression compilation uses previously loaded kernel files for the
application component and its dependencies to compile an expression.
Change-Id: Icf73868069faf3a2eb6d43ba78e459f8457e9e35
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/160944
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Gary Roumanis <grouma@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Anna Gringauze <annagrin@google.com>
Kevin Moore