Language: PHP
Rule: php:S1124 — “Modifiers should be declared in the correct order”
Why it’s a false positive: The rule expects modifier order final/abstract → public/protected/private → static, per PSR2. It incorrectly flags public private(set) as misordered classic visibility modifiers. In reality this is PHP 8.4’s asymmetric visibility syntax — a single combined modifier, not two classic ones. public private(set) $x means publicly readable, privately writable: the property can be read from anywhere, but only modified from within the declaring class. This idiom is recommended for protecting a mutable object’s state without writing accessor boilerplate.
The parser doesn’t seem to recognize this syntax. Parsing support for PHP 8.4 asymmetric visibility was added in SONARPHP-1584 / PR #1335 (merged Dec 2024), but rule S1124 doesn’t appear to have been updated to recognize it as valid.
Impact: Any PHP 8.4+ project using this idiom will hit this false positive.
Current workaround: Manually marking each occurrence as “false positive” on our end.
Environment:
- SonarQube Server — version v2026.1.2
- Sonar Scanner CLI — version 12.1
- Analysis runs server-side during GitLab MR pipelines (not via SonarQube for IDE)
Reproduction snippet:
<?php
class ScopeEntity
{
public private(set) string $contentType;
}
Analysis flags:
Reorder the modifiers to comply with the PSR2 standard.