Implementation Notes
Generated from the sysml-rs language pack — see the Language Reference index for provenance, licensing, and the raw JSON. 10 cards.
constructor expression does not lower to a distinct kind
Tooling — tooling.implementation.constructor-expression-generic-lowering
A constructor expression (Type(args)) parses cleanly but lowers to a generic InvocationExpression rather than a distinct ConstructorExpression, so it is not distinguished from an ordinary invocation. An implementation limitation, not a language restriction; the concept exists in the grammar.
Support (sysml-rs): parse unknown · resolve unknown · elaborate unknown · execute unknown
Related: Invocation Expression
if / terminate action nodes do not lower to distinct node kinds
Tooling — tooling.implementation.control-node-if-terminate-generic-lowering
The if control node and the terminate action node parse cleanly, but the lowering does not materialize their distinct IfActionUsage / TerminateActionUsage kinds — an if conditional succession lowers to a generic TransitionUsage and terminate does not surface a terminate node. An implementation limitation, not a language restriction; the grammar declares both node kinds.
Support (sysml-rs): parse unknown · resolve unknown · elaborate unknown · execute unknown
Related: Transition Usage, Action Usage
enum members do not lower to a distinct EnumerationUsage
Tooling — tooling.implementation.enumeration-usage-not-distinct
Members declared with enum inside an enum def parse cleanly, but the lowering produces no model element for them at all — not merely a generic usage in place of a distinct EnumerationUsage, but zero elements — so enumerated-value membership is not modelled in any form. This is an implementation limitation, not a language restriction — the concept exists in the grammar.
Support (sysml-rs): parse unknown · resolve unknown · elaborate unknown · execute unknown
Related: Enumeration Definition
message / message-event do not lower to distinct kinds
Tooling — tooling.implementation.message-generic-lowering
A message (and its message event) parses cleanly but lowers to a generic FlowUsage / EventOccurrenceUsage rather than a distinct Message / MessageEvent, so the message’s payload-transfer semantics are not modelled as such. An implementation limitation, not a language restriction; the concepts exist in the grammar.
Support (sysml-rs): parse unknown · resolve unknown · elaborate unknown · execute unknown
Related: Flow Connection, Event Occurrence Usage
individual / portion occurrence prefixes do not lower to distinct kinds
Tooling — tooling.implementation.occurrence-prefix-generic-lowering
The occurrence prefixes individual (individual def/individual), portion (portion), snapshot and timeslice parse but do not lower to their distinct occurrence element kinds — individual def in particular is not recognised as an OccurrenceDefinition marked individual, and the usage prefixes drop to a generic ReferenceUsage/OccurrenceUsage without their individual/portion role. An implementation limitation, not a language restriction; the concepts exist in the grammar.
Support (sysml-rs): parse unknown · resolve unknown · elaborate unknown · execute unknown
Related: Occurrence Definition, Occurrence Usage
prefixed individual|variation <kind> def and ref <keyword-usage> forms misparse
Tooling — tooling.implementation.prefixed-def-and-ref-keyword-usage-misparse
Two LR(1) lookahead splits: (a) individual part def / individual occurrence def / variation part def misparse into a standard_usage plus a feature_declaration — the usage-vs-definition choice must be made on the prefix+keyword lookahead but the forms diverge one token later at def; (b) ref enum / ref port (any ref <keyword-usage>) splits into an empty standard_usage plus the keyword usage. Implementation limitations, not language restrictions — both forms are normative (SysML.xtext OccurrenceDefinitionPrefix:800-806 / IndividualDefinition:813-817 / DefinitionPrefix variation, and RefPrefix on usages). The bare forms (individual def X;, standalone enum e;, port p;) all parse and lower.
Support (sysml-rs): parse unknown · resolve unknown · elaborate unknown · execute unknown
Related: Occurrence Definition, Part Definition, Enumeration Definition, Port Usage
membership-wrapped role usages under-resolve their type refs nondeterministically
Tooling — tooling.implementation.role-usage-resolution-nondeterminism
Membership-wrapped role usages once stamped their typing/reference target as a string prop on the membership (no lowered intermediate usage), so the resolver’s pass-1 loop hit a _ => {} no-op: the target was never resolved and a missing one never counted as unresolved — a silent drop (subject s : Missing gave no diagnostic), with nondeterminism from a runtime fallback scanning a HashMap in hash order. FIXED. Subject/objective: pass 1 routes them through resolve_feature_typing (resolves in the membership’s owning scope, stamps a type Ref, fail-hards a dangling target). assume/require constraint and framed concern reference forms: the parser mints the membership’s owned ConstraintUsage and hangs the grammar’s relationship on it — a ReferenceSubsetting for the bare-name form (SysML.xtext:448), a FeatureTyping for the : Def form — and referencedConstraint derives from that (SysML-vocab.ttl:2576), the resolver fail-harding both through the standard path. actor/stakeholder were always unaffected (they lower a real FeatureTyping).
Support (sysml-rs): parse unknown · resolve unknown · elaborate unknown · execute unknown
Related: Subject, Actor, Stakeholder, Framed Concern, Objective
state effect / state action / trigger subactions do not lower to distinct kinds
Tooling — tooling.implementation.state-subaction-generic-lowering
A state effect behavior, a state action usage and a transition trigger action parse cleanly but lower to a generic ActionUsage / AcceptActionUsage rather than their distinct EffectBehaviorUsage / StateActionUsage / TriggerAction kinds — the state-subaction and trigger roles are not modelled as distinct usages. An implementation limitation, not a language restriction; the concepts exist in the grammar.
Support (sysml-rs): parse unknown · resolve unknown · elaborate unknown · execute unknown
Related: Exhibit State Usage, Accept Action
TextualRepresentation lowers to a generic ReferenceUsage
Tooling — tooling.implementation.textual-representation-generic-lowering
A KerML TextualRepresentation annotating element (a rep with a language string and a body) parses cleanly, but the tree-sitter lowering produces a generic ReferenceUsage rather than a distinct TextualRepresentation element, so the representation’s language and body are not modelled as such. This is an implementation limitation, not a language restriction — the concept exists in the grammar.
Support (sysml-rs): parse unknown · resolve unknown · elaborate unknown · execute unknown
Related: Reference Usage
type-relationship operators do not materialize a distinct relationship kind
Tooling — tooling.implementation.type-relationship-fragment-generic-lowering
The type-relationship operators unioning (unions), intersecting (intersects), differencing (differences), disjoining (disjoint from), feature-inversion (inverse of), type-featuring (featured by) and conjugation (conjugate/~ on a type) parse cleanly, but the lowering does not produce their distinct Unioning/Intersecting/Differencing/Disjoining/ FeatureInverting/TypeFeaturing/Conjugation relationship elements — the participating types are recorded without the specialization relationship being modelled as such. An implementation limitation, not a language restriction; the concepts exist in the grammar. (The ~ port-conjugation form on ports IS modelled — see the conjugated-port-definition card.)
Support (sysml-rs): parse unknown · resolve unknown · elaborate unknown · execute unknown
Related: Specialization