Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

[TS] Evaluate instanceof against the runtime constructor value

Fermée
#457 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
45/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
kotlin, node.js, typescript

Piste de recherche

Start at the current instanceof evaluator and its use of the static EtsIR checkType, then review the focused symbolic-test entry point described in the issue. Account for dependencies JacoDB #390 and UnitTestBot/jacodb#396 before testing. Done means both outcomes share one static RHS type, direct checks remain covered, and generated inputs and results replay in Node.js.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

enhancement

Problem

The current instanceof evaluator uses the static checkType from EtsIR. For a dynamic right-hand side, that type does not identify which constructor object the program actually selected. JacoDB PR #395 therefore marks dynamic checks unsupported instead of reporting a possibly false Boolean.

Minimal TypeScript example

class A {}
class B {}
export function check(useA: boolean): boolean {
  const ctor = useA ? A : B;
  return new A() instanceof ctor;
}

Node.js returns true for check(true) and false for check(false). The ctor expression must be evaluated once; the membership check must use that runtime value, not its static union type.

Expected support

Use the right-hand constructor value and the left-hand object's prototype chain for the supported class-constructor model. Preserve JavaScript behavior for a non-callable RHS (TypeError) where that value is representable. If custom Symbol.hasInstance is outside the current model, report that case as unsupported explicitly.

Acceptance criteria

  • A focused symbolic test obtains both outcomes with the same static RHS type and distinguishes unsupported from failure.
  • Generated inputs and results replay in Node.js.
  • Direct value instanceof A remains covered and correct.

Dependencies: JacoDB #390 (RHS evaluation) and UnitTestBot/jacodb#396 (declared class runtime values). Implement this as a separate USVM PR.

Langage dominant
Kotlin
Étoiles
33
Forks
27
Merge moyen
3 j 21 h
PR mergées (30 j)
88

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de UnitTestBot/usvm

Toutes les issues de UnitTestBot/usvm

Issues similaires

Plus d'issues Kotlin

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.