-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Regression in allowInterop idempotence in DDC in Dart >=3.3.0 <3.5.0 #56897
Comments
Summary: The issue reports a regression in the idempotence of |
cc @nshahan Thanks for narrowing down the versions! I suspect it's the general RTI changes that accidentally regressed this and it's this CL that fixed it: 25a9fc0. The correct answer is indeed to test this so it doesn't regress again - I can take that on. Apologies for the temporary regression. You're correct that that changelog is specific to
This is an interesting question. There's a general necessity for differentiating between a JS and a Dart value. In some cases, you simply can't tell (Dart |
@srujzs Awesome, thank you for looking into that, and for discussing my use-case! Gotcha, so it sounds like there may not be a stable way to do it with either
Yes, that sounds like it would be useful! That way, I could also conditionally pass through any |
I've filed #56905 to track the request for that API. I have a change that adds test cases for idempotency in review, and after that lands, I'll mark this as closed. |
@srujzs Thank you very much!! |
I noticed that a regression of #38311 was introduced in Dart 3.3.0, and was fixed in Dart 3.5.0.
The broken behavior is the same as described in that previous issue, and also is what's advertised in allowInterop's doc comment:
Using same reduced test case from that issue...
...I get the following results in these arbitrary Dart SDK versions that I tested:
true
(good behavior)false
(bad behavior)Even though the issue was fixed, it wasn't clear to me what exactly fixed the issue, whether it was fixed on purpose, or whether test coverage was added for this case.
And it looks like when the original issue was fixed (in this commit), no tests were added, so I'm worried that this issue might not have test coverage and could regress again 😕.
I noticed a potentially related changelog entry in the 3.5.0 release notes:
However, the linked issue that was resolved and the commit fixing it seemed more related to
.toJS
thanallowInterop
.If it's helpful, I can also provide a little more context on how I'm currently relying on this behavior.
Right now, I have some code utilizing
package:js
interop and passing arbitrary values to JS code.Some of those values are meant for consumption by JS code, and others (including Dart objects, and notably Dart functions) are meant only for consumption by Dart code reading them back from JS at a later point, and are fine to be treated as opaque to JS.
Values that have already been wrapped in
allowInterop
are assumed to be meant for consumption by JS code, and need to be passed through as-is, whereas Dart functions need to be wrapped in another object so they don't throw when passed over to JS. Without this, the assert indart:js_util
'ssetProperty
fails with the message: Dart function requiresallowInterop
to be passed to JavaScript..The utility that conditionally wraps functions lives here, and uses the idempotent behavior of
allowInterop
to test whether a function has already been wrapped inallowInterop
.I anticipate that this dynamic, conditional wrapping of functions may no longer be possible after switching to the latest Dart JS interop, and we'll need to refactor the code that prepares those values. But, for the time being, we rely on that behavior.
If there are any less-hacky ways of testing whether a function can be called from JS, I'm all ears 😄.
The text was updated successfully, but these errors were encountered: