Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Hermes: two upstream conformance gaps worked around in the unit tests (for...in shadowing, napi ToObject)

Abierto
  • ¿Algo no está bien?
#219 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
cpp, javascript
Área
backend, testing-qa

Línea de trabajo

Comienza con Tests/UnitTests/Scripts/tests.ts y el pin de Hermes en el CMakeLists.txt de nivel superior. Construye la ruta de Hermes de este repositorio para reproducir el comportamiento de sombreado de for...in y el comportamiento de coerción de primitivos de Node-API contra el SHA fijado, y después revisa lib/VM/JSObject.cpp y API/napi/hermes_napi_object.cpp. Se considera terminado cuando se obtenga evidencia ejecutable adecuada para informes upstream y se elimine cada workaround únicamente después de que aterrice la corrección correspondiente de Hermes.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug

[Filed by Copilot on behalf of @bghgary]

Tracks two distinct Hermes conformance gaps that #218 works around in Tests/UnitTests/Scripts/tests.ts. They are in different layers of Hermes and neither is fixable here — this issue exists so the workarounds have a referent and can be removed when upstream fixes them.

Hermes is pinned in the top-level CMakeLists.txt to facebook/hermes static_h at 348582831f50954895da8e80cc91112d51036c69 (tip as of 2026-06-03).

1. for...in reports a property shadowed by a non-enumerable own property

Layer: Hermes VM (lib/VM/JSObject.cpp)

Per spec, for...in adds every own key to its visited set regardless of enumerability, but only emits the enumerable ones. A non-enumerable own property must therefore hide a same-named enumerable inherited one.

const parent = { shared: 1 };
const child = Object.create(parent);
Object.defineProperty(child, "shared", { value: 2, enumerable: false });

const keys = [];
for (const k in child) { keys.push(k); }
// expected: []      (child.shared is 2; the inherited 1 is unreachable)
// Hermes:   ["shared"]

Multi-level, same cause:

const gp = { deep: 0 };
const mid = Object.create(gp);
mid.middle = 1;
Object.defineProperty(mid, "deep", { value: 9, enumerable: false });
const leaf = Object.create(mid);
leaf.own = 3;
// expected: ["own", "middle"]
// Hermes:   ["own", "middle", "deep"]

Plain inheritance with no shadowing behaves correctly, so this is specific to the shadowing rule rather than enumeration generally.

Cause, from appendAllPropertyKeys in lib/VM/JSObject.cpp at the pinned SHA: own keys are collected with OwnKeysFlags().plusIncludeNonSymbols().plusKeepSymbols() — no IncludeNonEnumerable — so enumerableProps holds only enumerable own properties. The dedup set is populated exclusively by addToDedup, which is called only after a property has been pushed. A non-enumerable own property is therefore never collected and never deduped, so the inherited one is emitted.

Notably Hermes' own Node-API implementation gets this right, and deliberately — API/napi/hermes_napi_object.cpp sets okFlags.plusIncludeNonEnumerable() with the comment "Always include non-enumerable so we can post-filter uniformly", and inserts into seenKeys before applying the enumerable filter. So the two enumeration paths inside Hermes disagree with each other.

Impact here: none on our behaviour — napi_get_property_names is correct on Hermes. It only means Hermes' for...in cannot be used as a test oracle. #218 handles this with a runtime probe (forInHonoursShadowing) rather than naming the engine, so it self-heals if upstream fixes it.

Evidence: source inspection at the pinned SHA, plus an empirical repro on the prebuilt Hermes CLI v0.13.0, which reproduces both cases above (V8 is correct on both). See the caveat below.

2. napi_get_property_names rejects primitives instead of applying ToObject

Layer: Hermes Node-API (API/napi/hermes_napi_object.cpp)

Node-API specifies the argument is coerced with ToObject, so a primitive is wrapped and its properties reported — napi_get_property_names("ab") should yield ["0", "1"]. V8 does this via CHECK_TO_OBJECT.

Hermes' napi_get_all_property_names (which napi_get_property_names delegates to) instead does:

RETURN_STATUS_IF_FALSE(
    env, objPhv != nullptr && objPhv->isObject(), napi_object_expected);

so any non-object is rejected outright with no coercion path.

Impact here: the primitive-wrapping cases in #218's argument coercion block are skipped on Hermes.

Evidence: source inspection at the pinned SHA only — see below.

Before filing upstream

facebook/hermes is actively maintained and responsive, but two recent issues were closed as suspected AI-generated spam specifically for lacking a minimal repro, and maintainers routinely distinguish between stable, static_h and V1 when triaging. So neither of these should be filed upstream until:

  • Issue 1 is reproduced against the pinned static_h SHA, not just v0.13.0. The current repro is roughly two years older than the pin; inspection at the pin shows the same defect, but that is not the same as running it.
  • Issue 2 has any runnable repro. It is a Node-API entry point and is not reachable from the hermes.exe CLI, so there is currently no empirical evidence at all.

Building this repo's Hermes leg locally satisfies both: it uses the exact pinned SHA and exposes the Node-API surface.

Removing the workarounds

Both live in Tests/UnitTests/Scripts/tests.ts:

  • Issue 1 — the forInHonoursShadowing probe. Nothing to do; it starts using for...in as an oracle again once upstream is fixed.
  • Issue 2 — the napiEngine === "Hermes" skip on the primitive cases. Un-skip once upstream applies ToObject.
Lenguaje dominante
C++
Estrellas
22
Forks
23
Merge medio
2 h 29 min
PR fusionados (30 d)
3

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de BabylonJS/JsRuntimeHost

Todos los issues de BabylonJS/JsRuntimeHost

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.