Skip to content

Extract whole enum declarations as units so mod-added members survive merges - #36

Open
TheValiantOne wants to merge 1 commit into
mainfrom
fix/enum-units
Open

Extract whole enum declarations as units so mod-added members survive merges#36
TheValiantOne wants to merge 1 commit into
mainfrom
fix/enum-units

Conversation

@TheValiantOne

Copy link
Copy Markdown
Owner

Summary

The last compile error class from live validation: I dont know any 'HVS_Modcrab' — a mod (modalchemyrequiresmeditation) extends vanilla hud.ws's EHudVisibilitySource enum, and the merged output silently reverted the enum to vanilla while keeping the code that uses the new member. Enum members were the one mod-added content class gap-handling v2 (#27) didn't promote out of vanilla-wins gap territory (var/default/autobind were covered). The engine's audit trail even flagged the drop — "content from modalchemyrequiresmeditation near this position was not preserved" — it just had no better option than noting it.

Fix

A whole enum Name { ... } block is now one unit (ScriptUnitKind.EnumDeclaration, keyed enum:Name so it can never collide with a same-named function's identity). Per-member extraction isn't viable — members are bare identifiers, not statements — but whole-block units get everything needed: one side editing the enum takes that side's block; both sides editing goes through the standard per-unit 3-way merge (line-based merging composes distinct member additions cleanly) with the tiebreak as fallback; and the #33/#34 output invariants (presence/duplication) cover enum units with no extra work.

Validation

  • Real-data: vanilla + mod hud.ws both extract the enum as a unit, round-trip byte-exact, and HVS_Modcrab survives TryMerge.
  • 2 new tests (extractor unit shape + the engine add-a-member scenario); 158 total, green; format clean.
  • Live re-merge of hud.ws with this build posted below once run.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GXAuGMLB44T5Zv5o5ZzKah

… merges

Enum members were the one mod-added content class still living in gap
territory after gap-handling v2 (var/default/autobind were promoted;
enums weren't). Gap content reverts to vanilla on reassembly, so a mod
extending a vanilla enum had the new member silently dropped while the
code using it survived - "I dont know any 'HVS_Modcrab'", observed live
(modalchemyrequiresmeditation extends hud.ws's EHudVisibilitySource).
The merge's own audit note even flagged the loss ("content from
modalchemyrequiresmeditation near this position was not preserved").

A whole `enum Name { ... }` block is now ONE unit (per-member extraction
isn't viable - members are bare identifiers, not statements), keyed
"enum:Name" so it can't collide with a same-named function. One side
editing the enum takes that side's block; both sides editing goes through
the normal per-unit 3-way merge/tiebreak; the #33/#34 output invariants
cover enum units automatically.

Verified against the real hud.ws pair: enum extracted on both sides,
byte-exact round trips, HVS_Modcrab survives TryMerge. 2 new tests
(158 total).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GXAuGMLB44T5Zv5o5ZzKah
@TheValiantOne

Copy link
Copy Markdown
Owner Author

Live repair confirmed: pristine re-merge of hud.ws with this branch's build — HVS_Modcrab present in the merged EHudVisibilitySource enum definition (plus its usage), structural gate passes, inventory back to 41 records. 🤖

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant