Use `hasScheme` in place of comparing against the empty string, and
`isScheme` to compare against all other schemes.
TEST=No behavior changes.
Change-Id: Ifc9fd13c6cf37933ebd4a754c4b500dedbcb291b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/231185
Reviewed-by: Kevin Moore <kevmoo@google.com>
Commit-Queue: Nate Bosch <nbosch@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>
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>
- 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>
During expression compilation, if the compiled expression is using
a type that was not used in the current function, the incremental
compiler and DDC produce code that refers to undefined types.
To fix that, discharge types created during expression compilation
and add their definitions at the beginning of the generated
function.
Added tests to validate the behavior.
Fixes: https://github.com/dart-lang/sdk/issues/41443
Change-Id: If3fdce85a50ab2590d107f3b9e8c19b4768fd482
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148468
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Anna Gringauze <annagrin@google.com>
- Remove collecting private fields from scope calculation
We only need to collect the fields from the evaluated
expression and they are already collected separately.
- Correct private fields calculation
Currently, library names are assumed to be the same as the module,
which creates redefinitions of library variable in produced Javascript
code, and exceptions in chrome for modules that contain more than one
library.
The actual fix will come from making DDC incremental by storing more
information, for now make a best effort to compute correct names for
library variables from the module data that expression compiler
receives from chrome. The following code will be produced to calculate
private symbols _pf1 (from lib1, module1) and _pf2
(from lib2 module1):
let lib1 = require('module1.dart').lib1;
let lib2 = require('module1.dart').lib2;
let _pf1 = dart.privateNames(lib1, '_pf1');
let _pf2 = dart.privateNames(lib2, '_pf2');
Note that this seems to work even if the current breakpoint is inside
the define statement for lib1, and the lib1 symbol is not exported
yet.
Closes: https://github.com/dart-lang/sdk/issues/40272
Closes: https://github.com/dart-lang/sdk/issues/41585
Change-Id: I141719d2d5d5c08dd3c0ef5f0406756dce5575ab
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/145307
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Anna Gringauze <annagrin@google.com>
ExpressionCompiler currently translates offsets of scopes to line
numbers during the binary search in the library in order to find
the inner-most scope containing the line where debugger has stopped.
This results in many offset-to-line translations per evaluation request,
each translation also performing a binary search in Source.lineStarts
table.
To make scope lookup more efficient, this change uses Source.lineStarts
table to find the offset for the debugger stop once, and uses integer
offset comparisons instead in the scope binary search.
Closes: https://github.com/dart-lang/sdk/issues/40281
Change-Id: I72052b144d15acef684a5f8d29b40f6c5774b723
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/142461
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This allows us to start experimenting with the legacy module format in flutter web/internal.
This also updates the DDC module name parsing to throw an ArgumentError on invalid formats, and exposes the parsing method.
Change-Id: I4ce85ecd4078a9827aba046e34425a4f1d1e9abd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/142263
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
ExpressionCompiler crashes while detecting current scope
if there are any scopes in the library with valid fileOffset
and invalid fileEndOffset.
Make ExpressionCompiler more tolerant to incomplete offset
information by just skipping scopes where fileEndScope is not set.
Fixes: https://github.com/dart-lang/sdk/issues/41241
Change-Id: I357017be1cb641053f23144edd5b74f30a9240ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/142080
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Anna Gringauze <annagrin@google.com>
Module names and import module names generated by the frontend server
are currently breaking debugger's assumptions on module names. This
change fixes it to make debugger works with various compiler
configurations, such as build_runner, frontend server with dwds tests,
and unblocks flutter tools to continue debugger and frontend server
integration.
JavaScriptBundle
- Change module import names to module names instead of file paths,
omit leading '/' as it cannot be in a module name in requireJS
- Module name changes are hidden under "debugger-module-names" flag
to prevent breaking flutter tools.
FrontendServer
- Always call exit after listening to commands is finished,
otherwise process running frontend server does not exit on 'quit'
command.
- Call computeCanonicalNames after initial compilation to support
subsequent module importing in compileExpressioToJs calls
- Add error handling to usage of kernelToJs compilers
ExpressionCompiler
- Separate library variables from library fields for loading modules,
as they can be different, for example
```main = require('web/main.dart').web__main```
Closes https://github.com/dart-lang/sdk/issues/40832
Change-Id: Ic103c22932c7181ee325f239193d32361d057ed0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/138010
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Jonah Williams <jonahwilliams@google.com>
Reviewed-by: Gary Roumanis <grouma@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
This is a reland of 344c584ec4
First attempt failed due to lack of implementation of the new
API from SDK in Flutter/engine that this change introduces.
Fixed by creating dummy implementation in flutter/engine:
https://github.com/flutter/engine/pull/16309
Original change's description:
> Implementation of evaluation to JS in frontend server
>
> - made ProgramCompiler somewhat incremental by letting the user
> set the current library and class
> - fixed a bug in procedure_builder where extension method wrappers
> did not have correct fileEndOffset set, which prevented finding
> dart scope at a line when extension methods are used
> - added new compileExpressionToJs API to frontend server and
> frontend compiler interface
> - added ExpressionCompier class that combines IncrementalCompiler
> and ProgramCompiler to compile expression at given dart location
> to JavaScript
> - in JavascriptBundle, set the module name for library tracking in
> JavaScript and saved program compilers to a table for incremental
> reuse in expression compiler
> - Exposed generator from IncrementalCompiler for use in
> ExpressionCompiler
> - added tests for expression compiler
> - added test for compileExpressionToJs API in frontend server tests
>
>
> Change-Id: Ic5e7829e07030b8ad044da7d35bcf27e9fba81c8
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/132701
> Commit-Queue: Anna Gringauze <annagrin@google.com>
> Reviewed-by: Alexander Aprelev <aam@google.com>
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
> Reviewed-by: Gary Roumanis <grouma@google.com>
> Reviewed-by: Jake Macdonald <jakemac@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
Change-Id: I56426d2b6d831b2f8d8c57d468d0b54833a0062e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/134561
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
- made ProgramCompiler somewhat incremental by letting the user set
the current library and class
- fixed a bug in procedure_builder where extension method wrappers
did not have correct fileEndOffset set, which prevented finding
dart scope at a line when extension methods are used
- added new compileExpressionToJs API to frontend server and
frontend compiler interface
- added ExpressionCompier class that combines IncrementalCompiler
and ProgramCompiler to compile expression at given dart location
to JavaScript
- in JavascriptBundle, set the module name for library tracking in
JavaScript and saved program compilers to a table for incremental
reuse in expression compiler
- Exposed generator from IncrementalCompiler for use in
ExpressionCompiler
- added tests for expression compiler
- added test for compileExpressionToJs API in frontend server tests
Change-Id: Ic5e7829e07030b8ad044da7d35bcf27e9fba81c8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/132701
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Gary Roumanis <grouma@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Also updates StrongComponents to prefer the main component as the root if it is in a cycle. This makes bootstrapping more predictable.
This enables a clean integration of build_runner or ddr (internal) and the frontend_server by allowing it to work with any dev server.
All that is needed is a custom .packages file with `http` uris pointing at a dev server which does all code generation, etc.
Bug: https://github.com/dart-lang/webdev/issues/865
Change-Id: I14533d71e5f7ddac58d98073cf016c2589165e9f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/132962
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Auto-Submit: Jake Macdonald <jakemac@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Johnni Winther <johnniwinther@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>
Write JavaScript source map contents as part of the incremental compile. places them in a single file adjacent to the source and offset manifests.
This file contains a map where the module name corresponds to the key and the value is the source map object.
Change-Id: Ice8ac910a5d7119a51d567b8f14cef560cfe8e2e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123360
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Jonah Williams <jonahwilliams@google.com>
If the entrypoint is not a file URI, we'll crash as the strong components implementation is unable to find it. Fallback to the first library in the component
Change-Id: Ibd1650978ebc904463ca2a97bd219a4069524b60
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/122560
Commit-Queue: Jonah Williams <jonahwilliams@google.com>
Reviewed-by: Alexander Aprelev <aam@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>
Nate Bosch