Users of the CFE often need the ClassHierarchy and may CoreTypes after
invoking the CFE. This CL extends the result of `kernelForProgram` and
`kernelForComponent` to a `CompilerResult` that includes these objects.
Change-Id: I08491198fe876b6514e49993ad794388d6662c9c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/112259
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
When we perform constant evaluation in the CFE, the async transform
runs after constant evaluation. Thus, it can no longer use const
bool.fromEnvironment("dart.vm.product") to query whether the VM is
in product mode.
Instead, it can read the product mode define directly from the
environment defines given to the CFE and generate different code
depending on the value.
Change-Id: I2aabc4a84b50a940d35d5664ff4ebdf0680ed5c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/111645
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Note: Changes in this CL will require some google3 changes (mostly in code related to test entrypoints).
We encountered an issue whereby cross-module programs importing files
with the same name (but separate identities/locations) were being
overridden throughout all of DDK's module builders. For example, a
module importing "x.dart" and "y/x.dart" would export {x: x, x: x$} -
the latter renamed module shadowing the first. DDC handles this by
prepending a formatted module-root-relative identifier string, so
"y/x.dart" becomes something like y__x, and the export becomes {x: x,
y__x: y__x}. However, this results in some code bloat, especially as
paths become deeply nested. More importantly, the $-renaming scheme is
not consistent across modules. Were we to export x$ instead of x, how
would the importing library know whether x or x$ referred to "y/x.dart"?
To have the best of both worlds, we're introducing the concept of a
module alias that exists at the boundary of module imports and exports.
We use this module-root-relative alias to differentiate modules with the
same name but use the shorter $-renaming scheme throughout the generated
code. Relevant points:
1) jsLibraryAlias has been introduced alongside jsLibraryName.
jsLibraryName no longer must be unique - that property having been
transferred to the alias. DDK no longer just outputs pathSegments.last,
instead adopting DDC's scheme of "creating" a special alias from the
module root. jsLibraryName's temporary IDs are renamed using the
existing DDK scheme.
2) Libraries are now associated with NameSpecifiers. The name and asName
fields represent jsName and jsAlias, respectively, for exports
(vice-versa for imports).
3) The test frameworks have been taking advantage of DDK's previous
naming scheme (throwing way the module root, keeping just the name). A
common pattern is to expect DDK's output symbol to be "someexport", then
forcing DDC's output (normally "some__path__someexport") to resemble
that with the deprecated "library-root" flag set to the path of the
output JS file. We resolve this by updating the scaffolding code to look
for the module-root-relative (long) name, which requires a bunch of
path-to-identifier subsitution logic. The "absoluteRoot" bool in the
sourcemap test runner is a way to reenable this DDC-specific deprecated
behavior. The test runner now requires this alias in the html generator.
Fixes https://github.com/dart-lang/sdk/issues/37473
Change-Id: Iaaa82f3350d424af195967b55c87cb32b30a3d85
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/108942
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
When compiling the SDK, nullable inference was marking optional and named
parameters as not nullable when they had default values that are not nullable.
This is wrong because the caller could pass null at the call site if they want.
Fixes: #37700
Change-Id: I9d2baae9e4491587b25dcacda4b3df151b9a2754
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/111602
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Visiting an `UnevaluatedConstant` at this point is a signal something
has gone wrong in the constant evaluation. This should help us identify
hidden issues when flipping the constants-update-2018 flag back on.
Change-Id: Idd8db4c60785f00b22c29292db53783582ed8af1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/109104
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This:
(1) Uses dartdevc and kernel_worker directly to build ddk artifacts.
(2) Generates an outline file instead of a full dill file for ddc_sdk.dill.
(3) Fixes source maps in the shipped sdk so that urls from dart_sdk.js.map
have correct relative paths to dart files in the sdk. This won't work with
webdev/build as that copies and serves dart_sdk.js, but it will now be
able to build the sdk directly.
Change-Id: I7b9470fe18cac9b4343c7c520fe6ffd7bd9246b4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104842
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Vijay Menon <vsm@google.com>
Reduce the surface area of this library to only the fields and methods
which are used from somewhere else.
Cleanup:
- Drop `get` from method names that were changing anyway.
- Remove the `emitMetadata` getter since it's nearly as short to read it
from the options field.
Change-Id: I8b28f5bbdde57c045c76b11f35c0b224adac89ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/107462
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Auto-Submit: Nate Bosch <nbosch@google.com>
Also actually compare the SDK summary digest instead of assuming it doesn't change.
Most of this logic is mirroring logic in the bazel_worker.dart file that kernel uses, which eventually we should unify.
Change-Id: If33af0d8de0b0a6a17081dcd852dd036c4b34a82
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/107184
Auto-Submit: Jake Macdonald <jakemac@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
These are now represented as named functions. This will also help the
debug tools give more information.
Tested with three applications and adding the names caused a code size increases
of less than 1%.
|Total App JS size | Increase |
|------------------|----------|
| 24.7 MB | 0.06% |
| 242 MB | 0.14% |
| 327 MB | 0.19% |
Fixes: #37118
Change-Id: I89a259215ceb8b9e559a190dbd521c923d4c55c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105546
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Rename the library prefix used in imports from `JS` to `js_ast`. Create more of
a distinction between:
* `JS` the library. Now named `js_ast`.
* `js` the const instance of a JSBuilder.
* `JS` the helper to inline javascript in the SDK patches
and runtime libraries.
Ignore the lint in the js_ast directory to avoid additional diffs for the
eventual un-forking of the package.
Cleanup a few unused imports.
Issue #37218
Change-Id: I039c1048876d9d9ad424fbec3ad555d300845a3d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/106160
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
New summary2 will unblock fixing long standing inference issues in
Analyzer.
We build it in addition to summary1, and will switch clients to summary2
incrementally. With this CL DDC will build summary2, but will not
consume it yet for analyzing code. This will be done in a separate CL.
This change was also tested in the internal repo, and does not cause
related build failures.
Change-Id: Ic2c635e45b514a2610e938129fa7527fd8d070b4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105261
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This fixes the problem when the flutter bots run multiple tests from the flutter tool e.g.,
flutter test first_widget_test.dart second_widget_test.dart
The first test causes the set of libraries, particularly Flutter's framework library, to be passed
to the transformer. The transformer needs the 'Widget' class located in Flutter's framework
library. The transformer on the first test works. Each subsequent test only the libraries not in
the prior test are passed, without the framework library, the transformer is unable to find the
'Widget' class and the widget transformer fails to run.
This fix allows the use of a nice speedup to hot-reloading Flutter applications when
--track-widget-creation is enabled and it allows us to enable --track-widget-creation by default,
for command line Flutter users.
This fixes issue https://github.com/dart-lang/sdk/issues/36640R=jacobr@google.com,askesc@google.com
Change-Id: I9a9c9dc69995122d0f7a7a3e1dfaebf57abb4afb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105661
Commit-Queue: Terry Lucas <terry@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Jacob Richman <jacobr@google.com>
Ben Konyi