Closes https://github.com/dart-lang/sdk/issues/60109
Both getClassMetadata and getClassesInLibrary can be called before
main is called. In order to support this, libraries should be
initialized so that these debugger APIs can inspect them. Similarly,
SDK libraries that are needed before any code can run should be
initialized. In order to support this, they are initialized on the
first initializeAndLinkLibrary call and reinitialized during a
hotRestart (since the libraries are recreated).
Tests are added to evaluate these methods before main is called.
The debugger test helpers are amended to:
- Support breakpoints within the bootstrap script. This is done by
caching the script and querying to see if it has the breakpoint if
the input sources do not.
- Refactor shared test expectation logic.
- Remove an unused method.
Change-Id: I5534d7008436a51243cf51dba01bb8ad06adca69
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/410602
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
The attached bug shows an issue users have been encountering where a constructor seems to be undefined. It turns out this is because DDC is trying to read the constructor from the wrong library.
This is happening because both 'package:dio' and a sister package 'package:dio_web_adapter' both contain a library with the same path: 'src/adapter.dart'. 'BrowserHttpClientAdapter' the class they are trying to reference is defined in 'package:dio/src/adapter.dart'. However, due to a naming collision, their import is referencing 'package:dio_web_adapter/src/adapter.dart'.
This naming collision happens because of the logic in '_jsLibraryAlias'. By truncating the start of the import URI (i.e. 'dio/' and 'dio_web_adapter/') the two libraries map to the same alias. This alias is then used to as the key in the AMD module export object and since both libraries are in the same module, only the second one gets exported.
This code may have been written with the assumption that libraries from different packages would always be in different modules (in which case the shortened paths shouldn't collide) but this is not the case. The fix is to use the full import URI including the package name.
In writing the attached modular test I discovered another issue that only affects es6 imports. The ScopedId resolver was not considering NameSpecifier as a declaration point for variables. This lead to a similar name collision since the import alias's name was also being derived from a truncated import URI. In the test, both 'f1/foo.dart' and 'f2/foo.dart' were being imported 'as foo'. Now one is 'as foo' and the other is 'as foo$'.
The first issue affects both AMD and es6 while the second issue only affects es6. The modular tests run with es6 so the new test fails if either of these fixes is not in place.
The new DDC module system is not affected by either issue since it doesn't use NameSpecifiers and it uses the full import URI as a string to register libraries rather than a shortened alias.
Tested on TGP and with a local Flutter application.
Bug: https://github.com/dart-lang/sdk/issues/56498
Change-Id: I5bdb945cfbe615874b40e2fc4ebba31b661cf3b7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/410260
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Tearoffs are now represented as a closure that resolves an underlying bound context and property on access. `_boundMethod` and RTI getters must also be evaluated late.
Additionally, we now both canonicalize static methods and tag them with their types at class-declaration time (though lazily) - so that late resolved closures have access to their types.
Some tests have been updated to expect simpler errors. DDC traditionally emits slightly different errors that might aid in debugging.
Change-Id: I1f762b8df45e0766d16dbc8688073768c8bfd233
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/401321
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Some CFE lowerings (e.g. pattern lowerings) result in nested scopes containing VariableDeclarations with the same 'name'. The current DDC transform translates these to the exact same name in JS leading to incorrect semantics.
The `TemporaryId` mechanism automatically renames any variables with the same name that would shadow each other. So we re-use that here to ensure the variables all have a unique name if the CFE hasn't already given them one. If the name is already okay (i.e. not shadowing something else), the name in JS will appear unchanged.
Side note: In a future change perhaps we should rename `TemporaryId`. The general mechanism it implements is more useful than its original intended use.
Fixes: #59613
Change-Id: I708c72528d5df19af48dde01163d375a5588baae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/398504
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
These are no longer handled with the new module format,
so skip them when that's enabled. This is the last piece
to get expression evaluation tests working again with the
new format.
Change-Id: I92933363ea4e275f7a3f1c9cd62e24b0f7987f49
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/393162
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
- Exposes a minimum set of APIs that are needed by DWDS
a single class Debugger.
- Renames some APIs and modifies the signature to better
align with what's happening and what DWDS actually uses.
Similarly, modifies the internal APIs to handle the new format.
- Modifies expression evaluation test suite to handle the
new module format correctly.
- Modifies LibraryBundleCompiler to emit the right export name.
- Adds/adapts existing tests for the runtime debugger APIs.
With this, all tests within pkg/dev_compiler/test/expression_compiler
pass with the new module format with the exception of two tests within
expression_compiler_e2e_ddc_null_safe_test, which will be fixed
in a future CL.
Change-Id: I296496441ea421ecb57bed3b2e90b92365fef510
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/391308
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Converts kernel_worker.dart.snapshot and dartdevc.dart.snapshot to
AOT snapshots. Fixes tests and paths in the code accordingly.
TESTS=ci
Change-Id: Ib99b2a3343e23252c3a6b5295b0d20f0f486aede
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/381388
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
The old runtime type system required prototype manipulations to
correctly capture a type that contained an embedded type argument.
This was achieved by assigning the prototype of the array in the
JSArray factories and connecting the prototype chain so JSArray
"extended" the native JavaScript Array.
In the new runtime type system these special case operations are
not needed.
Remove the error state for `JS_CLASS_REF()` for interface types
with type arguments. The class definitions are now defined outside
of closures so they can be referenced just like classes without
type arguments.
Update debugger API to manually identify the library for JSArray and
remove unnecessary accesses of `.length` via JavaScript.
Cleanup skipped test cases for the old runtime type system.
Change-Id: I57ab0c968ec06437dad0e081f6334268e99dbc69
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/385102
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This is a reland of commit e7658520bb
Fixes in the reland + context:
Type parameters emitted in implicit type checks on covariant mixin forwarding stubs may reference type arguments in anonymous classes. We reduce this to their mixin's implementing subclass to avoid generating RTI rules for anonymous classes.
Previous implementations would 'translate' type parameters to that of their mixed in type, but that strategy fails if the implementing subtype shuffles the order of type arguments relative to its mixed in type (demonstrated in the test - though not actually relevant in the Flutter break).
Original change's description:
> [ddc] Overhauling DDC's generic class representation.
>
> Prior to this change, DDC represented generic classes as closures over type parameters (with type arguments provided at runtime), which tightly coupled generic class definitions with their types and concrete instantiation.
>
> This rewrite decouples this representation, letting us 1) bind type information late and 2) separate generic class definitions from their instantiation.
>
> Notable changes:
> - Generic classes are now declared at top level (rather than within in closures).
> - RTIs are now passed to generic class constructors at runtime (except for JS Interop classes). Only the instantiated class's RTI is required (and it's retained up the type hierarchy).
> - Type signature resolvers are now lambdas that accept a type environment RTI at runtime. While signatures are still attached early, their instances' RTIs are now needed at runtime.
> - Generic classes, constructors, and factories are now evaluated in a 'Class' type environment.
> - An `RtiTypeEnvironment` is introduced to represent lookups on an RTI type environment bound to a parameter. These are used when evaluating type signatures and at constructor/factory bodies.
> - Type recipes now emit Class type parameters with names - but continue to emit method type parameters with de Bruijn indices. This is because indices aren't stable across subtypes.
> - Certain debugger functions now require instances (e.g.,`getClassMetadata`).
> - Adds a special flag for non-external JS interop factory constructors to emit 'true' types (versus 'any').
>
> Change-Id: I7cbeaaf666dd4f9bd5e3ef22a1163a659fc0ee48
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365863
> Reviewed-by: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Kallen Tu <kallentu@google.com>
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Reviewed-by: Nate Biggs <natebiggs@google.com>
> Commit-Queue: Mark Zhou <markzipan@google.com>
Change-Id: I9b6f69b7150631f28442675c4230e093e3b821d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/379511
Reviewed-by: Kallen Tu <kallentu@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This reverts commit e7658520bb.
Reason for revert: Causing failures in both Dart->Flutter roller and web_dev package.
Original change's description:
> [ddc] Overhauling DDC's generic class representation.
>
> Prior to this change, DDC represented generic classes as closures over type parameters (with type arguments provided at runtime), which tightly coupled generic class definitions with their types and concrete instantiation.
>
> This rewrite decouples this representation, letting us 1) bind type information late and 2) separate generic class definitions from their instantiation.
>
> Notable changes:
> - Generic classes are now declared at top level (rather than within in closures).
> - RTIs are now passed to generic class constructors at runtime (except for JS Interop classes). Only the instantiated class's RTI is required (and it's retained up the type hierarchy).
> - Type signature resolvers are now lambdas that accept a type environment RTI at runtime. While signatures are still attached early, their instances' RTIs are now needed at runtime.
> - Generic classes, constructors, and factories are now evaluated in a 'Class' type environment.
> - An `RtiTypeEnvironment` is introduced to represent lookups on an RTI type environment bound to a parameter. These are used when evaluating type signatures and at constructor/factory bodies.
> - Type recipes now emit Class type parameters with names - but continue to emit method type parameters with de Bruijn indices. This is because indices aren't stable across subtypes.
> - Certain debugger functions now require instances (e.g.,`getClassMetadata`).
> - Adds a special flag for non-external JS interop factory constructors to emit 'true' types (versus 'any').
>
> Change-Id: I7cbeaaf666dd4f9bd5e3ef22a1163a659fc0ee48
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365863
> Reviewed-by: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Kallen Tu <kallentu@google.com>
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Reviewed-by: Nate Biggs <natebiggs@google.com>
> Commit-Queue: Mark Zhou <markzipan@google.com>
Change-Id: I8ea12847bb2a4d096db0799c85f3175f1c5df3be
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/379420
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Auto-Submit: Nate Biggs <natebiggs@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
DDC hot reload requires a new module format, which is
currently represented by the intersection of the DDC
module format and canary. Some of the expression compiler
tests only test the AMD module format (all of them run both
canary and non-canary since those are two different try
bots). Add code to test the DDC module format as well.
Change-Id: Ie3ca0dd3d63985d3222ab09730a82935481076a4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/377764
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Prior to this change, DDC represented generic classes as closures over type parameters (with type arguments provided at runtime), which tightly coupled generic class definitions with their types and concrete instantiation.
This rewrite decouples this representation, letting us 1) bind type information late and 2) separate generic class definitions from their instantiation.
Notable changes:
- Generic classes are now declared at top level (rather than within in closures).
- RTIs are now passed to generic class constructors at runtime (except for JS Interop classes). Only the instantiated class's RTI is required (and it's retained up the type hierarchy).
- Type signature resolvers are now lambdas that accept a type environment RTI at runtime. While signatures are still attached early, their instances' RTIs are now needed at runtime.
- Generic classes, constructors, and factories are now evaluated in a 'Class' type environment.
- An `RtiTypeEnvironment` is introduced to represent lookups on an RTI type environment bound to a parameter. These are used when evaluating type signatures and at constructor/factory bodies.
- Type recipes now emit Class type parameters with names - but continue to emit method type parameters with de Bruijn indices. This is because indices aren't stable across subtypes.
- Certain debugger functions now require instances (e.g.,`getClassMetadata`).
- Adds a special flag for non-external JS interop factory constructors to emit 'true' types (versus 'any').
Change-Id: I7cbeaaf666dd4f9bd5e3ef22a1163a659fc0ee48
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365863
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Kallen Tu <kallentu@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
This includes a major version change from 127 to 128.
This change reverts some of the workarounds wrt
errors now that Chrome has fixed the original issue.
Change-Id: I639ee62964bf2d70e425071a1d541171f3b4af64
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/378240
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This allows internal Set classes to be referenced by our runtime.
Context: incoming changes to our generic types (required for hot reload) requires that RTIs be passed to generic classes on instantiation. Moving our Set implementation into our private runtime and making their classes public allows us to directly reference them without clobbering names externally.
Change-Id: Ie47b3263ebbf2650d314b5285a2d50f3abd1a664
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373327
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Late local variables are lowered by the CFE into a local:
* backing store variable
* get method
* set method
* isSet local variable (optionally when the type is nullable)
This change updates the name in JavaScript used for the backing store
variable to match the name for the late variable from the original
source. It also updates the scope information passed for expression
evaluation to remove the lowered name and replace it with the original
so evaluations will work as well.
The name change avoids the hiding performed by the debugger on
recognized temporary names so it appears in the list of local variables.
b/343405209
Issue: See https://github.com/dart-lang/sdk/issues/55918
Change-Id: I6b65a62baf6f26f6e9cfee9f14667d021e16645e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369506
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Today, support for expression evaluation in DDC uses a lot of
information. To properly support compiling expressions in arbitrary
frames, we consume source-maps, module metadata, and full kernel
components at various stages of the process. This data is already
plumbed and available for non-sdk modules in our debugging systems
(frontend-server, webdev, g3), however it is not available the Dart
SDK module itself. Because of that, the expression compiler today
rejects all expression evaluation requests when the target is a Dart
SDK library.
Until the fix the availability of this data everywhere, we believe
we can support a limited form of expression evaluation: only
evaluation of libary level expressions. Basically, expressions
where scope data is not necessary and kernel outlines are sufficient to
compile the expression.
Here we introduce logic to recognize the first offset location of a
library, which is a clear indicator that no scope data is needed and
a library level expression evaluation is being requested.
This change is an attempt to help resolve
https://github.com/flutter/devtools/issues/7766. Note: just like
changes were needed here in the worker and test-compiler files, it
is possible that some change may be necessary in dwds and other
parts of the pipeline. Additional validation will be needed after
this lands.
Change-Id: Iff081a24ecb05092407279a0a7ed3d38c13cf41d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/367981
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
The first in a series of changes that deletes all DDC tests running
with unsound null safety. Follow up changes will remove more tests
configurations, and null safety mode plumbing for the DDC infra.
* Delete the unsound version of some suites.
* Renames the sound suites to be more descriptive of the code in the
test instead of the mode it is run in.
Change-Id: If2edfecc811bb78a77a1e93bd6d0b75f22c3e80c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365520
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
In the refactor to speed up this test, we removed most retry logic
(except for the "unreliable tests" that now apply retries in a
predictable manner).
The "noisy" tests have a similar behavior but for different reasons.
These put a lot of timing presure by serving hundreds of very large
files. The default response timeout of 5s trips this sometimes.
We could try to make this more predictable by providing a larger timeout
upfront, but I believe part of the intent with these tests was also to
incorporate retries for reasons like response timeouts. So instead, I've
added a retry, which will use by default a larger timeout on the second
attempt. This will hopefully be sufficient to remove this source of
flakiness.
Change-Id: I8eb5e9dceed5e7af36f6db45147c2d961247f6e2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/360503
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This test was flaky about 3% of the time in linux bots due to a race
condition. Details are shared in
https://github.com/dart-lang/sdk/issues/55299. TLDR, when one test case
completes and it's execution is resumed (program 1), the test driver
sets up a breakpoint for a new test case concurrently and schedules to
run main again (program 2). Depending on when the breakpoint is set, it
could be hit by either program 1 or program 2. If both programs are in
the same state when they hit the breakpoint, then it doesn't matter
which program we use to validate the test expectations (a benign race
condition). However, this is problematic when the state is different,
which can happen when test 1 and test 2 both are using the same
breakpoint in a loop. This is what happened for the `forLoopTestBP` in
this CL.
To workaround this data race between two test cases, I decided to simply
combine them into a single test case. A different alternative is to copy
the test function and use a different breakpoint, but that didn't seem
worthwhile in this case.
Change-Id: I561c2a25d33d56a8543fe061342cab9cceafd4e4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/359721
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Currently our end-2-end tests create a temporary folder and delete
it after the suite has completed. Only one folder is created for the
entire test run, so the deletion only gets scheduled when the entire
suite has completed.
On windows bots, the cleanup very often fails causing up to 40%
flakiness on some tests.
This CL keeps the cleanup logic as is, but will now deem tests as
passing even when we can't do the proper cleanup.
Change-Id: I8e2e2d39d1bbdaf48c138c0a05a9a2540345fc28
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/359760
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
While working on the e2e tests, I noticed this test was taking a
long time. Turns out this was because it fully exercises an http
client retry logic using exponential backoff and up to 4 retries.
To reduce the costs, I changed the test to use controlled
environment instead. This still hits the same code-paths but
provides a faster turnaround by using at most 1 retry, and issuing
retries immediately.
With these changes, the test completes in 3s (instead of 28s).
I noticed that some of the tests to check an "unreliable" server
where non-deterministic (multiple parallel requests that sometimes
fail or succeed). The changes here also make it deterministic. While
this test seems to have some flakes due to other reasons, my hope is
that these changes will reduce the chances of this test being flaky
on the bots.
Change-Id: I8eb2a00c7a489ab4e5a46e2b5cdbee40d1ffb8d5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/356623
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Ideally we would write each source next to each test to make tests more
readable, but clustering all tests to use a common test file really
helps boost the runtime of the end2end tests now that we reuse the same
page between tests that share the same code.
This CL refactos the tests to mostly use one shared test file. Doing so
speeds up tests between 2x-4x depending on the test.
Change-Id: I9afd00c6a42226899969e3f605ac18e0d2b1a906
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/356285
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Since we changed how the test driver sets up breakpoints, we now we
have the ability to reuse a page for multiple tests.
Before, the test harness would follow this sequence:
* on each group of tests, it would call `_initSource`, which sets up
a boostraper and code to execute on the browser. This code was
reused by all tests in the group.
* on each test, it would indirectly call `_loadScript`, which
navigated to brand new page for each test. If there were multiple
tests in a group, this would load the boostraper and code once per
test.
This CL keeps the sequence of operations the same, except, that
`_loadScript` will reuse the existing page if it already loaded the
boostraper and DDC code needed by the next test.
This greatly reduces the total running time of some of the
expresison compiler shards. On my local machine one such test took
24s before both this and the parent CL, but now takes about 5s.
Change-Id: I7774df9e83142b42efc4ad523f589758a2a4660c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/356301
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Instead of pausing the application while loading, this
changes the bootstrap logic to not invoke main immediately.
Later the test harness uses an expression evaluation to
trigger the start of the application when it is ready for
it.
This change will enable the ability to reuse the same page
and script across multiple tests, which will save a lot of
test execution time (see related child CL).
Change-Id: Ifa1050ac777aabb3e21b69953e85c6578b3e0cc0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/356281
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
The data shows a lot of variation by machine. The slowest test samples
bring the p90 above 4s, which explains that we often hit the limit.
I expect that we'll continue seeing flakes, but less often as a result
of this change. That said, some of the e2e test are taking close to 4
minutes, so we may need additional sharding or switch our approach if
that ocurrs more often.
Change-Id: I47c0dbce6f766edf7c2845d26f11ae7c6372a7bc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/355980
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Multiple end-to-end tests are failing in the bots because some steps
during the test execution are timing out. We currently have a
timeout of 5 seconds for these steps, but it's unclear if the
timeout is because of conditions in the bot machines (e.g. they are
slow), one off exceptions, or something else.
To address the flakiness, I expect we will want to increase the timeout,
but before we do it may be valuable to start measuring what is the
current distribution of timing in the bots to figure out the best value
to use.
This CL adds logging for timing data for that purpose. I've added
tracking for some interesting steps in the expresson-compiler test
framework, including the top two steps that usually hit a timeout in
practice (find-script and pause-event-for-line).
Example output on my local machine:
```
init-source: 233ms (avg), 121ms (p50), 696ms (p90), 696ms (max), 7 (total)
find-script: 18ms (avg), 18ms (p50), 21ms (p90), 25ms (max), 52 (total)
load-script: 22ms (avg), 22ms (p50), 27ms (p90), 30ms (max), 52 (total)
set-breakpoint: 0ms (avg), 1ms (p50), 1ms (p90), 2ms (max), 52 (total)
pause-event-for-line: 422ms (avg), 410ms (p50), 440ms (p90), 658ms (max), 52 (total)
check-in-frame: 459ms (avg), 446ms (p50), 480ms (p90), 695ms (max), 51 (total)
```
Change-Id: I04734b9905da8e1b4c9d06451be65a2dee32ba1c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352988
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This CL:
* adds empty dart:_dart2js_only and dart:_ddc_only libraries for use in
conditional imports,
* updates pkg/dart2js_runtime_metrics to use the new libraries rather
than dart:_dart2js_runtime_metrics and dart:js,
* and removes some unnecessary libraries, including VM-specific
implementations in pkg/dart2js_runtime_metrics and the DDC
implementation of dart:_dart2js_runtime_metrics.
Change-Id: I9500aa303fa5ad8aba0e1d413f69957c268f3f11
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350681
Reviewed-by: Sigmund Cherem <sigmund@google.com>
When landing https://dart-review.googlesource.com/c/sdk/+/342400
the ddc-mac builder (but not Linux and Windows) started failing.
I could reproduce on Linux though so I'm not sure why those builders
didn't fail (nor why it wasn't caught by the try bot), either way this
fixes the issues:
* Test update: E.g. a breakpoint at the end of the scope doesn't work
because it will not be inside the (wanted) scope.
* Test update: Evalating "this" now actually works.
* Scope finding update: DDC adds sourcemapping entries for the *end* of
things so e.g. the getter "c" will have offset and offset+1 added as
source mappings. When translating from javascript position to dart
position we might pick that and thus ask for the scope of offset+1,
but nothing will be found because no node has that offset.
Here I add a fall-back saying that if we get no results we ask again
for the nearest lower offset.
Change-Id: I7e4430d9954466494b514cf51d999358483c9f8c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/345501
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Anna Gringauze <annagrin@google.com>
This allows using the new scope finder and facilitates expression
compilation with and in extension types.
For now the script uri is optional (and only passable in the new json
input via package:frontend_server), and only if the script uri is passed
we'll use the new scope finder.
Flutter etc should be updated to pass the new data.
Change-Id: I36eed1ea76a825e63e4c5b9ea60daf18aee39f3d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/342400
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Anna Gringauze <annagrin@google.com>
Stop running expression evaluation and module symbols tests on legacy
code. These still run with unsound null safety, just on migrated code.
Change-Id: Ifb602c058ebcc3fbd8254e8c2f431f8b18146a64
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/337615
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Anna Gringauze <annagrin@google.com>
Srujan Gaddam