this in a part-owned action resolves to the action performance instead of the owning part

[awolokita]

Model and observed behaviour

Minimal model (`bug.sysml`), on sysml v0.9.0 (Windows):


// Written in file: bug.sysml
action def A {
    ref part ctx : P;
}
part def P {
    action a : A {
        :>> ctx = this;
    }
}
part p : P;


Command:


sysml> %load bug.sysml
sysml> %instantiate p
sysml> %features p.a


Output:


Instance: p.a (ID: 2)
Features:
  ctx: <error: feature value a.ctx: type mismatch: cannot write instance(2) (instance) to a feature typed by P>


`instance(2)` is the performance of action `a` itself (i.e. `p.a`), not `p`. So
`a.this` resolved to the action, and `:>> ctx = this` tried to write the action into a
`P`-typed feature.

What the specification requires

a is an ownedAction of part p, so a.this must be p; :>> ctx = this should
set ctx to p, with no error.

OMG SysML v2.0 (formal/2026-03-02), Part 1, §9.2.4.2.1 (Part):

"The this reference of a ownedAction is always its owning Part."

Same document, §8.4.13.2 (Action Usages — "Semantics of this"):

"... the value of this is the top-level Action in the hierarchy ..., unless that
top-level Action is itself one of the ownedActions of a Part (or one of the
ownedPerformances of an Item), in which case the value is that Part (or Item)."

Kind of gap

Valid model is rejected (false positive)

Reference implementation

No response

Version

sysml v0.9.0 Commit: ee54ea0 Build time: 2026-09-25_01:12:11 Go version: go1.25.0

[HuiJun]

Thank you for this report! Turns out this is a bug in the 0.9.0 version and it was addressed in #635 when we found this. However, we did not add a test specifically addressing this into our conformance tests, so we'll go ahead and do that now. Otherwise, if you want to try it out, our develop branch currently does handle this correctly, and the fix will be included in our next release, 0.9.1, which should be out tonight or tomorrow morning. I'll leave this issue open until we can add the conformance tests. Thanks again!

[HuiJun]

Addressed in #721

[awolokita]

Confirm that this has been fixed in 0.9.1. Thanks!