Update to PHPStan 2.2.14

composer update mglaman/phpstan-drupal phpstan/extension-installer phpstan/phpstan phpstan/phpstan-deprecation-rules phpstan/phpstan-phpunit

would update the whole bunch of PHPStan extensions

Merge conflict bc #3621275: Update Composer dependencies for 12.0.0-beta1 is in. (Gitlab UI strangely not showing even it says there's a conflict if I try to rebase.)

Also, do we need to wait on https://github.com/phpstan/phpstan/issues/15192?

Ran composer require "mglaman/phpstan-drupal":"^2.1.2" "phpstan/phpstan":"^2.2.13" --dev and regenerated baseline and got the same changes.

lgtm

That's a few baseline additions. Maybe we should combine this with #3425412: [mid-Oct 2026] Bump PHPStan rule level to 3?

IMHO if most of the baseline changes come from mglaman/phpstan-drupal we should split that out and review it separately so we can get the speed changes in without too much conflict.

Ok that's fine, I was just trying to avoid having two separate issues making large baseline changes to avoid conflicts, but happy to proceed.

Committed/pushed to main, thanks!

Moving to 11.x for backport.

No actually the commit never went through - three new errors introduced, I think we need a baseline update here again.

Went ahead and regenerated the baseline locally and committed.

Back to 11.x for backport again.

The is_file() warning is noisy, but it's not affecting the CI job pass and I saw a fix got committed for it already, we can update to the next patch release when it comes out.

Had to do the actual commit with --no-verify because phpcs didn't like having nothing to analyse.

#20 the bug upstream was fixed

https://github.com/phpstan/phpstan/issues/15192
https://github.com/phpstan/phpstan-src/pull/6397

It should be matter of days before a 2.2.14 will be out and we can bump to it.

PHPStan is failing on main with https://git.drupalcode.org/project/drupal/-/jobs/12129494

------ ---------------------------------------------------------------------- 
  Line   core/tests/Drupal/KernelTests/Core/Entity/EntityLanguageTestBase.php  
 ------ ---------------------------------------------------------------------- 
  68     A file could not be loaded from                                       
         Drupal\Core\Extension\ModuleHandlerInterface::loadInclude             
         🪪  loadIncludes.fileNotLoadable                                      
 ------ ---------------------------------------------------------------------- 

Passed with a re-run, not really sure what that means...

Yes I've just seen it again too - going to revert. Globally ignoring and then opening an issue (against phpstan probably) sounds good.

2.2.14 was released today

11.x has a failure in Drupal\Tests\Core\Test\WorkAllocatorTest::testAllocator which I don't know enough about and I am concentrating on other things right now.

11.x is fixed now - was an HEAD failure due to a test-only backport. Rebased and the 11.x is green.

So I think it is just the main MR to update now.

I forgot to comment that I updated the main branch. That was a few hours ago. But I rebased again, because why not?

Unless I am missing something, I do not see #28/#29 addressed. Or maybe it's no longer a problem?

The 11.x branch has https://git.drupalcode.org/project/drupal/-/merge_requests/17087/diffs?c... which looks like it should resolve it.

But I don't see that in the main commit.

Darn! Added an ignore with an @todo in phpstan.neon.dist

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

No, the diff applies.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

It feels weird that in main we need a global ignore, whereas in 11.x not? Is there a difference in the code analysed?

I checked the new baseline entries and it's mostly:

+$ignoreErrors[] = [
+	'message' => '#^Storing entity storage as a class property is not recommended\\. Call Drupal\\\\Core\\\\Entity\\\\EntityTypeManagerInterface\\:\\:getStorage\\(\\) at the call\\-site instead\\.$#',
+	'identifier' => 'drupal.entityStoragePropertyAssignment',
+	'count' => 1,
+	'path' => __DIR__ . '/modules/ckeditor5/src/Plugin/CKEditor5Plugin/MediaLibrary.php',
+];

This is something we should clean up so it's a valid new entry.

This all looks good to me now.

The 11.x branch had the ignore at least a couple of days ago, but my link to it is breaks the gitlab UI... https://git.drupalcode.org/project/drupal/-/merge_requests/17087/diffs?c...

Oh in 11.x they're individually added to the baseline, either that changed or I read it incorrectly:

$ignoreErrors[] = [
	'message' => '#^A file could not be loaded from Drupal\\\\Core\\\\Extension\\\\ModuleHandlerInterface\\:\\:loadInclude$#',
	'identifier' => 'loadIncludes.fileNotLoadable',
	'count' => 1,
	'path' => __DIR__ . '/tests/Drupal/KernelTests/Core/Entity/EntityLanguageTestBase.php',
];

I think we need to add the global ignore to 11.x too then. Leaving RTBC since we could probably change that as part of the backport.

In the 11.x MR mglaman/phpstan-drupal is bumped to 2.2.0, and it's only 2.1.2 on main. I think these two should probably be in sync as well? There's also a 2.2.1 release as of today, so it might be easier to bump both of them to that.

OK, bumped both MRs so they're in sync at mglaman/phpstan-drupal 2.2.1, and added the global ignore to 11.x.
This introduced some new baseline entries in the main MR. Also needed to manually update PinnedDevDependencies, since the builder was removed from main.

I re-reviewed all the changes except the baseline (which I did review a bit before the most recent update from @godotislate), I think this is ready to commit again.

I am still confused by the need to add a global ignore instead of adding to the baseline the actual errors - and for main only. To me it means the baseline would not be deterministic, and there would be random occasions where the error is reported and other not, which would be a primer in static analysis. Is that the case, can't we just add to the baseline as in 11.x?

@mondrake latest update to 11.x has the same global ignore, noted in #54.

@mondrake after the initial commit here we started to get seemingly random phpstan failures on various MRs, for example:

  Line   core/tests/Drupal/KernelTests/Core/Entity/EntityLanguageTestBase.php  
 ------ ---------------------------------------------------------------------- 
  68     A file could not be loaded from                                       
         Drupal\Core\Extension\ModuleHandlerInterface::loadInclude             
         🪪  loadIncludes.fileNotLoadable       

in https://git.drupalcode.org/project/drupal/-/jobs/12129494

Not every MR was affected but several were, iirc the errors were showing up in different tests on the MRs that failed too.

phpstan recently introduced a native PHP extension which is swapped in at runtime for child processes, maybe this (or something else new in this release) is struggling with includes - most modern PHP applications don't dynamically include files outside of autoloading, so it would be quite possible that what is for us a backwards compatibility layer is the only, or at least first, code that's hitting the bug.

#3624168: Fix loadIncludes.fileNotLoadable phpstan violations is open to look into this more, and we can try removing the global ignore there, see if we can get an MR run to fail. We could also try an experiment and remove the global ignore in HEAD too via that issue if that will help track down the problem and we can't reproduce on MR runs. But what I really don't want to do is introduce 80% random test failures when we're desperately trying to tag the beta alongside having dozens of RTBC issues in the queue.

Sure, thanks for explaining!

Needs a reroll after #3595089: Remove the Olivero theme

Both MRs rerolled and main baseline regenerated.

Committed to main and 11.x - thanks!