Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Subsetting type conformance is not checked, although redefinition type conformance is

Chiusa
  • Qualcosa non va?
#95 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
65/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go
Ambito
compilers

Direzione di ricerca

Inizia dagli entry point ParseFile e Resolve e traccia come vengono validate le relazioni di subsetting e redefinition e come vengono raccolte le diagnosi. Riproduci l’esempio di subsetting non conforme tramite il servizio gRPC, quindi aggiungi una regressione che lo copra insieme al caso di controllo conforme e al caso di redefinition. Il lavoro è completato quando il modello di subsetting non valido segnala una diagnosi di conformità dei tipi, mentre il modello valido rimane pulito.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Subsetting type conformance is not checked, although redefinition type conformance is

Version: v0.3.0, sysml-grpc-linux-amd64, SHA-256 b39b720e020c325020af95c33640ad3583c938d74c40d29a0741fab6c03412de
Path: ParseFile + Resolve over gRPC, one inline document

Summary

The service validates that a redefining feature's type conforms to what it redefines, and it validates the multiplicity bound for subsetting and redefinition alike — but it does not validate that a subsetting feature's type conforms to what it subsets. That case produces no error, no warning, and no diagnostic of any kind.

The asymmetry looks unintentional rather than deliberate: the multiplicity rule is already applied to both relations (its message says so — "Subsetting/redefining feature should not have larger multiplicity upper bound"), and the redefinition type check already computes and formats exactly the diagnostic the subsetting case needs.

Reproduction

Each block is one document through ParseFile, then Resolve. Diagnostics are the union of both, de-duplicated.

1. Subsetting with a non-conforming type — expected a diagnostic, got none

package P {
	class A;
	class B;
	feature g : A;
	feature f : B subsets g;
}

→ (no diagnostics at all)

f subsets g asserts that f's values are among g's. g holds As and f is a B, which is unrelated to A, so no value of f can be a value of g.

2. Control — subsetting with a conforming type

package P {
	class A;
	class B specializes A;
	feature g : A;
	feature f : B subsets g;
}

→ (no diagnostics at all)

Correct, and together with (1) it shows the check is absent rather than merely lenient: the well-formed and the ill-formed model are indistinguishable in the output.

3. The same violation through redefinition — reported

package P {
	class A;
	class B;
	class C { feature g : A; }
	class D specializes C { feature g : B redefines C::g; }
}

→ [error] g (typed by B) redefines g (typed by A): types do not conform

4. The multiplicity half of subsetting — reported

package P {
	class A;
	feature g : A [0..5];
	feature f : A subsets g [0..10];
}

→ [warning] Subsetting/redefining feature should not have larger multiplicity upper bound

5. Control — the resolver is working

package P {
	class A;
	feature g : Nonexistent;
}

→ [error] unresolved reference: Nonexistent

Also reproduces in SysML usage syntax

Same silence with part def / part in a .sysml document, so it is not specific to the KerML surface:

package P {
	part def A;
	part def B;
	part g : A;
	part f : B subsets g;
}

→ (no diagnostics at all), and likewise with part def B :> A for the conforming control.

Expected

Case (1) reports a diagnostic in the shape case (3) already produces — e.g. f (typed by B) subsets g (typed by A): types do not conform.

Why it matters to a downstream consumer

Silence is indistinguishable from a clean bill of health. A tool that asks the service to validate a model gets an empty diagnostic list and has no way to learn that half of the subsetting check did not run — so it reports the model as sound. For consumers that build a specialization/subsetting graph out of the parsed model (we translate one to OWL), an unchecked subsetting edge propagates into everything derived from it.

Environment

Reproduced on Linux x86-64 against the published v0.3.0 release asset, checksum as above, over the gRPC API only. Happy to supply the exact request payloads if useful.

Lingua principale
Go
Stelle
24
Fork
5
Merge medio
10h 11m
PR unite (30g)
572

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Open-MBEE/OpenSysML

Tutte le issue di Open-MBEE/OpenSysML

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.