Skip to content
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: Export constant identifying the compiler #55694

Closed
simolus3 opened this issue May 11, 2024 · 5 comments
Closed

dart2wasm: Export constant identifying the compiler #55694

simolus3 opened this issue May 11, 2024 · 5 comments
Labels
area-tools A meta category for issues that should be addressed by tooling (prefer more concrete areas). type-enhancement A request for a change that isn't a bug

Comments

@simolus3
Copy link
Contributor

simolus3 commented May 11, 2024

I'd like to have a reliable way of knowing whether my Dart code is running as WebAssembly. This is useful to work around some implementation differences (e.g. references vs. copies when viewing typed data).

#54785 suggests a suitable constant could be dart.tool.dart2wasm = true. Which such a constant, I could select suitable code paths depending on whether my code is compiled to JavaScript or WebAssembly.
There are existing workarounds with a combination of conditional library imports or identical(0, 0.0) hacks, but an officially supported constant would be a lot cleaner.

I've opened https://dart-review.googlesource.com/c/sdk/+/365822/1 for this.

@lrhn
Copy link
Member

lrhn commented May 11, 2024

As you link to #54785, this is something that can be useful for more than just Dart2Wasm.
I'd prefer a general solution to something that only works for one compiler.
(Preferably entries that distinguish, at least, whether running natively, in JS or in Wasm, and possibly also whether compiled in development mode or production mode, and whether asserts are enabled.)

That is, I'd want to also define dart.tool.vm, dart.tool.dart2js, dart.tool.dev_compiler (or whatever names they want to be known under).
I believe dart.tool.dart2js already exists. The rest should too.

(But I'm OK with just agreeing that they should all exist, and then landing this as the first step.)

@lrhn lrhn added type-enhancement A request for a change that isn't a bug area-tools A meta category for issues that should be addressed by tooling (prefer more concrete areas). labels May 11, 2024
@JaffaKetchup
Copy link

Need this here as well! Could be very useful for example projects for packages to show an indicator as to whether it's running with WASM, to verify potential performance improvements.

@simolus3
Copy link
Contributor Author

I'd prefer a general solution to something that only works for one compiler.

I'm not claiming this fixes #54785 :) I just need the identification in dart2wasm and I think it would be nice to have it in a format that will eventually be consistent between all tools.

@osa1
Copy link
Member

osa1 commented May 21, 2024

@lrhn is there a problem with adding dart.tool.dart2wasm now, without waiting for #54785?

It looks like dart2js added it ~9 months ago:

environment['dart.tool.dart2js'] = '${true}';

@lrhn
Copy link
Member

lrhn commented May 21, 2024

I have no problem with landing this as-is. (That's what I tried to say in the last line of my previous comment, maybe I should just be more direct. Ship it!)

I don't know whether I'm the one who should get to decide this. So far, nobody else does, so I'll take it!

I hope that this format is what we end up on, and if we don't, we'll have to take it from there. Since Dart2JS already used it, it'll only a bigger migration problem, not a more difficult one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-tools A meta category for issues that should be addressed by tooling (prefer more concrete areas). type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

4 participants