Skip to content

ST6RI-984 (original) Values computed while a reference is transiently unresolved are kept after it resolves - #824

Draft
vincemolnar wants to merge 5 commits into
masterfrom
ST6RI-984
Draft

vincemolnar wants to merge 5 commits into
masterfrom
ST6RI-984

Conversation

@vincemolnar

@vincemolnar vincemolnar commented Oct 26, 2026 •

Copy link
Copy Markdown
Contributor

Since release 2026-09, some models that validated without issues get spurious warnings, and an unresolved proxy can end up in the model.

Problems fixed

  1. A metadata value naming an element that is found only through a second import gets the warning "Bound features should have conforming types":
package P {
	private import VerificationCases::*;
	private import VerificationMethodKind::*;
	verification def MassTest;
	verification massTests : MassTest {
		@VerificationMethod { kind = test; }
	}
}

After transformAll(…, true), the model also contains an unresolved proxy (an AcceptActionUsage object) owned by the implied binding connector, which SysML2XMI -g writes out. The examples in sysml/src/examples/Metadata Examples get 10 such warnings.

  1. After EcoreUtil.resolveAll, a feature redefined in a type whose supertype comes from semantic metadata is inherited both redefined and not redefined ("Duplicate of inherited member name …"), for example 70 times in sysml/src/examples/Arrowhead Framework Example.

  2. (Also before 2026-09.) In kerml/src/examples/Association Examples/ProductSelection_OwnedEnds.kerml, after transformAll(…, true), an implied Subsetting owns an unresolved proxy.

Cause

A name lookup nested in the resolution of another reference can fail because the scope excludes the elements whose resolution is in progress. LazyLinkingResource then records the reference as unresolvable until the next change to the resource. Until #815/#821 and #818, the result parameters and default multiplicities created during name resolution changed the resource and so discarded these records. Now the records persist, and values computed and cached in the meantime (an implicit binding connector, a redefinition closure) keep the unresolved proxy.

Changes

  • KerMLLazyLinkingResource: a failure of a lookup nested in the resolution of another reference stays recorded only until that resolution ends.
  • FeatureAdapter.getAllRedefinedFeatures: a result that contains an unresolved proxy is not cached.
  • ConnectorUtil.addConnectorEndTo, TypeUtil.insertImplicitSpecializations, FeatureUtil.insertImplicitTypeFeaturings: an unresolved proxy is not added as an owned related element.

Tests

NestedResolutionTest covers problems 1 and 2; both tests fail without these changes. The full build with all tests passes.

@vincemolnar
vincemolnar requested a review from seidewitz October 26, 2026 11:53
@seidewitz
seidewitz marked this pull request as draft October 26, 2026 18:52
@seidewitz seidewitz self-assigned this Oct 26, 2026
@seidewitz seidewitz added the bug Something isn't working label Oct 26, 2026
@seidewitz
seidewitz marked this pull request as ready for review October 26, 2026 23:20
@seidewitz seidewitz added this to the 2026-10 milestone Oct 26, 2026
@seidewitz

Copy link
Copy Markdown
Member

@vincemolnar
I have:

  1. Revised the version on this branch to 0.63.1, so that it can be published in release 2026-09.1. The version will be restored to 0.64.0 before merging it into master.
  2. Split your one commit into three (with no changes in the code).
  3. Tested performance using SysMLInteractiveProfiler (no problems).

Let me know if you concur.

@vincemolnar

Copy link
Copy Markdown
Contributor Author

@seidewitz I concur, thanks! I have also updated the PR description to make it self-contained. Let me know if you want it restored.

@seidewitz
seidewitz marked this pull request as draft October 28, 2026 15:25
@seidewitz seidewitz changed the title ST6RI-984 Values computed while a reference is transiently unresolved are kept after it resolves ST6RI-984 (original) Values computed while a reference is transiently unresolved are kept after it resolves Oct 28, 2026
@seidewitz

Copy link
Copy Markdown
Member

Further testing has shown that the original general solution proposed in this PR results in unacceptable performance when there are links that cannot be resolved, not just temporarily, but permanently during the processing of a model. While work continues on this general solution, a more specific solution is proposed in PR #825, which is adequate for a release update to eliminate user-visible symptoms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants