Do not treat lines spanned by attributes as executable

[Slamdunk]

Fix #1148

Beware the targeted branch is 12.5, so releases are needed also for 13 and 14 branches.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.21%. Comparing base (e70f9f8) to head (22adabf).
⚠️ Report is 1 commits behind head on 12.5.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff            @@
##               12.5    #1149   +/-   ##
=========================================
  Coverage     88.21%   88.21%           
- Complexity     1400     1401    +1     
=========================================
  Files           105      105           
  Lines          4718     4719    +1     
=========================================
+ Hits           4162     4163    +1     
  Misses          556      556           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[sebastianbergmann]

The proposed changes mark every line spanned by an attribute as non-executable. This makes sense to me and I will merge these changes.

This does not really explain the --processes=1 vs --processes=16 discrepancy, though. That smells like a static-analysis cache / merge-path difference where single-process likely hit a cached/short-circuit path that skipped attributes, while parallel runs went through the visitor. Once attributes are unconditionally unset, both paths converge, so the user-visible bug should disappear even though the underlying merging asymmetry isn't touched.

[sebastianbergmann]

releases are needed also for 13 and 14 branches

I have released phpunit/php-code-coverage 12.5.5 and phpunit/php-code-coverage 14.1.1 with this fix, but there will be no more releases for the 13.x version series.

[Slamdunk]

This does not really explain the --processes=1 vs --processes=16 discrepancy, though. That smells like a static-analysis cache / merge-path difference where single-process likely hit a cached/short-circuit path that skipped attributes, while parallel runs went through the visitor. Once attributes are unconditionally unset, both paths converge, so the user-visible bug should disappear even though the underlying merging asymmetry isn't touched.

Yeah: one process lets PHP decide the executable lines of MyClassWithAttributes because it uses it, while the other process has to leverage ExecutableLinesFindingVisitor because it doesn't use it.