Skip to content

Format fingerprints change on identical reloads and trigger dependent rebuilds #1534

Description

@joaodinissf

Saving a byte-identical .format file changes its exported fingerprints and unnecessarily rebuilds dependent formats. FormatResourceDescriptionStrategy includes obj.eContainer().toString() in the fingerprint; the EMF object's Java identity changes when the resource is reloaded.

Reproducer

The public fixture adds tests to otherwise unchanged production code at master bd137db11. It uses public Xtext grammars and a temporary Eclipse project; no private project is needed.

Use JDK 21 and Maven. Extract the ZIP, enter its root directory, then run:

git init
git add .
git -c commit.gpgsign=false -c user.name=Reproducer -c user.email=reproducer@example.invalid commit -m "Initialize reproducer"
mvn integration-test -f ddk-parent/pom.xml --batch-mode --fail-at-end

On Linux, prefix Maven with xvfb-run. macOS uses the repository's existing SWT profile. Initializing Git is required by Tycho's qualifier calculation. integration-test executes the normal test aggregator without release-baseline verification, which requires the original Git history. Do not select the Format suite with -Dtest: that can skip the aggregator entirely.

Verified from a fresh archive extraction on macOS with JDK 21. The project builds without error markers, then saving unchanged Xtype.format yields an index event containing both Xtype.format and its dependent Xbase.format. The assertion fails with:

identical save must not rebuild descendants: [Xtype.format, Xbase.format]

Event ordering can vary. The full extracted run reported seven expected Format assertion failures and, separately, a SWTBot CheckQuickfixTest.testBulkApplyingQuickfix dialog timeout; that timeout is not part of this reproducer. Focused description tests also demonstrate unstable identical LF/CRLF reloads and missing configuration/inheritance fingerprints.

Expected behavior and fix constraints

Byte-identical reloads should keep exports stable. Genuine changes must still propagate through a base → child → grandchild chain, including a child without local declarations. Incremental generated Java and trace bytes should match a full build after constant edits, rule edits, declarations added/renamed/removed, and inherited comment/line-ending changes.

Replacing object identity with a stable URI alone is insufficient: unchanged descendants then stop advertising inherited changes. In an earlier experiment this left grandchild Java and inherited source locations stale until a full build. A fix needs stable configuration fingerprints that include inherited source information, with termination for cycles and unresolved bases. The focused inheritance fixtures connect parsed models directly; the separate workspace fixture exercises actual indexing, linking and generation.

Scope

An earlier DDK 19.1 experiment likewise reindexed a base and child after an identical save and emitted change events for four unchanged Java/trace files. That workspace settled when idle. This reproducer demonstrates unnecessary rebuild propagation; it does not establish the cause of an endless Windows build loop.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions