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

[TS] Support field assignments that change the runtime value sort

Ouverte
  • Quelque chose ne va pas ?
#467 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
48/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
kotlin, typescript
Domaine
compilers, testing

Piste de recherche

Start with the unsupported path reported by PR #466 and the related context in issue #465, using the minimal TypeScript example as the reproducer. Add the focused symbolic tests described in the acceptance criteria, including the alias case, and replay generated concrete cases in Node.js; done means both branches have no unsupported paths and existing typed field operations remain correct.

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

Description

Current state (2026-10-14)

Audited against usvm main at 19866c959d.

Structural symbolic object fields can change runtime kind after #458. For concretely allocated declared class fields, WriteField still rejects incompatible value sorts; the method-reference audit also reproduced this boundary.

Remaining acceptance boundary

Represent the current allocated-field value independently of its declared sort and preserve replacement/alias reads. Re-run both Numeric/Text constructor branches with no unsupported path and native replay; preserve the existing explicit boundary until implemented.

Original report and acceptance context, retained for traceability

Problem

TypeScript permits assigning a value whose JavaScript type differs from a field's declared type when the receiver has a union type. The symbolic executor stores fields in separate regions by value sort. After selecting a concrete runtime class, a write of another sort cannot be represented by that class's declared field region. USVM #465 / PR #466 now reports that path as unsupported; it still needs a sound model.

Minimal TypeScript example

class Numeric {
  value: number = 1;
  numericOnly: boolean = true;
}

class Text {
  value: string = "initial";
  textOnly: boolean = true;
}

export function check(useNumeric: boolean): boolean {
  const object = new (useNumeric ? Numeric : Text)();
  object.value = "changed";
  return object.value === "changed";
}

TypeScript accepts this code, and Node.js returns true for both check(true) and check(false). With PR #466, the Text branch is modeled and the Numeric branch is explicitly reported in unsupportedPaths because assigning a string changes the field's runtime value sort.

Expected support

Model the current value of an object field independently of its declared TypeScript type. A write that changes the JavaScript value type must replace the previous value; subsequent reads, including through aliases, must observe the new type and value. Branches that cannot yet be modeled should remain explicitly unsupported rather than produce a stale field value.

Acceptance criteria

  • A focused symbolic test covers both branches with no unsupported paths and checks that both return true.
  • The generated concrete cases replay in Node.js.
  • A second test reads the changed field through an alias and confirms that the original field value is no longer visible.
  • Existing typed numeric, Boolean, reference, and any field operations remain correct.

Related: #465 and PR #466. This task concerns value type changes after assignment, not constructor selection.

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.