fix(refactoring): add ignoreCompileErrors escape hatch for compile-error blocks #100

Merged

hauschel.fred merged 1 commit from fix/75-force-compile-errors into main

2026-09-07 21:38:29 +00:00

hauschel.fred commented

2026-09-07 21:34:09 +00:00

Collaborator

Summary

jdt_encapsulate_field hard-blocks with no way to proceed when JDT's
SelfEncapsulateFieldRefactoring reports a pre-existing compile error while
analyzing the field. Eclipse shows a "Continue anyway?" dialog for this;
headless mode has no equivalent, so the refactoring was simply stuck.

RefactoringSupport.getRealErrors() gains an ignoreCompileErrors overload
that filters status entries matching JDT's "compile error" wording.
jdt_encapsulate_field and jdt_rename_element expose it as an optional
parameter (default false).
Blocked responses name the flag and the JDT finding, never null/NPE.
If forcing genuinely cannot help (e.g. the field's own type does not
resolve), the result reports that honestly instead of a false SUCCESS.

Deliberately excludes "syntax error" (Checks.checkIfCuBroken) from the
ignorable markers: bypassing that specific JDT safety check left
ProcessorBasedRefactoring's participant machinery uninitialized and later
steps threw a raw NullPointerException instead of a clean status — a
structurally unparseable file cannot be safely forced through with the
current JDT version. Investigated and confirmed via bytecode inspection of
org.eclipse.jdt.core.manipulation (Checks.checkCompileErrorsInAffectedFile(s),
SelfEncapsulateFieldRefactoring, Checks.checkIfCuBroken) plus empirical
reproduction against fixture-broken.

Test plan

New E2E case in tests/refactoring-test.sh (Test 4): blocked without
the flag (self-explanatory message), honest error (no false SUCCESS,
no NPE) when forced on a field whose type cannot resolve.
tests/refactoring-test.sh full suite: 6/6 passed.
tests/smoke-test.sh: 9/9 passed.
mvn clean package product build.

Closes #75

🤖 Generated with Claude Code

https://claude.ai/code/session_018q6miiQHwQYFgZBy71aUhL

## Summary `jdt_encapsulate_field` hard-blocks with no way to proceed when JDT's `SelfEncapsulateFieldRefactoring` reports a pre-existing compile error while analyzing the field. Eclipse shows a "Continue anyway?" dialog for this; headless mode has no equivalent, so the refactoring was simply stuck. - `RefactoringSupport.getRealErrors()` gains an `ignoreCompileErrors` overload that filters status entries matching JDT's "compile error" wording. - `jdt_encapsulate_field` and `jdt_rename_element` expose it as an optional parameter (default `false`). - Blocked responses name the flag and the JDT finding, never `null`/NPE. - If forcing genuinely cannot help (e.g. the field's own type does not resolve), the result reports that honestly instead of a false `SUCCESS`. **Deliberately excludes** "syntax error" (`Checks.checkIfCuBroken`) from the ignorable markers: bypassing that specific JDT safety check left `ProcessorBasedRefactoring`'s participant machinery uninitialized and later steps threw a raw `NullPointerException` instead of a clean status — a structurally unparseable file cannot be safely forced through with the current JDT version. Investigated and confirmed via bytecode inspection of `org.eclipse.jdt.core.manipulation` (`Checks.checkCompileErrorsInAffectedFile(s)`, `SelfEncapsulateFieldRefactoring`, `Checks.checkIfCuBroken`) plus empirical reproduction against `fixture-broken`. ## Test plan - [x] New E2E case in `tests/refactoring-test.sh` (Test 4): blocked without the flag (self-explanatory message), honest error (no false SUCCESS, no NPE) when forced on a field whose type cannot resolve. - [x] `tests/refactoring-test.sh` full suite: 6/6 passed. - [x] `tests/smoke-test.sh`: 9/9 passed. - [x] `mvn clean package` product build. Closes #75 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_018q6miiQHwQYFgZBy71aUhL

hauschel.fred added 1 commit

2026-09-07 21:34:09 +00:00

fix(refactoring): add ignoreCompileErrors escape hatch for compile-error blocks 895783d937

jdt_encapsulate_field hard-blocks with no way to proceed when JDT's
SelfEncapsulateFieldRefactoring reports a pre-existing compile error while
analyzing the field (Checks addFatalError) — Eclipse shows a "Continue
anyway?" dialog for this, which headless mode has no equivalent for.
RefactoringSupport.getRealErrors() gains an ignoreCompileErrors overload that
filters findings matching JDT's "compile error" wording; jdt_encapsulate_field
and jdt_rename_element expose it as an optional parameter (default false).
Blocked responses now name the flag and the JDT finding; if forcing genuinely
cannot help (e.g. the field's own type does not resolve), the result reports
that honestly instead of a false SUCCESS or a bare NullPointerException.

Deliberately excludes "syntax error" (Checks.checkIfCuBroken) from the
ignorable markers: bypassing that specific JDT safety check left
ProcessorBasedRefactoring's participant machinery uninitialized and later
steps threw a raw NullPointerException instead of a clean status — a
structurally unparseable file cannot be safely forced through with the
current JDT version.

Closes #75

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

hauschel.fred merged commit a70e0b0b04 into main

2026-09-07 21:38:29 +00:00

hauschel.fred referenced this pull request from a commit

2026-09-07 21:38:29 +00:00

Merge pull request 'fix(refactoring): add ignoreCompileErrors escape hatch for compile-error blocks' (#100) from fix/75-force-compile-errors into main

hauschel.fred referenced this pull request

2026-09-07 21:45:15 +00:00

Upstream-Meldungen an Eclipse JDT für die in v1.1.0 umgangenen Headless-Bugs #103

Commenting is not possible because the repository is archived.

No reviewers