Repository navigation
fix(resolve): do not report name collisions among a view's exposes alone - #1635
Merged
Merged
Conversation
Co-Authored-By: jason.han <hanhuijun@gmail.com>
Contributor
Author
|
I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".
|
Co-Authored-By: jason.han <hanhuijun@gmail.com>
…n retired Co-Authored-By: jason.han <hanhuijun@gmail.com>
6 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What and why
Since
name-conflictstarted covering imported memberships, a view whoseexposes bring two members of one name warns, although an Expose is the thing a view uses to show elements and both are shown:sysml -validatereportedwarning[name-conflict]: Duplicate of imported member name 'p'whilesysml -render V::vdraws bothp. Recursive exposes over real models hit this constantly.checkImportedNames(internal/semantic/resolve/distinguishability.go) now skips a name when every colliding membership comes only through an Expose.gatherImportedrecords per membership whether every import reaching it is an Expose (importedMember.exposedOnly), so a membership an expose brings first and a plainimportreaches again still counts as imported. The warning stays when a plain import or an inherited member is part of the collision, since a name written in the view then changes what it resolves to. The hiding itself (KerML 7.2.5.4) does not change: the colliding names are still not members of the view, and an unqualifiedpwritten inside it stays unresolved with the hidden-import hint. Owned-duplicate reporting and strict mode do not change either.Specification basis
Namespace::importedMembershipsexcludes "Memberships that have distinguisibility collisions with each other or with any ownedMembership", so colliding imported memberships are not inmembership, andvalidateNamespaceDistinguishibility(which ranges overmembership) is not violated by them.ViewUsage::exposedElement = ownedImport->selectByKind(Expose).importedMemberships(Set{}).memberElement->select(includeAsExposed)reads each Expose's own memberships, so a collision among exposes never changes what the view exposes.The
docs/project/spec-compliance.mdrow on imported memberships colliding by name now says this and lists the new tests. The row's status is unchanged.How it was verified
go build ./...,go vet ./...clean;gofmt -l .empty.go test -count=1 ./internal/semantic/resolve/... ./internal/check/... ./tests/resolve/...passes. New cases: two exposes colliding give no diagnostic andExposedMembersstill returns bothV::a::pandV::b::p(tests/resolve/expose_name_conflict_test.go);import a::*+expose b::*, two exposes plus a plain import, an inherited member plus an expose, and a package with two collidingimports all still warn (same file andinternal/check/passes/imported_name_conflict_test.go).sysml -validategiveswarning[name-conflict]on develop and nothing on this branch;sysml -render V::vdraws bothV::a::pandV::b::p.sysml -validateover the 153.sysmlfiles undersrc,extensionsandexamples/sysml-diagram-samplesof the MEMO application's repository: 29 → 0name-conflictwarnings, and no new diagnostic of any kind.Corpus gates
Corpora fetched with
./scripts/download-pilot-corpora.sh,./scripts/download-spec-examples.shand./scripts/download-training-examples.sh;go test -count=1 ./tests/corpus -run 'TestPilotCorpora|TestSpecExamples|TestTrainingExamples'passes (TestPilotCorporaDiagnostics,TestSpecExamplesDiagnostics,TestTrainingExamplesSemanticErrors). No ratchet moved:pilot_corpora_expected.txtand the spec-examples expectation are unchanged, since every imported-collision row in those corpora comes through a plain recursiveimport(the Annex A models) and keeps its warning;training_examples_expected.txtis untouched.Pilot differential
The differential records the imported-collision rows, so its baseline is re-recorded (
go run -C tools ./cmd/pilot-diff -update; the pilot column is live, 0jar not found). Every movement against the committed baseline:examples/general-views-demo/vehicle.sysml:102unmappedwarning retired (Duplicate of imported member name 'mass')definitionView's singleexpose VehicleStructure::**[…]reachesVehicle::mass,vehicle::massandheavyVehicle::mass; all three come through the Expose, so it is no conflict.examples/self-model/asciidoc/markup.sysml:16unresolved-referenceseverityerror→warningpilot-diff -outrun on currentorigin/develop(55fafe2) already giveswarningon this row, and differs from this head's recording only by thevehicle.sysml:102row above. The row is deterministic: with no AsciiDoc converter configured (OPENSYSML_ASCIIDOCTORunset) it is the same on every run, and two runs at this head recorded byte-identical JSON.Totals: 518 → 519 fully agreeing, 360 → 359 only ours, 1469 → 1468 our diagnostics; agreed (1098), severity-only (11), only-pilot (2462) and pilot diagnostics (3571) unchanged.
docs/project/pilot-differential.mdgets the round, its Results and current-counts tables;make docs-countsregenerated the README and architecture figures (the errata-corrected figure moves 520/358 in step), and the skills that quote the headline are refreshed so the skill-count guard holds.Checklist
make testandmake lintpass locallychanges/unreleased/<slug>.<section>.md, not as an edit toCHANGELOG.mdmake docs-countsrun if a gate count moved (compliance rows need nothing: the census is counted at docs build)F4,K5) in the body, docs, or changelogLink to Devin session: https://nasa-jpl-demo.devinenterprise.com/sessions/49dd100270534e66bac4527030ada332
Open in Devin Desktop: https://nasa-jpl-demo.devinenterprise.com/desktop/session/49dd100270534e66bac4527030ada332?variant=devin
Requested by: @HuiJun