Before this CL, whenever a dill library builder was asked to compute
the outline it would finalize its exports - even if it was already done.
This is not really a problem (it mostly puts stuff into maps --- doing
it again will just overwrite what's already there with the same thing
again), but when having many dill library builders, and asking them to
compute the outline again and again because we've added a few new ones
(e.g. via kernel worker) it adds up to a lot of wasted time.
This CL adds a boolean to the dill library builders to avoid re-doing
this already done work.
An internal benchmark via kernel worker of lots of outline
calculations in worker mode with reuse and the incremental compiler
(and lots of dill loaded dependencies) goes from ~149 seconds to
~143 seconds.
Change-Id: I19cadbf64ff5e0ff117bad4df86c83832a1f28fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105243
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Calculation of Class::NumTypeArguments() is reimplemented so that it does
no require separate calculation of Class::NumOwnTypeArguments().
Number of own type arguments is no longer stored in Class, and has_pragma
bit is moved into state_bits.
This simplifies overall calculation and does not require to keep both
num_type_arguments and num_own_type_arguments. This also allows us to add
up to 15 more flag bits to Class.
Change-Id: Iac7a751145fea7adb673ab9369eeb8eea5c5794d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105544
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Previously we created artifical edges from a LUB node's components to
the LUB node; now the nullability propagation algorithm understands
how to propagate nullability downstream through LUB and substitution
nodes, so no artificial edges are needed.
Change-Id: Ib2fef14c3dcd58a013ad8e057fd55597a1deb4fc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105402
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
It wasn't detected by the "unused field" hint because there is another
field in the same file with the same name that *is* used
(NullabilityMigration._graph).
Change-Id: I955f30d010ddaa2d218f61daf32978d391182708
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105410
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This gives us more flexibility for how we want to publish and deploy
the tool. We now have the option, for example, of making a command
line app that invokes the tool and does not depend on analysis_server.
Note that some testing infrastructure had to be duplicated. I plan to
consolidate this infrastructure in follow-up CLs.
Change-Id: I046506bc2bb5c3e467e15885f198ee0632351ee9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105463
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The Dart_KernelCompilationResult type is clumsy to use because it has
multiple owning pointers, and TestCase needs to be better about
remembering to release memory in all code paths. But adding this
free() call at least fixes the reported leak.
Fixes#37154.
Change-Id: I075ccfd20c55026f2443c3d0aef3d2d62192ab3b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105406
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Matthew Dempsky <mdempsky@google.com>
This is a temporary way to ensure the bots will fail on these test suites until
the test matrix provides the output directory. At that point, the .json files
will be used to track test failures and the exit code is no longer necessary
TBR=vsm@google.com
Change-Id: Ie96c3835760de02addc89f7ccbcb3ccb04c21940
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105405
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This was unfortunately not detected by the bots:
* First because of #37117 this didn't break the build.
* Second, because of how I am migrating modular_test to use the test matrix,
we are temporarily not seeing failures either.
I had the intention to wait to land my changes until after the test
infrastructure had support to report the status of individual modular tests.
I landed what I thought was safe to land first, but didn't realize that my
first change already was hiding failures. Now I decided to move forward to
land the rest of my changes, so the only thing that remains is to wait for
the test infrastructure changes to land (ETA: very soon, a CL is already
approved).
TBR=vsm@google.com
Change-Id: Ia06f4ce9bc5d9368fc36a88f9c9ce5530e42c983
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105404
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Sigmund Cherem <sigmund@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>
Closes#37153
Isolate.resolvePackageUri was the only API which had an implementation
across DDC and dart2js. The implementation in dart2js has been broken by
default since Dart 2.0.0 without a user implemented hook that is not
used on any public repo on github. Our current supported path for
invoking the compilers on projects disallows the import altogether on
the web and it is only usable with an older version of the
`build_web_compilers` package, or by invoking the compiler manually
outside of the build system. This CL does not break the ability to have
the import when invoking outside of the build system.
- Drop implementation for `Isolate.resolvePackageUri` from the dart2js
and DDC patch files.
- Drop all references to `defaultPackagesBase` since it is not used.
- Drop all tests under `isolate/browser` since we do not expect any
support on the web. Most of these tests would have already been
failing. Remove status file entries that refer to the deleted tests.
Change-Id: I4a19213b0946d835c00e9c107a714f3bc5672f86
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105080
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
CompressionOptions's clientMaxWindowBits and serverMaxWindowBits are null
by default, indicating that no particular window size is negotiated in
the protocol, instead implying that the connection can handle a default
window size of 15 (32,768 bytes) (RFC 7692 7.1.2.1 and 7.1.2.2).
This change clarifies the documentation for the clientMaxWindowBits and
serverMaxWindowBits fields by stating they can be null to request the
protocol's default window size.
The current implementation's behavior is reasonable. It could be changed
to explicitly say 15 instead of null, but it's more efficient to omit the
request for 15 bits from the protocol since it's default, and it's fine to
allow callers to explicitly request 15 bits since the code already allows
this behavior. This change simply codifies the existing behavior in the
documentation.
The co19 test LibTest/io/CompressionOptions/DEFAULT_A01_t01 was written
based off the misleading documentation. An issue to test the intended
behavior was filed at <https://github.com/dart-lang/co19/issues/364>.
Closes https://github.com/dart-lang/sdk/issues/29436
Change-Id: If7645e7d5abd59715fd1eb0bfe8cbb877d776402
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103813
Commit-Queue: Jonas Termansen <sortie@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Jens Johansen