Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#467 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
kotlin, typescript
Domínio
compilers, testing

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Kotlin
Estrelas
33
Forks
27
Merge médio
3d 21h
PRs com merge (30d)
88

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de UnitTestBot/usvm

Todas as issues de UnitTestBot/usvm

Issues semelhantes

Mais issues de Kotlin

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.