SONARPHP-1660,SONARPHP-1933 S1172 Fix FP with Laravel implicit route model binding

[lijun-chen-sonarsource]

Several user feedback from the rule-feedback-dashboard state that S1172 is not applicable in some Laravel-specific methods.

In some cases, it is possible for users to rename the parameters to $_ so that we don't raise S1172. This work focuses on cases where this escape hatch is not possible.

Do not report unused model parameters that are likely consumed by
Laravel's implicit route model binding, where parameter names have to
correspond to route placeholders for it to work.
Detect also asController and handle methods from Laravel Actions
and suppress model-like parameters also there.

Use local heuristics instead of collecting route registrations. This
avoids extending project-level symbol data and the complexity of resolving
dynamic PHP route declarations, while keeping detection consistent
between normal (full) analysis and SQ IDE.

---

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}

[hashicorp-vault-sonar-prod]

SONARPHP-1933

[asya-vorobeva]

👍

[gitar-bot]

Code Review ✅ No issues found 1 closed / 1 findings

🟡 Medium risk · Adds Laravel-specific parameter suppression heuristics across PHP analysis paths

Fixes false positives in S1172 for Laravel implicit route model binding by using local heuristics to detect parameters consumed by Laravel's magic routing, addressing trait detection to properly recognize inherited traits in addition to declaring classes.

✅ 1 closed

✅ Edge Case: Trait detection only looks at the declaring class, not inherited traits

📄 php-checks/src/main/java/org/sonar/php/checks/UnusedFunctionParametersCheck.java:290 📄 php-checks/src/main/java/org/sonar/php/checks/UnusedFunctionParametersCheck.java:293-301 📄 php-checks/src/test/resources/checks/UnusedFunctionParametersCheckLaravelActions.php:127-141
usesLaravelActionTrait only looks at use statements declared directly in the method's class. If AsAction/AsController comes from a parent class (for example abstract class BaseAction { use AsAction; } in App\Support), a subclass's handle(Account $account) is still reported unless some ancestor sits in a namespace containing \actions\. The InheritedAccountHandler test says the action role is inherited from a parent class, but it only passes because BaseAction is in App\Actions. The namespace heuristic is what matches, not the inherited trait. A fix is to walk Symbols.get(owner).allSuperTypes() and check each ancestor's trait usage, or else change the test comment and add a case where the base class is outside an Actions namespace.

Review coverage

🧪 Functional validation No results

📋 Rules No rules evaluated

🤖 Auto-approval Not enabled · Set up

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
1 Fixed issue
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
94.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube