Nate Bosch
2bbb2f3c1f
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>
Testing of source maps
This folder contains two types of tests for validating sourcemaps: the debugging behavior and the stacktrace behavior.
For both there are 2 suits: One for (legacy) DDC and one for DDC with kernel (DDK).
Running the tests likely requires the compilation of the correct targets. DDK currently also
requires ddc_sdk.dill inside
{sdkroot}/{out,xcodebuild}/ReleaseX64/gen/utils/dartdevc/kernel/ddc_sdk.dill.
Except for that, running them should simply be a matter of executing the *_suite.dart files.
All tests are plain Dart files and goes in "testfiles" (debugging tests) or "stacktrace_testfiles" (stacktrace tests). They are automatically picked up by the testing framework.
Debugging tests (step tests)
See README.md in pkg/sourcemap_testing.
Debugging a test
One can filter which tests are run by running (from the sourcemap folder):
dart sourcemaps_ddc_suite.dart -- sourcemaps_ddc//printing_class_fields
One can additionally get debug output for failing tests (i.e. tests with different outcome than expected), e.g.:
dart sourcemaps_ddc_suite.dart -Ddebug=true -- sourcemaps_ddc//printing_class_fields
The latter is also useful in combination with /*fail*/ when adding new tests to see all the places
where the debugger stopped (both in JS positions and translated to dart positions).
For instance -Ddebug=true -- sourcemaps_ddk//next_through_catch_test with a /*fail*/
currently gives output like the following:
Stop #1
test.main = function() { | main() {
try { | try {
let value = /*STOP*/"world"; | var value = /*STOP*/"world";
dart.throw(dart.str`Hello, ${value}`); | // Comment
} catch (e) { | throw "Hello, $value";
Stop #2
try { | var value = "world";
let value = "world"; | // Comment
/*STOP*/dart.throw(dart.str`Hello, ${value}`); | /*STOP*/throw "Hello, $value";
} catch (e) { | }
let st = dart.stackTrace(e); | // Comment
Stop #3
dart.throw(dart.str`Hello, ${value}`); | }
} catch (e) { | // Comment
let st = /*STOP*/dart.stackTrace(e); | catch (e, /*STOP*/st) {
{ | print(e);
core.print(e); | print(st);
[...]