Problem

When PHPUnit handles deprecation warnings during test execution, the ErrorHandler uses SourceMapper to determine whether the deprecation was triggered in first-party code or third-party code (self, direct, or indirect). This identification currently requires scanning the configured <source> directories to build a list of first-party files.

As reported in #6111 and #6469, this file scanning operation can cause significant performance degradation, especially when:

• The <source> include/exclude patterns are overly broad
• The configured source directories contain many files
• Many deprecation warnings are triggered during a test run

Proposed Solution

Add a new identifyIssueTrigger boolean attribute to the <source> element in phpunit.xml. This attribute defaults to true (preserving current behaviour), but can be set to false to disable the trigger identification feature entirely.

When disabled:

• PHPUnit skips the expensive file scanning operations in the error handler
• Deprecations are still reported, but with an "unknown" trigger origin instead of being classified as "self", "direct", or "indirect"
• Test execution performance is significantly improved for large codebases

Configuration Example

<source identifyIssueTrigger="false">
    <include>
        <directory>src</directory>
    </include>
</source>

Trade-offs

When identifyIssueTrigger="false" is set:

• The ignoreSelfDeprecations, ignoreDirectDeprecations, and ignoreIndirectDeprecations options will not function correctly since they depend on trigger identification
• PHPUnit will emit a warning if trigger identification is disabled while any of these ignore options are enabled
• Deprecation reports will show "unknown if issue was triggered in first-party code or third-party code" instead of the specific classification

Use Cases

This option is intended for users who:

1. Have large codebases where source scanning is expensive
2. Don't need the self/direct/indirect classification of deprecations
3. Want to optimize CI/CD pipeline execution time
4. Are willing to accept less detailed deprecation reporting in exchange for faster test runs