-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[dart2wasm] Follow-up tasks on source maps #56232
Comments
This will make * `flutter run` have source maps enabled by default * `flutter build` have source maps disabled by default which mirrors what happens already today with the js compilers. For local development this works quite well. We do have some follow-up items for source maps in dart2wasm compiler, see [0] [0] dart-lang/sdk#56232
Ideally I think we'd have the source maps use relative URLs or something similar rather than |
This will make * `flutter run` have source maps enabled by default * `flutter build` have source maps disabled by default which mirrors what happens already today with the js compilers. For local development this works quite well - even better than with dart2js (see dart2js issues in [0]). We do have some follow-up items for source maps in dart2wasm compiler, see [1] [0] [/issues/151641](#151641) [1] [dart-lang/sdk/issues/56232](dart-lang/sdk#56232)
I think this is OK, tear-off allocation code does not correspond to Dart code. If we really want to map tear-off allocation to some code, it should be mapped to the allocation line rather than the torn-off member. E.g.
Here we generate
which shouldn't be mapped to So I think it's best to leave this unmapped. Another follow-up task could be mapping locations in |
I think what we do in dart2js is very applicable here for dart2wasm. I shared also some context in flutter/flutter#151641 (comment). In general, we view source mapping as a 2 step process: producing the actual mapping (a compiler task) and integrating into a service that hosts the sources (a non-compiler task). Sometimes the same output is integrated in multiple ways (compiled output served locally and later served in production). We leverage custom schemes to make the compiler more independent, and delay integration work until it is needed.
We view this step of replacing the custom
Related to flutter/flutter#151641 (comment), the dart2js approach here is to mimic what we do for the SDK: adopt a custom scheme to hide absolute file URLs, and later allow tools to expand it or replace it as needed for integration with a source hosting service. In monorepos, a simple approach we've used is to pick a project root that holds all the code, and use a custom scheme to be the root for all of the code. We may need to revisit and propose a consistent approach for non-monorepos. I don't believe we have a standardized approach yet.
This is something that has made me uncomfortable in the past for two reasons:
Long term, I'd prefer that we don't conflate StackTrace.toString with debuggable stacktraces, but instead provide a new async API for that purpose (like
Agree. In release mode, it is also important to keep sources private and not provide a channel that could expose them inadvertently. |
This will make * `flutter run` have source maps enabled by default * `flutter build` have source maps disabled by default which mirrors what happens already today with the js compilers. For local development this works quite well - even better than with dart2js (see dart2js issues in [0]). We do have some follow-up items for source maps in dart2wasm compiler, see [1] [0] [flutter/issues/151641](flutter#151641) [1] [dart-lang/sdk/issues/56232](dart-lang/sdk#56232)
This will make * `flutter run` have source maps enabled by default * `flutter build` have source maps disabled by default which mirrors what happens already today with the js compilers. For local development this works quite well - even better than with dart2js (see dart2js issues in [0]). We do have some follow-up items for source maps in dart2wasm compiler, see [1] [0] [flutter/issues/151641](flutter#151641) [1] [dart-lang/sdk/issues/56232](dart-lang/sdk#56232)
I agree that it's very beneficial to have a two step mechanism and we should introduce that in dart2wasm as well (and align with dart2js) Though I see a lot of value of having a mode where one can just serve the files with an arbitrary http server and things just work. For example, when I try out flutter web with wasm, I do this:
and navigate a browser to that URL. I want stack maps to work in this case. And currently with dart2wasm's 1 step process it works very nicely (better than dart2js, see flutter/flutter#151641) So we could consider having two modes for the compiler:
@sigmundch Do we currently have a helper package that helps with rewriting of the source maps? Is it baked into e.g. |
…151643) (#153310) Cherry-pick request: #153308 Original CL: This will make * `flutter run` have source maps enabled by default * `flutter build` have source maps disabled by default which mirrors what happens already today with the js compilers. For local development this works quite well - even better than with dart2js (see dart2js issues in [0]). We do have some follow-up items for source maps in dart2wasm compiler, see [1] [0] [/issues/151641](#151641) [1] [dart-lang/sdk/issues/56232](dart-lang/sdk#56232)
Source map support has now landed in dart2wasm (thanks to @osa1 ) in 10742d9 (see flutter/flutter/pull/151643 for the flutter tools PR to take advantage of this).
Though we do have a set of follow-up tasks:
org-dartlang-sdk://dart-sdk/lib/**/*.dart
scheme we emit isn't resolvable by the browser. We have a few options heredart:*
codedart:*
into the source map file - downside: increases size of mapping fileorg-dartlang-sdk://*
scheme to a different uri scheme that flutter's http server can serve in e.g.flutter run
file:///**/*.dart
urls in the mapping fileflutter run
) knows how the app is hosted and served and can therefore choose to serve package sources as under a specific url space=> it just needs to tell dart2wasm that url space we should use for packages
StackTrace.toString()
fetch source maps at runtime & stringify stack. (Possibly only in--enable-assertions
/ profile mode?)We should align the approach with dart2js here (@sigmundch). (See also existing dart2js issues with source maps in flutter flutter/flutter#151641)
@yjbanov @eyebrowsoffire any preferences here what would be best for flutter? (the current dart2wasm approach of baking in absolute file uris works really well for local development but not if app is used on non-developer machines)
/cc @osa1
The text was updated successfully, but these errors were encountered: