-
Notifications
You must be signed in to change notification settings - Fork 529
remove uses of deprecated v8::PropertyCallbackInfo::This() #6003
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
base: main
Are you sure you want to change the base?
Changes from all commits
7235c95
8a63008
7b605ec
90620d2
2311aed
69a6dd7
a20439e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -234,11 +234,11 @@ KJ_TEST("can't use builtin as prototype") { | |
| e.expectEval("function JsType() {}\n" | ||
| "JsType.prototype = new NumberBox(123);\n" | ||
| "new JsType().value", | ||
| "throws", kIllegalInvocation); | ||
| "number", "123"); | ||
| e.expectEval("function JsType() {}\n" | ||
| "JsType.prototype = new ExtendedNumberBox(123, 'foo');\n" | ||
| "new JsType().value", | ||
| "throws", kIllegalInvocation); | ||
| "number", "123"); | ||
| e.expectEval("function JsType() {}\n" | ||
| "JsType.prototype = this;\n" | ||
| "new JsType().getContextProperty()", | ||
|
|
@@ -395,7 +395,7 @@ JSG_DECLARE_ISOLATE_TYPE(InterceptIsolate, InterceptContext, InterceptContext::P | |
| KJ_TEST("Named interceptor") { | ||
| Evaluator<InterceptContext, InterceptIsolate> e(v8System); | ||
| e.expectEval("p = new ProxyImpl; p.bar", "number", "123"); | ||
| e.expectEval("p = new ProxyImpl; Reflect.has(p, 'foo')", "boolean", "true"); | ||
| e.expectEval("p = new ProxyImpl; Reflect.has(p, 'foo')", "boolean", "false"); | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This would be my only hesitation here as an observable change. I highly doubt it'll actually break anything so consider it non-blocking but it at least warrants pointing out.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. from what i understand, this should have been the behaviour all along. if anyone relies on this, it's a bit crazy, but yes, it's observable and i'm not sure there's much we can do about it
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, actually this worries me. If someone is checking for the existence of properties in an RPC stub, today they'd get I could imagine someone being broken. Could we solve this by placing an interceptor on the prototype as well, and having that one return true for these queries? (I think we discussed such a thing at the meeting last week.)
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Unfortunately I believe only one interceptor is supported and a second interceptor up the chain will just be ignored. We were talking about having different portions of the interception on different portions of the chain (like the query in on spot and the getter in another), but I don't think that works here. I'll experiment.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we distinguish somehow whether the caller called If we can't distinguish that, maybe it wouldn't be too hard to change V8 so that we can?
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well,
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah if we switch to |
||
| e.expectEval("p = new ProxyImpl; Reflect.has(p, 'bar')", "boolean", "true"); | ||
| e.expectEval("p = new ProxyImpl; Reflect.has(p, 'baz')", "boolean", "false"); | ||
| e.expectEval("p = new ProxyImpl; p.abc", "throws", "TypeError: boom"); | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kentonv there's another observable change here. in theory it shouldn't matter? certainly moving from throw an exception to not is unlikely to break much but just checking
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I'm not too worried about this.
We might also want to add a test that uses
Reflect.get()with an explicit receiver (third argument) to verify that the property still ends up being read from the holder and not the receiver somehow.