This will make it possible to use the script to create a patched sdk
for dart2js and the vm (some followup needed), which will be useful
to migrate their libraries to nnbd.
In the future, we should be able to leverage this new logic to
write tests that ensure our sdk is warning-free (there are > 80 real
warnings today even on the non-nnbd sdk)
In detail, this CL includes:
* loading the libraries data from libraries.json, this removes the need for a
hand-crafted libraries.dart that replicates the data in libraries.json.
* auto-generates a libraries.dart in the patched sdk that can be used to run
dartanalyzer or to compile an sdk with dartdevc-legacy.
* script simplifications in patch_sdk.dart
* removed tracking of modification stamps. This didn't appeared to be
used by the ninja rules. I believe it was used to reduce local
iteration cycles when we were first developing the sdk itself.
* use Uri directly instead of package:path - this simplifies things,
especially since the libraries_specification is Uri-based as well.
* switch to use package:args for parsing options
* added an option to merge part files in a single file. I've noticed that the
analyzer provides some false positive errors in part files, but once merged
they are no longer shown. In particular, we are clearly hitting limitations of
dartanalyzer on the patched sdk. At this time the old patch-script generated
an sdk with 1500 warnings, this new script reduces it to 500 (not sure why),
with merging of part files it goes down to 80.
Change-Id: I6bbaf92ef4554f00c8bf6b38d19bf79d44fb3e94
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/125780
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
The goal of this change is to make it possible to start iterating on nnbd tests
for DDC. This keeps the current philosophy of keeping NNBD and non-NNBD build
configurations separate, except that NNBD builds are allowed to consume library
sources from the non-nnbd sdk.
This change addresses the first set of errors that are encountered when trying
to build a fully NNBD configuration:
* CFE has issues with type promotion, for that reason we remove
`--enable-experiment=non-nullable` in vm build rules, and we use a smaller
training data when creating the dartdevc app-jit snapshot.
* We'd hit compile-time errors with nnbd libraries with inconsistent
patchfiles. To avoid that, the libarries.json points to the non-nnbd SDK
sources for most dart:* libraries.
Change-Id: Ie6226b3bd8a92b4a1632dd84a5db2f04238fd4f8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/125080
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Change Expression.getStaticType to take a StaticTypeContext instead
of a TypeEnvironment.
The StaticTypeContext provides access to the TypeEnvironment and the
current 'this type' as well as determining the nullability state of the
enclosing library.
This change is needed to support nnbd types for getStaticType and also
serves as a step towards supporting caching during static type
computations to avoid repeated computations of the same (complex)
expressions.
Change-Id: Ied974dff7f6f7c3c8f262aa80c8dea5c674662f7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124683
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
We're deprecating kernels Library.isExternal as it wasn't used for
what it was originally intended. It will hopefully go away entirely
soon.
This reverts commit 689447d0fb and fixes
the reason for the revert.
Change-Id: I122b5b777a2bf7316fde48e034fa3c566458a0cc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124133
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
We're deprecating kernels Library.isExternal as it wasn't used for
what it was originally intended. It will hopefully go away entirely
soon.
Change-Id: I3a4537ab566152555095df7461516f110a533896
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123722
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
- Adds a temporary modular test suite to prevent regressions on NNBD tests.
- New modular tests build the standard SDK with the dart:_runtime library from
the NNBD fork.
- Unblocks DDC development while the forked SDK is in a state that does not
build.
Change-Id: If422f5d19237f9d11e26aad503f1be960b331c57
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123541
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Uses a temporary representation for nullable and legacy types that is subject to
change.
Updated subtype test to include expectations when running with strict mode
checks.
Does not yet include support for:
* Required named parameters
* Weak checking modes (currently only strict checking)
* Caching the results of a check for a later lookup
Issue: #38128
Change-Id: I60935c071affdb56c368e9555fce8f86931103e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119537
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This fixes the issue we had with shared/diamond depedencies. This also matches
more closely how DDK is invoked internally and externally.
While the change to use `--dart-sdk-summary` is not necessary, this brings the
API closer to how it is used elsewhere. It should be cleaned up in the future to
reuse the `--input-summary` flag instead.
Change-Id: Iec3695b5541ffaf7f5762a3d77f071a596237da1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119723
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This refactoring achieves the following:
- Collect the integer operation semantics into one place instead of
having it sprinkled all over the constant evaluator with many
"if (targetingJavaScript)" tests.
- Avoid emitting the internal JavaScriptIntConstant node, which is
serialized as normal DoubleConstant nodes, thus achieving parity
between direct consumers and consumers seeing output that has been
serialized.
- Implement the JavaScript semantics for unsigned right shift.
- Fix truncating divide with a result outside int64 range incorrectly
clamping the result for JS targets.
- Fix positive hex constants >= 2^63 through int.fromEnvironment
producing negative values in dart2js.
- Clarify in Kernel documentation how numeric constants are represented
on VM vs JS targets.
Change-Id: If30bb2c2c77c54eff120b611b059c2ec726c99a0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/116525
Reviewed-by: Mayank Patke <fishythefish@google.com>
Splits strong_test into 4 shards. This test took 4+ minutes locally with
the fast_strong_test and analyze_test ticking in at ~1:45. This change
makes local testing of frontend unittests take 2 instead of 4 minutes in
total.
Change-Id: Id6015de86d547b209a699b1e5196b3edad1e6977
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/114501
Reviewed-by: Jens Johansen <jensj@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>
The many different entrypoints to the CFE have repeatedly shown problems
with targets that do not support unevaluated constants being used
without providing an environment.
Making the targets opt-in to supporting unevaluated constants will
give the users of CFE early notice that CFE is used inconsistently
(as opposed to the backends failing when they happen to see an
UnevaluatedConstant node that they don't support).
Change-Id: I98c80df3a551823598e413e2895f5649f22f7c22
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/110561
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This makes it an actual Pub package like most other code inside the SDK
repo. The main goal is to make it easier to write tests for the test
runner itself.
This change:
- Moves all of the code from tools/testing/dart/ over to
pkg/test_runner. Most of it ends up under test_runner/lib/src.
- Move tools/testing/dart/main.dart to
pkg/test_runner/bin/test_runner.dart.
- Move standalone_2/io/test_runner_test.dart to
pkg/test_runner/test/test_runner_test.dart. I don't think it currently
works, but it wasn't being run in its old location either.
- Add test_runner to the analysis-server bot. This ensures the
test_runner package is static error clean.
- Remove standalone_2/io/test_runner_analyze_test.dart which used to
attempt to do the above and is no longer needed.
- Update test.py to look for the test runner at its new location.
- Add test_runner to the repo .packages file and remove the weird
test_dart pseudo-package. (I think this fixes #35279.)
- Remove status file entries for the removed standalone_2 tests.
There are no code changes to the test runner itself aside from fixing
up import paths.
Change-Id: I3d05d50d222b291848fa5a30de2846e803bc81e6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105821
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Jonas Termansen <sortie@google.com>
For this to work properly, we first need the test infrastructure to have support
for the `--output-directory` flag (see base CL)
Change-Id: I75f788d19ad3b4e9523830250c4a1c9de8418cda
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104400
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Kernel mode only
Build with:
> dart bin/dartdevc.dart -k --compile-sdk dart:core --modules amd -o dart_sdk.js
For now, this doesn't support building only parts of the SDK - dart:core brings everything in.
Change-Id: I23cda3064408778dc93c9b3d4be757f1e99bae0e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104811
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Vijay Menon <vsm@google.com>
Mostly this is adding an abstraction so we can produce the jsonl files that will
allow us to track the status of each test individually.
On a separate CL I'll be moving the tests out of the current unit tests into
their own step in the test matrix.
Change-Id: Id4537db1458949370195124164b120b49a7a526c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104384
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The test is failing, for now I plan to just land the test in its failing test and change the status once it starts passing.
Change-Id: I305c32cc7a163e280bdb766f29835264c331c9ac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103680
Reviewed-by: Vijay Menon <vsm@google.com>
Explicit casts make it easier to confidently navigate the code base and
apply refactorings which tighten types. This change exposes a number of
places where types can be tightened, but only the most trivial were
applied. For most places I added the explicit cast that would have
happened anyway and so behavior shouldn't be changing.
- Add the configuration which disallows implicit casts in the analyzer.
- Add explicit casts in almost all instances.
- Where the implicit cast was due to a local variable type on the left,
change it to a `var` so the type is not repeated.
- In a few places add argument types where they were already applied on
the parent type, and the subclass was unnecessarily loosening argument
types to dynamic.
- In a few places where a method was defined with an implicit dynamic
return but had an obvious and consistent return type, annotate the
method instead of casting after calls to that method.
Change-Id: I90e11b1cc08ce69967ea5705b507d5758a8f668f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103381
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Working towards turning on all lints from package:pedantic. This change includes
the lints that needed cleanup and don't change any behavior.
Applied cleanup:
* Don't explicitly initialize variables to null.
* DO use curly braces for all flow control structures.
* Use `.isEmpty` instead of `.length == 0`.
* Use `.isNotEmpty` instead of `.length > 0` or `! .isEmpty`.
* Use `=` to separate a named parameter from its default value.
The remaining lints from package:pedantic will require cleanup that is less
automatic and will be addressed in later changes.
Change-Id: Ie4c3ba685f8a559209dd14ac037203ecd16252c7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103086
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Vijay Menon