Mark Zhou
dbabe4dea6
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>
26 lines
652 B
Dart
26 lines
652 B
Dart
import 'package:testing/testing.dart';
|
|
|
|
import 'common.dart';
|
|
import 'ddc_common.dart';
|
|
import 'sourcemaps_ddc_suite.dart' as ddc;
|
|
|
|
Future<ChainContext> createContext(
|
|
Chain suite, Map<String, String> environment) async {
|
|
return StackTraceContext();
|
|
}
|
|
|
|
class StackTraceContext extends ChainContextWithCleanupHelper {
|
|
@override
|
|
final List<Step> steps = <Step>[
|
|
const Setup(),
|
|
const SetCwdToSdkRoot(),
|
|
const TestStackTrace(
|
|
ddc.DevCompilerRunner(debugging: false, absoluteRoot: false),
|
|
"ddc",
|
|
["ddc", "ddk"]),
|
|
];
|
|
}
|
|
|
|
void main(List<String> arguments) =>
|
|
runMe(arguments, createContext, "testing.json");
|