- Make previous behavior non-conditional
(already default and flag uses are removed)
- Use relative paths instead of package uris as module names
under --debugging-module-names flag, false by default.
(used as server paths in the browser, need to match relative
paths in source maps)
- Pass packageConfig to Javascript bundle API
- Add tests
Closes: https://github.com/dart-lang/sdk/issues/49667
Change-Id: I57c2e2629ba5dd756cce9a8ec6ae891fb092e1d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255826
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
It should not be necessary to ever run `pub get` for a package which is
not published. All packages used in the SDK are controlled by a single
package config, so it's not necessary to declare versions or paths for
any packages.
Remove all dependency overrides.
R=devoncarew@google.com
Change-Id: Icb328813b471f35ee4c99995f4e90aac4d8ed438
Tested: Covered by existing static analysis.
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/244767
Commit-Queue: Nate Bosch <nbosch@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Devon Carew <devoncarew@google.com>
I will add new functionality (binary protocol for macro compilation),
and would like to use modern language version.
Change-Id: I2fc0dc57b64b41669e76a81dff76b0eac93808e5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/239621
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This is used by the modular compilers, so it unblocks more "real" blaze integration, and allows the language repo to create examples that you can actually run.
Note that this also actually enables macros when the experiment flag is passed in to this entrypoint.
Change-Id: Ia5ce82621a63363a17d16599fead5124ddf65faf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/236340
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jake Macdonald <jakemac@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>
- 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>
This should enable strong mode tests to be fully NNBD opted in. At the
same time, legacy tests when run with the experiment off should
hopefully be able to still consume these libraries because they don't
actually use any NNBD features.
To do this, I changed the script that generates the SDK repo's package
config to not put in a language version for any package whose pubspec
has no SDK version. According to language versioning, that means the
package should be considered to be at the "current" version of the SDK
running the code.
In NNBD, that's opted in. With the experiment off, that is (presumably)
"opted out" in the sense that NNBD doesn't exist.
In order to *not* opt in some of the other packages that currently
lack SDK constraints, I put those in and pinned them to "^2.7.0" which
was what the package config script used to implicitly fill in for them.
I see a bunch of other changes in the generated package config too. The
update script probably hasn't been run in a while.
Change-Id: I55193d42eac0696a6b0105546551efa45a1f3252
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144305
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Converts `package:` import uris into `/packages/` modules.
Also renames the output modules to append `.lib.js` instead of just `.js`. This allows us to distinguish between modules and applications based on extension.
Updates DDC source map code to be able to convert absolute file uris in sources so that they are relative to the source map.
Bug: https://github.com/dart-lang/webdev/issues/865
Change-Id: I55d70aa3761f10cc8bd7e92f5b567478040660de
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/132300
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Jonah Williams <jonahwilliams@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Adds support to the frontend server for producing javascript when
compiling with a target model of dartdevc. This uses the ProgramCompiler
and associated types from the dev_compiler package to output the kernel
AST into a "bundle" format.
dev_compiler:
* Exposes additional types needed for JavaScript compilation.
* Allows overriding CoreTypes instead of forcing it to be created from
Component. This is require to support compilation of the
partial Components created by the incremental compiler.
* provides extraIndexedLibraries in Target class so the CoreTypes produced by the incremental compiler have indexed them.
frontend_server:
* When the target model is dartdev, JavaScript is output instead of
kernel. For each Component we compile, we first compute the strongly
connected components and produce a List of new Components to interop
with the dev compiler. The file uri is used as module name.
Change-Id: I4cc117b20671ffd48dd43f9786961c016a02d056
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/121400
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Jonah Williams <jonahwilliams@google.com>
Doesn't do anything with the new target, but establishes a public API for dev_compiler (at least within the SDK)
Change-Id: I4c86b890d3993f96cf32ed0f749608a72a173da6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119526
Commit-Queue: Jonah Williams <jonahwilliams@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
To support JavaScript compilation, the frontend_server will require a dependency on the dev_compiler. To avoid conflating this with the vm specific functionality, the frontend server will be split from its current location.
This change will require a small corresponding update in flutter/engine, documented in the patches directory
Change-Id: I47923765546f7f6fa43e36ef38f8f466d3a7b2fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/120321
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
