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

[CP] Use node's enclosing library annotation for lowerings #55430

Closed
srujzs opened this issue Apr 10, 2024 · 7 comments
Closed

[CP] Use node's enclosing library annotation for lowerings #55430

srujzs opened this issue Apr 10, 2024 · 7 comments
Assignees
Labels
area-web Use area-web for Dart web related issues, including the DDC and dart2js compilers and JS interop. cherry-pick-approved Label for approved cherrypick request cherry-pick-review Issue that need cherry pick triage to approve

Comments

@srujzs
Copy link
Contributor

srujzs commented Apr 10, 2024

Commit(s) to merge

https://dart-review.googlesource.com/c/sdk/+/361241

Target

beta/stable

Prepared changelist for beta/stable

https://dart-review.googlesource.com/c/sdk/+/362195
https://dart-review.googlesource.com/c/sdk/+/362190

Issue Description

Some JS interop members rely on the enclosing library's @JS annotation value to find the relevant JS member to dispatch to. In dart2wasm, the code to do so used the invocation's enclosing library's @JS annotation for this determination. This isn't an issue for many JS interop members because we replace the interop declaration for those members, but it is an issue for JS interop methods/constructors as we replace the interop invocation instead. This then leads to calling the wrong JS member because we failed to include the correct library annotation value, which may then lead to a crash due to a missing member.

This is only an issue on dart2wasm. This affects the following JS interop members: top-level methods, constructors, and static methods.

What is the fix

Always use the declaration's enclosing library's annotation value and avoid caching the library's annotation value.

Why cherry-pick

JS interop code that may work fine when compiling to JS may now crash when compiling to Wasm, and may lead to a frustrating debugging experience.

This affected two users so far. It affected the original user who filed the issue: #55359. It also affected the I/O demo app that @kevmoo has been working on.

Risk

Low - this only affects the code to determine which JS interop member to use.

Issue link(s)

#55359

Extra Info

No response

@srujzs srujzs added the cherry-pick-review Issue that need cherry pick triage to approve label Apr 10, 2024
@kevmoo
Copy link
Member

kevmoo commented Apr 10, 2024

LGTM! Minimal risk, but clearly fixing an issue with Firebase!

@kevmoo
Copy link
Member

kevmoo commented Apr 10, 2024

Need to make sure this is merged into BETA, although getting it into the current stable is also nice

@itsjustkevin
Copy link
Contributor

Please open a beta CL also, we are currently prioritizing beta cherry-picks as we stabilize before the next quarterly release.

@srujzs
Copy link
Contributor Author

srujzs commented Apr 11, 2024

Done!

@itsjustkevin itsjustkevin added the cherry-pick-approved Label for approved cherrypick request label Apr 11, 2024
@itsjustkevin
Copy link
Contributor

CC: @sigmundch

@devoncarew devoncarew added the area-web Use area-web for Dart web related issues, including the DDC and dart2js compilers and JS interop. label Apr 11, 2024
@sigmundch
Copy link
Member

I support this CP too, for both stable and beta. I expect we'll see more usage on dart2wasm after 3.4, so I'd especially want to include it in 3.4 beta before it goes out as stable.

@srujzs - consider updating the description above to clarify which kind of JS interop member/methods are affected. I believe it's only top-level methods and possibly static class methods and properties?

cc @mkustermann

@srujzs
Copy link
Contributor Author

srujzs commented Apr 15, 2024

consider updating the description above to clarify which kind of JS interop member/methods are affected. I believe it's only top-level methods and possibly static class methods and properties?

Updated. It affects any JS interop member that uses the enclosing library's JS annotation and could contain optional parameters - top-level methods, constructors, and static methods.

copybara-service bot pushed a commit that referenced this issue Apr 16, 2024
Closes #55359

The current library's annotation is used for the interop lowerings
in dart2wasm. For most members, this is okay because we emit the
equivalent JS code for the member when we visit the procedure and
not when we visit the invocation. However, for methods, the invocation
determines the resulting JS call due to the existence of optional
parameters. In that case, if the invocation was not in the same
library as the interop member declaration, it results in using the
wrong library's annotation value.

Adds tests for this case and does some cleanup of existing tests.

Specifically:
- Adds a consistent naming scheme for test libraries that are
namespaced.
- Adds code to delete the non-namespaced declarations so that the
namespaced interop methods don't accidentally call those declarations.
- Removes differentArgsMethod which was already tested in
js_default_test.
- Removes use of js_util in favor of js_interop_unsafe.

Cherry-pick: https://dart-review.googlesource.com/c/sdk/+/361241
Cherry-pick-request: #55430
Bug: #55359
Change-Id: Ibf7125fea6da7722549f3c87aafdf881132b104f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362195
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Kevin Chisholm <kevinjchisholm@google.com>
copybara-service bot pushed a commit that referenced this issue Apr 16, 2024
…ings

Closes #55359

The current library's annotation is used for the interop lowerings
in dart2wasm. For most members, this is okay because we emit the
equivalent JS code for the member when we visit the procedure and
not when we visit the invocation. However, for methods, the invocation
determines the resulting JS call due to the existence of optional
parameters. In that case, if the invocation was not in the same
library as the interop member declaration, it results in using the
wrong library's annotation value.

Adds tests for this case and does some cleanup of existing tests.

Specifically:
- Adds a consistent naming scheme for test libraries that are
namespaced.
- Adds code to delete the non-namespaced declarations so that the
namespaced interop methods don't accidentally call those declarations.
- Removes differentArgsMethod which was already tested in
js_default_test.
- Removes use of js_util in favor of js_interop_unsafe.

Cherry-pick: https://dart-review.googlesource.com/c/sdk/+/361241
Cherry-pick-request: #55430
Change-Id: I37661ed200c6db367e3f29f50b0877834f4c1639
Bug: #55359
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362190
Reviewed-by: Kevin Chisholm <kevinjchisholm@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-web Use area-web for Dart web related issues, including the DDC and dart2js compilers and JS interop. cherry-pick-approved Label for approved cherrypick request cherry-pick-review Issue that need cherry pick triage to approve
Projects
None yet
Development

No branches or pull requests

9 participants