vm: properly support symbols on globals

[dubzzz]

A regression has been introduced in node 18.2.0, it lakes the following snippet fails while it used to work in the past:

constassert=require('assert');constvm=require('vm');constglobal=vm.runInContext('this',vm.createContext());consttotoSymbol=Symbol.for('toto');Object.defineProperty(global,totoSymbol,{enumerable: true,writable: true,value: 4,configurable: true,});assert(Object.getOwnPropertySymbols(global).includes(totoSymbol));

The PR that introduced the regression is: #42963. So I basically attempted to start understanding what it changed to make it still fix the initial issue while not breaking the symbol related one.

Fixes: #45983

[dubzzz]

I'll rework the commit message to fit the guidelines. Do I need to change the commit in-place and force push or can I push an extra commit on top of it?

[aduh95]

I'll rework the commit message to fit the guidelines. Do I need to change the commit in-place and force push or can I push an extra commit on top of it?

Force pushing is the only way in this instance, as we typically squash all the commits in the PR into the first one.

[dubzzz]

Normally everything should be good now. As suggested by @aduh95, I force-pushed on my original commit to fix the commit message. Only changes made since the original commit (before force-push) are: edit commit message and fix lint on the new test file.

[aduh95]

This PR makes test/parallel/test-repl-underscore fail:

=== release test-repl-underscore ===
Path: parallel/test-repl-underscore
Error: --- stderr ---
node:assert:124
throw new AssertionError(obj);
^
AssertionError [ERR_ASSERTION]: Expected values to be strictly deep-equal:
+ actual - expected
[
"'baz'",
'Expression assignment to _error now disabled.',
+ 'Uncaught TypeError: Cannot redefine property: _error',
- '0',
'Uncaught Error: quux',
'0'
]
at assertOutput (/Users/runner/work/node/node/test/parallel/test-repl-underscore.js:246:10)
at Immediate._onImmediate (/Users/runner/work/node/node/test/parallel/test-repl-underscore.js:214:5)
at process.processImmediate (node:internal/timers:475:21)
at process.topLevelDomainCallback (node:domain:161:15)
at process.callbackTrampoline (node:internal/async_hooks:128:24) {
generatedMessage: true,
code: 'ERR_ASSERTION',
actual: [
"'baz'",
'Expression assignment to _error now disabled.',
'Uncaught TypeError: Cannot redefine property: _error',
'Uncaught Error: quux',
'0'
],
expected: [
"'baz'",
'Expression assignment to _error now disabled.',
'0',
'Uncaught Error: quux',
'0'
],
operator: 'deepStrictEqual'
}
Node.js v20.0.0-pre
Command: out/Release/node /Users/runner/work/node/node/test/parallel/test-repl-underscore.js
===
=== 1 tests failed
===
Failed tests:
out/Release/node /Users/runner/work/node/node/test/parallel/test-repl-underscore.js

[dubzzz]

This PR makes test/parallel/test-repl-underscore fail

I'll rework it to make sure this test passes too. I may have missed one condition in the code I added.

[aduh95]

Can you get rid of the merge commit please? It tends to break our tooling. (git reset 020bc92a500df7e8e48b632aed011a06cac0f169 --hard && git cherry-pick dda9dc3c9a30fdc91e30d7f754191114fac94b9f && git push -f should do the trick).

[dubzzz]

Yes definitely I will

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/49303/

[dubzzz]

Not sure to get the reason of the remaining failures 🤔 I started to check on jenkins side but I don't exactly get the reason of the failure and the link to the current change.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/49315/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/49343/

[dubzzz]

@aduh95 Not sure what to do for the nodejs-github-bot failures, I don't get exactly what is failing 🤯

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/49351/

[aduh95]

Not sure what to do for the nodejs-github-bot failures, I don't get exactly what is failing 🤯

Unfortunately sometimes the CI reports unrelated CI failures (either because the test is flaky, or because of a hardware/infra failure). Restarting the CI did not trigger the same issue twice, so it's fair to assume it was indeed unrelated :)

[nodejs-github-bot]

Landed in 6bbc2fb

[dubzzz]

As it fixes an issue in node 18, any way to put it in the next release of node 18 too?

[aduh95]

As it fixes an issue in node 18, any way to put it in the next release of node 18 too?

Before landing on Node.js 18.x, it will need to be released on Node.js 19.x for at least 2 weeks. The backport should be done by a releaser without any action from you after that, or if a manual backport is needed, they'll add a comment here.

node/doc/contributing/backporting-to-release-lines.md

Lines 19 to 25 in a0440c9

	## What can be backported?
	The "Current" release line is much more lenient than the LTS release lines in
	what can be landed. Our LTS release lines (see the [Release Plan][])
	require that commits mature in the Current release for at least 2 weeks before
	they can be landed in an LTS staging branch. Only after "maturation" will those
	commits be cherry-picked or backported.

[dubzzz]

For the record, as some other regressions have been reported following #42963 (the original PR, I patched with this one), I'm trying to cover all of them via dedicated tests and possibly adapt again the proposed option (by adding comment).

[dubzzz]

I opened a follow-up PR that should fix the previously reported issues linked to 18.2.0 and 18.0.0. See #46615