Skip to content

vm: let declaration no longer throws SyntaxError for non-configurable global property in vm context (regression in v26) #63715

Description

@hai-x

Version

v26.3.0

Platform

Darwin 24.6.0 Darwin Kernel Version 24.6.0: xnu-11417.140.69.705.2~1/RELEASE_ARM64_T6041 arm64 (macOS, Apple Silicon)

Subsystem

vm

What steps will reproduce the bug?

A let declaration that collides with a non-configurable property on a vm context's global object is no longer rejected with a SyntaxError. Save as repro.js and run with node repro.js:

const vm = require('vm');
const context = vm.createContext({});

// Define a non-configurable ("restricted") property on the context global.
vm.runInContext(
  "Object.defineProperty(this, 'foo', { value: 1, configurable: false });",
  context
);

// Per ECMA-262 GlobalDeclarationInstantiation step 3.d, a lexical
// declaration colliding with a restricted global property must throw.
try {
  vm.runInContext('let foo;', context);
  console.log('NO ERROR (let foo; was accepted)');
} catch (e) {
  console.log('THREW:', e.constructor.name, '-', e.message);
}

How often does it reproduce? Is there a required condition?

100% reproducible.

What is the expected behavior? Why is that the expected behavior?

let foo; should throw a SyntaxError, because foo is a non-configurable own property of the global object. v24.12.0 behaves correctly: THREW: SyntaxError - Identifier 'foo' has already been declared

What do you see instead?

On v26.3.0 the declaration is silently accepted: NO ERROR (let foo; was accepted)

Additional information

Found via the test262 language/global-code/script-decl-lex-restricted-global.js case.

Activity

  1. Renegade334 commented on Jun 2, 2026

    @Renegade334
    Member

    This might be one of the cases that the behaviour before #63549 was guarding us against (cc @legendecas)

  2. added
    vmIssues and PRs related to the vm subsystem.
    on Jun 2, 2026
  3. legendecas commented on Jun 3, 2026

    @legendecas
    Member

    Thanks for the report!

    This might be one of the cases that the behaviour before #63549 was guarding us against.

    I will try with https://chromium-review.googlesource.com/c/v8/v8/+/7898818.

    As a follow-up, I think we could run the part of the test262 global-code in vm to proactively verify vm changes.

  4. added a commit that references this issue on Jun 29, 2026
  5. added a commit that references this issue on Jul 7, 2026
  6. added a commit that references this issue on Aug 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    vmIssues and PRs related to the vm subsystem.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions