Provide additional context in the DisallowedEmptyRule error message
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 35/100
Research direction
Start by locating the DisallowedEmptyRule implementation and the code that constructs its generic error message. Update the diagnostic so it includes the type passed to empty(), then verify that mixed-based cases can be targeted without broad path-based suppression.
Written by the indexing model from the issue text.
Description
In doctrine/dbal, the Schema and Driver APIs use array<string,mixed> parameters heavily (e.g. as connection parameters and column definitions).
While overall the value type is mixed, each array element usually has a certain type.
Since most of the array elements are optional, the boolean values are checked like this:
if (isset($field['unique']) && $field['unique']) {
// this is a unique column
}
Or like this:
if (empty($column['fixed'])) {
// this is a fixed-length column
}
Before reimplementing these APIs using objects with well-defined properties, I want to suppress the error reporting of such cases.
The first case is suppressed nicely like this:
-
message: '~^Only booleans are allowed.*mixed given~'
paths:
- %currentWorkingDirectory%/src/Driver/*/Driver.php
- %currentWorkingDirectory%/src/Platforms/*Platform.php
- %currentWorkingDirectory%/src/Schema/*SchemaManager.php
However, the second cannot be pin-pointed since the error message is generic for all cases:
Construct empty() is not allowed. Use more strict comparison.
I could rework expressions like empty($array[$key]) to isset($array[$key]) && $array[$key] and suppress them as above but I'd rather do the opposite since the empty() approach is more compact and has exactly the same meaning.
Would it be possible to include the type passed to empty() so that instead of whitelisting all such cases in certain paths, I could only whitelist the cases where a mixed like the above is passed?
- Dominant language
- PHP
- Stars
- 711
- Forks
- 62
- Avg merge
- 35m
- Merged PRs (30d)
- 4
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from phpstan/phpstan-strict-rules
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
phpstan/phpstan-strict-rules#317 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
phpstan/phpstan-strict-rules#316 · 3 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 52/100
phpstan/phpstan-strict-rules#298 · 2 comments · 1 reaction ·
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
phpstan/phpstan-strict-rules#289 · 1 comment ·
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 35/100
phpstan/phpstan-strict-rules#283 · 6 comments ·
All issues in phpstan/phpstan-strict-rules
Similar issues
-
sync-en
Difficulty 1/5 Under an hour Newbie friendliness 92/100
Maintainers usually reply within 1 day
-
sync-en
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 3 days
-
Form
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
symfony/symfony-docs#23159 ·
Maintainers usually reply within 3 days
-
bug component: bulk editor support
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Yoast/wordpress-seo#23669 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
php/frankenphp#2688 ·
Maintainers usually reply within 1 day