- Issue created by @jweowu
I recently submitted a patch 🐛 Identifiers longer than 63 characters are truncated, causing Views to break on Postgres Needs work for which the testbot didn't even run the main tests, because it bailed out early with Custom Commands Failed → when PHPStan complained about a piece of code in one of the patched files which was not relevant to the patch!
That left me in a position of trying to analyse something entirely tangential, solely in an attempt to get it to test my actual changes, and then submitting a new version of the patch which contains additional changes which have no business being there.
(I considered whether I had introduced the situation it was complaining about, but I do not believe that to be the case. The complaint was that a variable $alias which was being tested with isset() could never be NULL, but the only changes to that code in my patch were to pass $alias through a new function which, when given a NULL argument would return that same NULL value. My patch therefore has no effect on a NULL $alias, and so if that variable can never be NULL post-patch, it must also be the case that it could never be NULL pre-patch.)
I can't add anything else here -- I have only example case described above. (I'm just assuming the odds of it being isolated are pretty much nil.)
PHPStan has a feature it refers to as a Baseline which "allows you to declare the currently reported list of errors as “the baseline” and cause it [not to report them] in subsequent runs. It allows you to be interested in violations only in new and changed code."
It would be good if this were employed so that pre-existing complaints (a) could all be collected and addressed in their own issue, and (b) those complaints did not trip up unrelated patches.
?
?
?
?
Active
Testrunner Codebase