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
dart2js: Type checks can be fooled by native objects #13010
Comments
This comment was originally written by ngeoffray@google.com I don't understand this bug. There are many ways a native object can fool dart2js generated code. What is is with type tests that we need to do something about it? Added NeedsInfo label. |
I don't think there are many ways a native object can fool dart2js after Stephen switched to using interceptors instead of monkey patching. Generally, a generated type test on obj should look like this: var t = $.getInterceptor(obj); Not: obj.is$Foo The latter breaks if obj is a native object that has a is$Foo property. If we always use getInterceptor, the only way to break dart2js output is to create a native object that has a property matching displayPropertyName. Added Triaged label. |
This comment was originally written by ngeoffray@google.com I still don't understand. The native object can as well mimic Dart behavior, e.g. have a get$foo method that has side effects whereas the compiler thought all foo getters don't have any. I could think of tons of other examples. So what is it that makes type tests so special that we don't want native objects to pretend they are Dart objects? And displayPropertyName is as fakable as $isFoo. |
This comment was originally written by ngeoffray@google.com Added NeedsInfo label. |
That's a good point. Especially when we minify code, the chances that method names conflict with properties on native objects is substantial. One could argue that type tests are more important than accidentally calling a native method that looks like a Dart method. This is because the type test is used in checked mode which is the first thing you should try if a native object is causing confusion. |
When we generate a use of a selector (e.g. get$length) that is understood by some native objects and the receiver is not statically proven to be non-native, we use interceptors. 'is T' is another selector that is understood by all native objects for all T, so we should also use an interceptor unless proven unnecessary. (1) it is really hard to debug code when 'is T' is unreliable |
Added Triaged label. |
Added this to the M7 milestone. |
Removed this from the 1.6 milestone. |
Removed Oldschool-Milestone-1.6 label. |
It should not be possible for native objects to be mistaken for Dart objects.
See tests/compiler/dart2js_native/fake_thing_test.dart
Type tests must use getInterceptor when (1) the test relies on a property on an object (e.g. $isThing) (2) the receiver could be a native instance.
The text was updated successfully, but these errors were encountered: