GeezerVison

globalThis[Symbol.toStringTag] was unconditionally initialized
to the sandbox's constructor name, even if it is not present on the
sandbox object.

The original behavior was something like this:

When we still used a function template's instance template for the global object template. The [Symbol.toStringTag] setting was used to make it look the same while allowing different vm contexts to use different global object templates, so that contexts can share a snapshot. I am not sure how necessary it is to ensure that the globalThis in the new context has the same name as the sandbox's constructor, though. Maybe another alternative is to return something specific for this in the getter/setter/definer interceptors?

Codecov Report

Attention: Patch coverage is 87.50000% with 1 line in your changes missing coverage. Please review.

Project coverage is 87.31%. Comparing base (cc26951) to head (acf009b).
Report is 354 commits behind head on main.

@@            Coverage Diff             @@
##             main   #54522      +/-   ##
==========================================
- Coverage   87.34%   87.31%   -0.03%     
==========================================
  Files         649      649              
  Lines      182544   182759     +215     
  Branches    35030    35048      +18     
==========================================
+ Hits       159445   159579     +134     
- Misses      16372    16459      +87     
+ Partials     6727     6721       -6     

@joyeecheung FunctionTemplate::SetClassName does not set up @@ToStringTag automatically. AFAICT, it is used as the function name and template uniqueness check.

On v18.8.0 where #44252 was not backported, the @@ToStringTag is not installed on the vm globalThis.

Yes, hence it was just done to keep it “look the same as before” (which matters when it gets logged by the console, etc. I don’t know how important it is though, maybe it’s fine to break the display name)

I left @@toStringTag untouched being an exception as is. The breaking behavior can be a separate PR. This PR still fix inconsistency on Object.getOwnPropertyNames, Object.getOwnPropertySymbols, and Object.keys.

@nodejs/vm @joyeecheung please take a look again, thanks!

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

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

Landed in d2479fa