Repository navigation
fix(powershell): link enum members with case_of instead of contains - #4092
rajatnagda45 wants to merge 1 commit into
Conversation
A PowerShell enum member is a discriminant case, not a declared field, so it should hang off its enum with a case_of edge like every other language that has enums (Java Graphify-Labs#1719, C#, Swift, Rust, VB.NET). PowerShell was routing enum members through the same contains path used for class members. The relation is not cosmetic: case_of targets are excluded from constructor binding, so an enum member named like a type could previously be mistaken for one. Update the existing enum test to expect case_of and add a focused regression test asserting enum members get case_of (and not contains) while the file still contains the enum type via contains.
|
Thanks for the pull request, @rajatnagda45. A maintainer will review it soon. Want to talk it through while it is in review? Come join us on our Discord server. For longer-form discussion there is also GitHub Discussions. A couple of things that speed up review: make sure the test suite passes on Python 3.10 and 3.13, and that the change keeps extraction deterministic. |
![graphify-labs[bot]](https://avatars.githubusercontent.com/in/4356270?s=60&v=4){kind=small}
There was a problem hiding this comment.
Graphify reviewed this change.
Looks safe to merge — no coupling regressions and no blocking issues, checked against the code graph (not a self-assessment).
Formal verification. PR-changed functions: 1/1 verified (0 proven, 1 may-equivalent, 0 distinguished) · 0 not verified.
Graphify review — findings
Switches PowerShell enum members to hang off their enum via case_of instead of contains, matching how Java, C#, Swift, Rust and VB.NET model enum cases. Because case_of targets are excluded from constructor binding, an enum member whose name matches a type no longer resolves as that type. The file-to-enum relation still uses contains, and a new test pins down both relations.
No blocking issues surfaced. 1 lower-confidence candidate did not survive cross-model review.
Analysis details — impact, health, verification
Impact & health
Graphify review
Impact — 642 functions depend on the 642 functions this change touches.
Health — this change adds coupling hotspots:
- new:
extract_powershell()— 17 callers, 6 callees - new:
extract_powershell_manifest()— 10 callers, 3 callees - new:
walk()— 1 callers, 6 callees
Verification — 642 functions in the blast radius were not formally verified this run (proofs are advisory here).
Gate & verification
graphify gate
PASS — objectively clean (no health regressions, tests not run — proofs not run this pass (advisory)). Grounded, not self-assessed.
Advisory (not blocking):
- verification_scope: 642 function(s) in the blast radius were not formally verified this run
Test selection
Test selection
1 of 329 test file(s) selected (0%) via static blast radius.
tests/test_languages.py— impact, changed-test
Selection is safe under the controlled-regression assumption; always-run tests + a periodic full run are the backstops. Advisory — it never changes the check verdict.
Docs that may be stale (advisory)
CHANGELOG.md§ 0.9.68 (2026-09-25) (lines 125-137): references changed symbolspropertyCHANGELOG.md§ 0.9.39 (2026-08-10) (lines 506-513): references changed symbolspropertyCHANGELOG.md§ 0.9.38 (2026-08-09) (lines 514-522): references changed symbolspropertyCHANGELOG.md§ 0.9.27 (2026-07-26) (lines 619-639): references changed symbolspropertyCHANGELOG.md§ 0.8.50 (2026-06-27) (lines 1054-1071): references changed symbolspropertyCHANGELOG.md§ 0.8.21 (2026-05-27) (lines 1344-1357): references changed symbolsproperty
Formal verification
No difference found (not proven): No behavior difference found in extract\_powershell (not a proof).
The verifier ran both versions of extract\_powershell on many inputs and saw identical behavior every time. Strong evidence the change is safe, but evidence, not a proof.
Guarantee: Empirical: differential testing (both versions run on many generated inputs). A divergence on an untested input remains possible, so this is 'no counterexample found', not 'proven equivalent'.
Note: An input the sampler did not try could still differ.
· 3 more finding(s) on lines outside this diff (see the check run).
|
Landed in v0.9.77 via an authorship-preserving cherry-pick, so your commit is on |
2 participants
Problem
Closes #4091.
A PowerShell enum linked its members to the enum with a
containsedge — the relation used for real declared members. Every other language with enums emitscase_ofper member (Java #1719, C#, Swift, Rust, VB.NET #4054). PowerShell was still an outlier.Implementation
One-line relation change in
graphify/extractors/powershell.py: the enum-member edge now usescase_ofinstead ofcontains. File-level containment of the enum type itself is untouched and keepscontains.This is not cosmetic:
case_oftargets are excluded from constructor binding (_member_nidsinextract.py), so an enum member named like a type can no longer be mistaken for a constructable member.Verification
test_powershell_enum_is_extracted_and_reference_resolvesto expectcase_of, and addedtest_powershell_enum_members_emit_case_of_not_contains. Verified the new test FAILS on pre-fix v8 and passes with the change.uv run pytest tests/→ 6491 passed, 15 skipped (security/wheel env-only tests deselected).ruff checkclean;pyrighton the changed file adds no new errors (the single pre-existing_make_idbaseline error is unchanged).Limitations
PowerShell class properties are not emitted as member nodes today, so the regression test uses the file→enum containment edge as the
containscontrol.