Array and Object have different values in REPL and in files #7788
Comments
addaleax
added
confirmed-bug
|
#5703 may be the cause of this. |
|
Yep, confirmed by bisecting. |
|
I opened #7793 as a known issue test. Once this is resolved, the test can be moved to the normal test suite. |
15157c3 changed the CLI REPL to default to useGlobal: false by default. This caused the regression seen in nodejs#7788. This commit adds a known issue test while a proper resolution is determined. Refs: nodejs#5703 Refs: nodejs#7788 PR-URL: nodejs#7793 Reviewed-By: Rich Trott <[email protected]>
|
Yes, it should be reopened if the revert PR lands. |
|
@lance as a side note, I believe the problem is that |
|
@cjihrig @addaleax - I think the problem is instead with some of the code here: https://github.com/nodejs/node/blob/master/lib/repl.js#L602-L618. In fact, @cjihrig, your known issue test will continue to fail even if we revert #5703 won't it? Because reverting that PR only causes the default to change and that's all. The known issue test is explicitly setting I think that perhaps this issue is related to https://github.com/nodejs/node/pull/7369/files#r68335215. |
|
The known issue test shows the relationship between |
|
/me should have read the revert PR first :) Still, I think it would be better to figure out what the real problem is and fix that rather than revert which just masks the problem. The issue doesn't go a way with a programmatic REPL started with |
|
#7788 (comment) – |
|
I agree that we should try to get to the bottom of it, but if it isn't a straightforward fix, we should revert until we have a fix. |
|
See also e.g. #7351 |
|
And maybe this is related somehow? #855 I don't really understand V8 Global proxy yet, so still trying to wrap my head around this. |
calebsander
changed the title
This is a partial revert of 15157c3. This change lead to a regression that broke require() in the CLI REPL, as imported files were evaluated in a different context. Refs: #5703 Fixes: #7788 PR-URL: #7795 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Minwoo Jung <[email protected]>
Change `vm.runInThisContext()` to use the last entered context, not the
top-level context that `vm.runInThisContext()` belongs to.
Note the call chain:
1. `node::ContextifyScript::RunInThisContext()`
2. `node::ContextifyScript::EvalMachine()`
3. `v8::Script::BindToCurrentContext()`
The current context in `RunInThisContext()` is that of the top-level
context which was then bound to the script to execute.
It works when `vm.runInThisContext()` is called from the top-level
context (the common case and hence why this bug went unnoticed for
so long) but not when called from an inferior context.
As a pleasant side effect, this commit fixes a bug in the REPL where
writes to `process.stdout` and `process.stderr` still went to the real
stdout and stderr instead of being captured redirected.
Fixes previously failing test `known_issues/test-repl-require-context`
which has been moved to `test/parallel` and renamed to avoid a conflict
with an existing test of the same name.
Note that this commit changes the behavior of the following snippet:
const s = '(function() { return vm.runInThisContext(this) })()';
const f = vm.runInNewContext(s, vm);
f();
Before this commit, it returned the |this| of the new context, now
it returns the |this| of the enclosing context. Two steps forward,
one step back.
Fixes: nodejs#7788
Refs: nodejs#14757
v6.3.04.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016 x86_64 x86_64 x86_64 GNU/LinuxI have one file, say
is.js, that contains the following:In the console,
require('./is.js').isObject({})returnsfalse. However,({}).constructor === Objectreturnstrue. Strangely,isNumber(2)works as expected. Whenrequired from another file, everything works as expected.Affected classes:
ObjectArrayDateErrorRegExpUnaffected classes:
NumberStringBooleanMapSetSymbolThe text was updated successfully, but these errors were encountered: