fix: migration faithfulness follow-ups (generator byte-drift + null-tolerance)#1446
Draft
joaodinissf wants to merge 2 commits into
Draft
fix: migration faithfulness follow-ups (generator byte-drift + null-tolerance)#1446joaodinissf wants to merge 2 commits into
joaodinissf wants to merge 2 commits into
Conversation
… terminals in AnnotationAwareContentAssistFragment2 The migration generated the proposal-provider via single-arg appends; when an assignment's terminal is a multi-line Alternatives, the continuation lines lost their indentation versus the Xtend-generated output (xtend-gen uses two-arg append(value, indent) which re-indents every continuation line). Restore the Xtend relative + two-arg-reindent pattern in the content/handleAssignment/ handleAssignmentOptions builders. Byte-identity verified against xtend-gen via an executable StringConcatenation harness across 10 input shapes (empty / single & multi-line leaf / options / keywords / stub & non-stub / combined): 7/10 -> 10/10 IDENTICAL. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…cher throws The synthesized @dispatch fall-through throws built the unhandled-parameter message with List.of(...), which is null-intolerant (NPE on a null element), whereas the Xtend-generated code used Arrays.<Object>asList(...).toString(). On the defensive null path (e.g. infer(null, ...)) the migrated code threw NullPointerException instead of the original IllegalArgumentException. Restore the null-tolerant Arrays.<Object>asList, matching xtend-gen. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Context
Follow-up to the Xtend→Java migration campaign. After the migrations merged, every migrated file was audited for generated-output byte-drift (where a code generator's emitted text must be byte-identical to what Xtend produced) and general faithfulness. The audit compared each migrated
.javaagainst the authoritativextend-gen(the Xtend compiler's own output), with executableStringConcatenationharnesses for the non-trivial generators. This PR carries the two generator-code fixes that surfaced; both are verified byte-identical / behaviour-faithful toxtend-gen.Fixes
1.
AnnotationAwareContentAssistFragment2— restore continuation-line indentationThe generated
Abstract…ProposalProviderwas built with single-argappend(value); when an assignment's terminal is a multi-lineAlternatives, the continuation lines lost their indentation versus the Xtend output (Xtend uses two-argappend(value, indent), which re-indents every continuation line). Restored the Xtext relative + two-arg-reindent pattern.Verification: an executable
StringConcatenationharness ran both thextend-genbuilder and the migrated builder over 10 input shapes (empty / single- & multi-line leaf / options / keywords / stub & non-stub / combined): 7/10 → 10/10 IDENTICAL after the fix.2.
FormatJvmModelInferrer— null-tolerantArrays.asListin dispatcher throwsThe synthesized
@Dispatchfall-through throws built the "Unhandled parameter types" message withList.of(...), which throwsNullPointerExceptionon a null element; the Xtend-generated code usedArrays.<Object>asList(...).toString()(null-tolerant). On a defensive null path this changed the thrown exception type. RestoredArrays.<Object>asList, matchingxtend-gen.Two additional minor observations (intentionally not changed here)
CheckCfgScopeProviderTest: the migration replaced an explicitnew NullPointerException("Got null context model")withnew IllegalStateException(...)(same message, same test outcome). Kept as-is — an explicitIllegalStateExceptionis preferable to throwingNullPointerException; reverting purely for byte-faithfulness would be a small quality regression.CheckModelUtil.modelWithContexts(test helper): emits a trailing"\n "the Xtend«FOR»did not. Its only caller is an@Disabledtest, so it is never exercised; deferred to avoid churn.🤖 Generated with Claude Code