Fix file path of trait errors reported directly in the trait

[janedbal]

Fixes phpstan/phpstan#14718.

Problem

Since 2.2.0, an error originating inside a trait that is collapsed into a single error and reported once directly in the trait (via the new ConstantConditionInTraitRule → Error::removeTraitContext() path) ends up with an inconsistent file pair:

• getFile() → the trait file (correct)
• getFilePath() → the using class's file (stale)
• getTraitFilePath() → null

removeTraitContext() moved file onto the trait file but left filePath pointing at the using-class file. Two things break as a result:

1. Inline @phpstan-ignore no longer suppresses the error (the regression reported in #14718). AnalyserResultFinalizer looks up line-ignores by getFilePath(), which points at the using-class file, so the ignore registered for the trait never matches.
2. The editorUrl link points at the wrong file. TableErrorFormatter builds it from getTraitFilePath() ?? getFilePath() → null ?? <using-class file>, i.e. the using-class file glued to the trait's line number.

Both worked correctly in 2.1.x.

Fix

Make filePath follow file onto the trait file in removeTraitContext(), the same way changeFilePath() keeps file and filePath in sync. One line.

Verification

Minimal reproduction: https://github.com/janedbal/phpstan-bug-14718-repro

Before (2.2.0): error reported despite the inline ignore, editor link → using-class file.
After: getFile() === getFilePath() === <trait file>, getTraitFilePath() === null.

Added a unit test in ErrorTest covering removeTraitContext().

Co-Authored-By: Claude Code

[ondrejmirtes]

Would be nice to have the repro repo here in e2e/ and e2e-tests, showing all the behaviour described in the issue - non-working ignore comment, impossible baseline generation, problem disappearing with primed result cache etc.

[janedbal]

Added e2e/bug-14718 + an e2e-tests job. The fixture is a trait used by two classes, with the deduplicated identical.alwaysFalse error reported directly in the trait. The job asserts, on the fixed build:

• an inline // @phpstan-ignore on that error suppresses it (exit 0) — and stays suppressed with a primed result cache (the run is repeated without clearing);
• with the ignore removed, the error is reported in the trait file, and --generate-baseline writes path: src/FooTrait.php (the trait file), not the using-class file.

For comparison, reverting the one-line fix flips all of these: the ignore is skipped, the editor URL / baseline path point at the using-class file (src/Foo.php).

One honest caveat: I could not reproduce the "error disappears on the second (primed-cache) run" facet in this minimal two-file fixture — it's deterministic across cache states here, so I didn't encode an assertion for it. That facet looks like it depends on the ConstantConditionInTraitRule dedup count() being sensitive to which files' collected data is restored from cache, which may need a larger setup (or be a separate concern). Happy to dig further or restructure the fixture if you have a setup in mind that triggers it.

Standalone repro repo (same case): https://github.com/janedbal/phpstan-bug-14718-repro

---

Note: (Claude anwering)

[ondrejmirtes]

Superb, please fix the build and mark it as ready.

[phpstan-bot]

This pull request has been marked as ready for review.

[ondrejmirtes]

Isn't this a BC break? The ignore work correctly before. It's a bit awkward, but for errors reported in traits, I think on current stable version, both the trait or the class path can be used in path in ignoreErrors.

[ondrejmirtes]

This is achieved here:

phpstan-src/src/Analyser/Ignore/IgnoredErrorHelperResult.php

Lines 158 to 187 in 04d314d

	$filePath = $this->fileHelper->normalizePath($error->getFilePath());
	if (isset($this->ignoreErrorsByFile[$filePath])) {
	foreach ($this->ignoreErrorsByFile[$filePath] as $ignoreError) {
	$i = $ignoreError['index'];
	$ignore = $ignoreError['ignoreError'];
	$result = $processIgnoreError($error, $i, $ignore);
	if (!$result) {
	unset($errors[$errorIndex]);
	$ignoredErrors[] = [$error, $ignore];
	continue 2;
	}
	}
	}
	$traitFilePath = $error->getTraitFilePath();
	if ($traitFilePath !== null) {
	$normalizedTraitFilePath = $this->fileHelper->normalizePath($traitFilePath);
	if (isset($this->ignoreErrorsByFile[$normalizedTraitFilePath])) {
	foreach ($this->ignoreErrorsByFile[$normalizedTraitFilePath] as $ignoreError) {
	$i = $ignoreError['index'];
	$ignore = $ignoreError['ignoreError'];
	$result = $processIgnoreError($error, $i, $ignore);
	if (!$result) {
	unset($errors[$errorIndex]);
	$ignoredErrors[] = [$error, $ignore];
	continue 2;
	}
	}
	}
	}

I suspect, wouldn't be a better place to fix this in FileAnalyser where @phpstan-ignore are processed?

[janedbal]

You're right that the previous commit was a BC break — overwriting filePath with the trait path made ignoreErrors/baseline entries keyed on the using-class path stop matching (the relocated self-analysis baseline entry was the tell).

New approach, pushed: removeTraitContext() now keeps traitFilePath instead of nulling it, and leaves filePath as the using-class file. So:

• the editor URL resolves to the trait via getTraitFilePath();
• IgnoredErrorHelperResult keeps matching both the using-class path and the trait path (the L158-187 dual lookup you linked) — no existing ignore/baseline breaks;
• the self-analysis baseline relocation is reverted.

On your FileAnalyser suggestion: for these specific errors the inline @phpstan-ignore isn't processed in FileAnalyser — they're collector errors from ConstantConditionInTraitRule, deduplicated and finalized in AnalyserResultFinalizer, which is where the local-ignore lookup happens. The bug was that it picked the ignore bucket by getFilePath() (using-class) while the comment lives in the trait file, so I fixed it there by selecting the bucket with getTraitFilePath() ?? getFilePath(). Happy to move it if you had a different spot in mind.

The e2e now asserts both the trait-path and using-class-path ignoreErrors suppress the error, plus a clean --generate-baseline round-trip, across empty and primed result cache.

Note: (Claude answering)