Implement Phase 2a Bracket-Form Expose Filter Evaluation#24
Merged
Conversation
- Fix Phase 1 pairing defect: SysmlViewNode.ExposedNames/ExposeBracketFilterTexts (two flattened, unpaired parallel lists) replaced by a single ExposeMembers list of paired ExposeMember(QualifiedName, BracketFilterExpressionText) records, so a view with more than one expose member no longer loses track of which bracket filter belongs to which exposed path. GetExposedNames() is a computed convenience method (not a property, to satisfy SonarAnalyzer S2365) projecting each entry's qualified name for ReferenceResolver. - AstBuilder.ExtractExposedNames now returns IReadOnlyList<ExposeMember> directly instead of two flattened lists; VisitViewUsage sets ExposeMembers. - Generalize ExposeScopeResolver: introduce ExposedScope (PrefixSubjects/ExplicitMembers/Failures) and BracketFilterFailure. ResolveExposedScope re-pairs each resolved Expose edge with its originating ExposeMember (forward-scanning heuristic) and, for a bracket-filtered entry, parses/evaluates it with the unchanged Phase 1 FilterExpressionParser/FilterExpressionEvaluator against a candidate set restricted to SysmlDefinitionNodes in the target's own containment subtree, narrowing that entry's contribution to the matched definitions only. Falls back to whole-subtree inclusion plus a recorded failure on parse/eval failure. IsInSubjectScope/IsRootRelevantToScope updated to check both PrefixSubjects and ExplicitMembers. - Mechanical ExposedScope? type substitution in the 6 other layout strategies (Grid/Browser/ActionFlow/Interconnection/Sequence/StateTransition) so every view kind automatically benefits from bracket-filter narrowing. - Repurpose LayoutWarnings.ForUnevaluatedExposeBracketFilter from "always warns when a bracket filter is present" to "warns only on parse/evaluation failure" (mirroring ForUnevaluatedFilter's existing failure-only pattern), emitting one warning per failed expression. - Add/update tests: paired ExposeMember extraction (AstBuilder), per-entry ExposeScopeResolver narrowing (success/mixed/failure fallback), updated LayoutWarnings tests for failure-only behavior, and an enhanced WorkspaceLoader regression test asserting ExposeMembers pairing on the real OMG corpus fixture. Phase 2b (istype/hastype/all/arithmetic/conditional/feature-chain nav) and Phase 2c (usage-level candidate filtering) remain explicitly deferred per the verified implementation plan's evidence-based rationale (zero corpus evidence for 2b; no current consumer for 2c). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Mirrors Phase 1's precedent (commit 5215c33) structure: - New reqstream requirements: Core.Filtering (SysML2Tools-Core-Filtering-BracketFormExposeEvaluation), Layout.Internal.GeneralViewLayoutStrategy (...-ExposeBracketFilterEvaluation), and updated Language.Semantic.Model.SysmlNode/AstBuilder/ReferenceResolver requirements reflecting the ExposeMembers/ExposeMember model change and the GetExposedNames() rename. Layout.Internal.LayoutWarnings requirement updated for the failure-only warning behavior. - Design docs updated: filtering.md and filter-expression-evaluator.md note the evaluator's reuse (unchanged) by ExposeScopeResolver; expose-scope-resolver.md rewritten for the ExposedScope/BracketFilterFailure shape and per-entry bracket-filter evaluation/re-pairing algorithm; general-view-layout-strategy.md and layout-warnings.md updated for the narrowed scope and failure-only warning; sysml-node.md/ast-builder.md/ reference-resolver.md/sysml-edge.md updated for the ExposeMembers model change; rendering.md drive-by fix for a stale "not yet evaluated" mention of the already-Phase-1-evaluated standalone filter. - Verification docs updated to match (sysml-node.md, ast-builder.md). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…aluation - ROADMAP.md: mark Phase 2a (bracket-form expose filter evaluation) done; explicitly list Phase 2b (zero corpus evidence across 251 OMG files) and Phase 2c (no current consumer - only GeneralViewLayoutStrategy uses definition-scoped candidates today) as deferred with rationale. - docs/user_guide/introduction.md: update 'View Body Statements' and 'Expose vs. Render: Worked Examples' to describe bracket-form expose filter evaluation and its per-entry, independent narrowing/fallback behavior. - test/SysMLModels/Custom/safety-metadata-filter.sysml: add BracketExposeMandatorySafetyView, a named view usage exercising a genuine bracket-form expose filter end-to-end (manually verified via the CLI: the rendered diagram narrows to only the Actuator definition, with no spurious diagnostics). - test/.../RenderIntegrationTests.cs: add DiagramRenderer_RenderWorkspace_BracketExposeMandatorySafetyView_FiltersToMandatoryPart asserting the narrowed rendered scope and the absence of an "unevaluated" bracket-filter warning for the successfully-evaluated expression. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…tale AstBuilder comment - expose-scope-resolver.md: rewrite Acceptance Criteria and Test Scenarios to describe the ExposedScope (PrefixSubjects/ExplicitMembers/Failures) shape and the new bracket-filter success/mixed/failure test scenarios, plus the new IsInSubjectScope/IsRootRelevantToScope explicit-member cases. - general-view-layout-strategy.md: add acceptance-criteria bullets and test-scenario entries for bracket-filter-driven scope narrowing, cross-referencing ExposeScopeResolverTests and the end-to-end RenderIntegrationTests case. - layout-warnings.md: replace the dangling ForUnevaluatedExposeBracketFilter_NonEmpty_ReturnsWarning reference with the actual current test names (ForUnevaluatedExposeBracketFilter_SingleFailure_ReturnsWarningWithReason and _MultipleFailures_ReturnsOneWarningPerFailure), and correct the Acceptance Criteria to state the actual shipped behavior (warns only on parse/evaluation failure; a successfully-evaluated bracket filter produces no warning) instead of the removed "parsed but not yet evaluated" behavior. - filtering.md: add acceptance-criteria bullets and test-scenario rows for the SysML2Tools-Core-Filtering-BracketFormExposeEvaluation requirement's tests. - AstBuilder.cs: fix a stale comment in ExtractImportTarget that still referenced the removed SysmlViewNode.ExposeBracketFilterTexts property and claimed bracket filters are unevaluated; updated to describe the current per-entry pairing/evaluation behavior. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This was referenced Jul 13, 2026
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.
This pull request completes Phase 2a of the
exposebracket-filter feature in the SysML2Tools core, enabling evaluation of bracketedexpose <path>::**[<expr>]filter forms. The implementation reuses the existing Phase 1 parser/evaluator, introduces a paired data model forexposeentries, and ensures that bracket filters are correctly matched to their intended targets. The documentation is updated throughout to reflect these enhancements, and requirements traceability is strengthened. Deferred work for more advanced filter constructs and usage-level metadata is explicitly documented.Bracketed expose filter evaluation (Phase 2a):
expose <path>::**[<expr>]filter form is now parsed and evaluated, narrowing the exposed scope to only the definitions matched by the filter. Failures to parse or evaluate degrade gracefully to whole-subtree inclusion, with warnings only on actual failures. [1] [2] [3] [4] [5] [6]exposeentries is refactored: instead of parallel lists, a singleExposeMemberslist pairs each path with its bracket filter expression, ensuring correct association. [1] [2] [3] [4]Scope resolution and error handling:
ExposeScopeResolvernow returns anExposedScoperecord withPrefixSubjects,ExplicitMembers(for matched definitions), andFailures(for failed bracket filters). The resolution logic is enhanced to pair resolved edges with their originatingExposeMembervia a forward-scanning heuristic. [1] [2] [3]Documentation and requirements traceability:
Deferred work:
istype, arithmetic, conditionals) and usage-level metadata filtering remain deferred, as no real-world need is observed. This is clearly documented for future reference.These changes collectively make bracketed expose filters fully functional, robust, and well-documented, while leaving a clear path for future enhancements.