Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Appendix F. Diagnostic Codes

The chapters cite diagnostic codes inline – E200 for an unresolved name, S001 for a duplicate member, PH006 for a Real that could be an ISQ type. This appendix explains where those codes come from, what the families mean, and how to look a code up. What it deliberately does not contain is an exhaustive hand-maintained code table: earlier editions carried one, it drifted from the tool (codes appeared, wordings changed, at least one severity was listed wrongly), and a reference that silently rots is worse than none. The live tool output is authoritative; a reference generated from the tool’s own source is planned for the sysml-rs portal.

Tag: [TOOLING]. The codes are sysml-rs’s diagnostic vocabulary – other SysML v2 implementations will emit a different set or use different identifiers. The checks behind the codes (e.g. “every requirement should have a verification case”) are spec-faithful where applicable; the labels are sysml-rs.

Where diagnostics come from

sysml-rs emits diagnostics from two layers:

  • The core analyzer checks structure and semantics as it elaborates a model: ownership integrity, name resolution, well-formedness of memberships and specializations, property validation, import health, and physics typing.
  • The runtime’s health checks look at what a model would do when executed: state machines with unreachable states, actions with no steps, flows with mismatched endpoints, verification cases that would vacuously pass, constraints that cannot be evaluated.

Every diagnostic carries a severity – error (the model does not parse, validate, or execute), warning (structurally valid but semantically suspect), or info (a non-blocking observation, often intentional) – and info-level codes deserve a review, not a reflexive fix.

The code families

Codes are grouped by prefix into families. These are the families the chapters reference; the set is open-ended and grows with the tool:

PrefixFamilyCross-reference
EStructural integrity and name resolution (E200 is the unresolved-name code behind the auto-import quick-fix)Chapter 4
SSemantic well-formedness: duplicate names, misplaced memberships, illegal typingsChapter 3, Chapter 12
VProperty validation
IMImports: circular chains, duplicates, unused importsChapter 4
SMState machines: missing initial states, unreachable states, dead endsChapter 8
AXActions: empty bodies, unreachable steps, malformed control nodesChapter 7
FLFlows and ports: missing endpoints, type mismatches, direction conflictsChapter 6
VCVerification cases: missing subjects, vacuous verificationChapter 10
CNConstraints: uncompilable or non-boolean expressions, violationsChapter 9
RQRequirements: unsatisfied, unverified, unresolvable referencesChapter 10
PHPhysics: incompatible domains, conservation imbalance, ISQ-type suggestions (PH006 carries the “did you mean ISQ type?” quick-fix)Chapter 14, Appendix E

Looking a code up

When a diagnostic fires, read it where it lives:

  • On the command line, sysml inspect --diagnostics <file> reports every diagnostic for a file or workspace, with its code, severity, and span. The surrounding CLI workflow – checking, querying, and inspecting models – is documented on the sysml-rs portal: CLI workflows.
  • In the editor, the same diagnostics appear as squiggles with the code attached, and codes with quick-fixes (auto-import for E200, the ISQ replacement for PH006, and others) offer them in place. See Editors for setup.

The message text is written to stand alone – it names the element, says what is wrong, and usually says what to do – so the code is a stable handle for searching and suppressing, not something you should need a table to decode.

When the tool is wrong

A diagnostic can itself be the defect: some codes are known to fire on well-formed models. Confirmed cases – with reproductions and workarounds where they exist – are tracked on the portal’s Known limitations page. If a diagnostic contradicts what you can verify against the specification, check that page before rewriting a correct model.