-
Notifications
You must be signed in to change notification settings - Fork 29.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
test: add known_issues test for #5350 #10319
Conversation
@AnnaMag btw, to get the list to show up as a checklist you need to remove the white space. :D e.g. |
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.
I think make lint
should catch those nits? I forget.
|
||
const context = vm.createContext(sandbox); | ||
|
||
const result = vm.runInContext("this.hasOwnProperty('prop_base');", context); |
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.
single quotes please!
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.
Is this the proper way to write it?
'this.hasOwnProperty("propBase");'
I thought that double quotes are used in JS to avoid escaping: http://standardjs.com/rules.html
Could you clarify this for me, please? Thanks!
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.
Oh uh... good question. We don't use Standard though (for legacy reasons).
@Trott thoughts? I'd prefer template strings tbh but I think our linter may warn about that currently...
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.
Ok. I asked for future reference.
I used template strings here: https://github.com/nodejs/node/pull/10272/files
and looks like the linter was ok with it
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.
In our lint rules, double quotes are acceptable if being used to avoid escaping single quotes. There are a few examples of it in the code base, but not many.
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.
(Just providing the answer to the question asked. I'm fine with whatever you do in this case as long as the linter accepts it.)
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.
Thanks!
const assert = require('assert'); | ||
|
||
const base = { | ||
prop_base: 1, |
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.
could we drop the trailing comma?
cc/ @fhinkel From https://nodejs.org/api/vm.html#vm_vm_createcontext_sandbox |
b9b9655
to
559dcad
Compare
const assert = require('assert'); | ||
|
||
const base = { | ||
prop_base: 1, |
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.
Can you use camelCase for JavaScript variables please.
}; | ||
|
||
const sandbox = Object.create(base, { | ||
prop_sandbox: {value: 3} |
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.
camelCase here too please.
559dcad
to
f829fb7
Compare
f829fb7
to
9c9c5a7
Compare
@Fishrock123, @cjihrig Done- thanks! |
@@ -0,0 +1,20 @@ | |||
'use strict'; | |||
// Ref: https://github.com/nodejs/node/issues/5350 |
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.
We usually don't include Ref:
when linking to issues. I can only find two tests that do that. (For consistency they probably shouldn't)
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.
The known issue tests do.
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.
I don't think it matters.
The more information possible the better, though.
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.
I meant just get rid of Ref, not the link.
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.
Yea. I meant the known issue tests (I think all of them) include Refs:
at the top.
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.
Never mind. Didn't realize that's the standard for known tests. Sorry for derailing the discussion.
Yes, it seems to be included in all files in that dir. I assumed it was an agreed upon "standard". Of course, np to remove it. |
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.
LGTM
Landed: b73402d |
PR-URL: #10319 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
PR-URL: #10319 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
PR-URL: #10319 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
this passes on v6 and fails on v4. Landed only on v6 |
PR-URL: #10319 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
PR-URL: #10319 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Checklist
make -j4 test
(UNIX), orvcbuild test nosign
(Windows) passesAffected core subsystem(s)
tests
Description of change
A test addressing subproblem of #5350
inherited properties flattened in the vm.runInNewContext
is added to the known_issues directory.
It will be fixed with the 5.5 V8 API changes
#5350 is a consequence of the above as flattening of sandbox
inherited properties happens first inside the vm context
and is subsequently translated onto the outer sandbox.
assert.strictEqual(sandbox.hasOwnProperty('propBase'), false);