a fresh node startup has populated RegExp statics

[ljharb]

Version

v18.5.0

Platform

n/a

Subsystem

No response

What steps will reproduce the bug?

node -pe 'RegExp.$_' will print out WeakRef.

node, and then RegExp.$_, will print out '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'.

This also applies to $&.

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

No response

What is the expected behavior?

No response

What do you see instead?

I expect the empty string for all RegExp statics.

This is a problem for a few reasons:

1. it exposes internal regular expression usage in node core
2. the value might change from any version to any version, so if anyone's foolish enough to rely on it, they'll break in a non-major
3. it's unseemly

If there's a point, right before node starts running user code, and right before the repl becomes available, then we could execute a trivial regular expression operation to clear all the statics.

Alternatively, this may be exposing non-primordial regex usage, and it's likely that switching to primordials (since I believe they'd update the statics on the primordial RegExp instead of the global RegExp) would solve this as well.

Additional information

No response

[ljharb]

cc @aduh95

[hemanth]

I would like to work on the fix for this. Looks like it is a side of this.

[ljharb]

ah, maybe the statics are populated by the same realm then :-/ that would be great for the repl, but wouldn't address node itself.

[richardlau]

Duplicate of #18931?

[ljharb]

The repl part, yes - but not the node -pe part.

[aduh95]

it's likely that switching to primordials (since I believe they'd update the statics on the primordial RegExp instead of the global RegExp) would solve this as well.

Before user code is executed, primordials.RegExp === globalThis.RegExp, so that wouldn't help. Creating an empty RegExp sounds fine though.

@hemanth if you want to work on the REPL side, that'd be great, I have a fix ready for the other problem.

[hemanth]

@aduh95 Trying to understand the intent behind this.

regExMatcher.exec(savedRegExMatches.join(sep)) results in:

[
  '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00',
  '',
  '',
  '',
  '',
  '',
  '',
  '',
  '',
  '',
  index: 0,
  input: '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00',
  groups: undefined
]

[aduh95]

My understanding is it's trying to clear up whatever RegEx node internals may have run between two REPL entries if that makes sense.

1. The user enters a regex operation, and hit ENTER to eval their entry.
2. Node.js internals run other regex operations that overrides RegExp statics.
3. The user expect to find RegExp statics in the same state their original operation should have left them.

I think that works for RegExp.$1 to RegExp.$9, but not the other ones. Not sure this could be achieve without re-running the user code.

[hemanth]

Node.js internals run other regex operations that overrides RegExp statics.

If we use primordial SafeRegExp we can avoid this side effect?

[aduh95]

Using SafeRegExp is not very practical because that would mean we can no longer use regex literals in core. Trying to migrate all of core to SafeRegExp seems like an unreasonable amount of work.

[hemanth]

@aduh95 Hmm, We should revive #20549 ?

[aduh95]

From my point of view #20549 (comment) and #20549 (comment) is a good TL;DR for this thread. I'd say let's try this approach and run benchmark to see how it performs. IMO it would be worth creating a SafeRegExp class in primordials rather than the getInternalGlobal hack.

I wonder if ShadowRealms integration gives a new solution to this problem, allowing us to run REPL code on another Realm sounds like something that should also fix the issue. Should we move this discussion to #18931 since only the REPL is at stake now?

[benjamingr]

Isn't RegExp.$_ a standard web-compatibility legacy feature? Spec wise are we safe to remove and not support it?

[aduh95]

It's implemented by V8, I'm sure we can easily disable it – but yes, as far as ECMAScript is concerned, it doesn't exist.

[benjamingr]

@aduh95 what about https://github.com/tc39/proposal-regexp-legacy-features/#additional-properties-of-the-regexp-constructor ? I thought there was a proposal to make it standard but it looks abandoned?

Anyway - no strong feelings from me, I figured it's one of these things like String.prototype.bold

[hemanth]

Legacy RegExp proposals is in stage 3!

So, are we leaning towards removing RegExp.$_ or SafeRegExp?

@aduh95 Nods, it makes sense to move the discussion to #18931