Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#95 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
65/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go
領域
compilers

調査の方向性

ParseFile と Resolve のエントリポイントから始め、subsetting と redefinition の関係がどのように検証され、diagnostic が収集されるかを追跡します。gRPC サービスを通じて非準拠の subsetting 例を再現し、その後、準拠する対照ケースおよび redefinition ケースとともにこれをカバーする回帰テストを追加します。無効な subsetting モデルが型準拠の diagnostic を報告し、有効なモデルには diagnostic がない状態になれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Go
スター
24
フォーク
5
平均マージ
10時間 7分
マージ済み PR（30日）
536

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Open-MBEE/OpenSysML のほかの issue

Open-MBEE/OpenSysML の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。