PHPStan Blog

Restricted Usage Extensions - You Don't Always Need a Custom Rule

2025-04-27T00:00:00Z

Recently I’ve wanted to implement support for the @internal PHPDoc tag. The good news was there was already a similar set of rules in phpstan-deprecation-rules for the @deprecated tag. The bad news was the logic around @deprecated was hardcoded there, meaning I’d have to copy and adjust all the rules.

I thought there should be a better way because this is a very common use-case and not everyone should be forced to reinvent the same wheel. If people have a need for rules around attributes like #[NamespaceVisibility] or #[Friend], it should not be their job to figure out all the rules needed for a comprehensive coverage of these restrictions.

Take methods for example: Everyone would implement a rule for a traditional method call like $foo->doBar(1, 2, 3), but only a few would remember that first-class callables like $foo->doBar(...) should be covered as well.

Or class names. The new extension currently covers 26 locations where a class name can occur in PHP code or PHPDocs. The great advantage of the extension interface is that it’s future-proof and we can call it as new places with class names appear in the PHP language or as we add new PHPDoc features.

Besides taking advantage of the new extensions to implement the @internal tag rules, I went back to phpstan-deprecation-rules and refactored it with these new capabilities. It fixed small inconsistencies like missing class name check for static property fetch, wrong class names in some error messages, or reported line numbers in multi-line function signatures. With bleeding edge enabled, it will report deprecated class names in more places.

The Restricted Usage Extensions were released in PHPStan 2.1.13. Head over to the developer guide to learn how to use them!

Do you like PHPStan and use it every day? Consider supporting further development of PHPStan. I’d really appreciate it!

PHPStan 2.1: Support For PHP 8.4's Property Hooks, and More!

2024-12-31T00:00:00Z

This release is a culmination of the last four months of my work. Beginning in September, I branched 2.0.x off of 1.12.x. In order to support PHP 8.4 syntax, I had to upgrade to PHP-Parser v5. In order to upgrade to PHP-Parser v5, I had to release PHPStan 2.0. Which I did on November 11th, alongside the cute and also long-awaited PHPStan elephpant. PHPStan’s fans ordered 750 of those! They will be manufactured in China and sent on a ship to Europe which is going to take some time. I hope they’re going to find themselves in the hands of their happy owners in May-June 2025, as promised in the order confirmation emails.

Today’s PHPStan 2.1 brings full understanding of flagship PHP 8.4 features like property hooks, asymmetric visibility, and the #[Deprecated] attribute. As usual I’m going to describe what considerations went into supporting these language features in PHPStan.

Property hooks #

This is a massive and complex new language feature which is obvious just by looking at the length of the RFC. After reading it I wrote down about 70-80 todos about what should be done in PHPStan’s codebase in order to properly support it 😅 Out of those there are still around 32 todos left. They are not necessary enough to be included in this initial release, but it’d be nice to have them.

In short, property hooks let you intercept reading and writing properties with your own code. They also allow properties to be declared on interfaces for the first time in PHP. You can have virtual properties without a backing value stored in the object. And last but not least, hook bodies can be written with either long or short syntax.

Property hooks are very similar to class methods, but they are also their own thing. Which means I had to adjust or replicate a lot of existing rules around methods:

Additionally, there are new special rules for property hooks:

Backing value of non-virtual property must be read in get hook
Backing value of non-virtual property must be always assigned in set hook

Set hook parameter type can be wider than the actual property type so PHPStan also has to be aware of the types it allows to assign to properties in and out of hooks:

class Foo
{
	public int $i {
		get {
			return $this->i - 10;
		}
		set (int|string $value) {
			$this->i = $value; // string not allowed
		}
	}
}

$f = new Foo();
$f->i = rand(0,1) ? '10' : 'foo'; // string allowed

Property hooks also bring properties that can only be read, or can only be written, to the language:

interface Foo
{
	public int $i { get; }
	public int $j { set; }
}

function (Foo $f): void {
	$f->i = 42; // invalid
	echo $f->j; // invalid	
};

And my final remark is that access to properties can now be expected to throw any exception:

interface Foo
{
	public int $i { get; }
}

function (Foo $f): void {
	try {
		echo $f->i;
	} catch (MyCustomException) { // dead catch on PHP 8.3-, but not on 8.4+
		
	}
};

Even non-hooked properties are subject to this, because they can be overwritten in a subclass with a hook. If you want to persuade PHPStan that access to your properties cannot throw exceptions, make them private or final.

Hooks can be documented with @throws PHPDoc tag which improves analysis of try-catch blocks, same as with functions and methods.

I also posted a community update which goes into depth what you should do if you want to support property hooks in your custom rules.

A huge thanks to Jarda Hanslík for initial property hooks support in BetterReflection, and for many many subsequent fixes for bugs I found 😅

And also a huge thanks to Nikita Popov, not just for his work on PHP-Parser in general, but also for merging a couple of fixes I made, and also for fixing a couple of other issues I reported.

Asymmetric visibility #

PHP now allows for different properties visibility when reading then and when assigning them. So property can for example be publicly readable, but only privately writable.

This feature is much easier to grasp than property hooks, but also comes with a few gotchas.

Property that’s public-readable or protected-readable, but only privately writable, is implicitly final and cannot be overridden.
Acquiring reference to a property follows write visibility, not read visibility, so I added a new rule for that.

Similarly to property hooks, I also have a few nice-to-have todos left for later.

`#[Deprecated]` attribute #

This attribute allows the PHP engine trigger deprecated warnings.

I suspect it’s not that useful in practice because it’s allowed only above functions, methods, and class constants. Most notably, it can’t be used to mark entire classes deprecated. It also does not work for properties. This is something that PHP could address in the future.

Nevertheless, you can use it in PHPStan 2.1 in tandem with phpstan-deprecation-rules to mark deprecated code and have it reported when used.

Do you like PHPStan and use it every day? Consider sponsoring further development of PHPStan on GitHub Sponsors and also subscribe to PHPStan Pro! I’d really appreciate it!

PHPStan 2.0 Released With Level 10 and Elephpants!

2024-11-11T00:00:00Z

PHPStan 1.0 was released a little over three years ago. I’m happy to report the project is thriving! We did about 176 new releases since then, implementing new features, fixing bugs, and laying the groundwork for 2.0. Yeah, we didn’t catch a break and we didn’t rest on our laurels.

I’ve been looking forward to 2.0 for a long time. Everyone will finally be able to enjoy new features we’ve been working on. Some of them have already been enjoyed by early adopters for more than two years.

But code and analysis changes are not the only things being released today! PHPStan joins the family of elephpants with its own take on the legendary PHP mascot.

You can also order PHPStan T-shirts again, in both blue and white, and straight/fitted cut:

We’re accepting orders for the next four weeks (until Sunday, December 8th), so don’t miss the opportunity and order the elephpant and T-shirt today! I can’t wait to see them in the wild.

And now to the code part. The comprehensive release notes are massive, consisting of over 180 items. That’s why, for the first time ever, PHPStan 2.0 also comes with easy-to-follow upgrading guide, for both end users and extension developers.

It’s really hard to pick and choose my favourite features and changes from 2.0, but I’ll try. Here we go:

Level 10 #

New challenge for the level max enthusiasts! Previously added level 9 acknowledges using mixed in your code isn’t actually safe at all, and that you should really do something about it. But it has some blind spots and still lets some errors through. Internally it’s named checkExplicitMixed. Meaning it will report errors for explicitly-typed mixed values in your code.

Level 6 forces you to add missing types. If you manage to skip that with the help of ~~cheating~~, ahem, the baseline, or if you call a third party code that doesn’t use a lot of return types, unknown types may be present in your code during analysis. These are implicitly-typed mixed, and they will be picked up by level 10

List type #

PHP arrays are really powerful, but they represent several computer science concepts in a single data structure, and sometimes it’s difficult to work with that. That’s why it’s useful to narrow it down when we’re sure we only want a single concept like a list.

List in PHPStan is an array with sequential integer keys starting at 0 and with no gaps. It joins many other advanced types expressible in PHPDocs:

/** @param list<int> $listOfIntegers */
public function doFoo(array $listOfIntegers): void
{
}

Lower memory consumption leads to faster performance #

PHPStan used to be a really hungry beast. To the point of being killed by CI runners because it consumed not just all the memory up to the memory_limit in php.ini, but also all the memory assigned to the runner hardware.

Now it’s a less hungry beast. How did I make it happen? It’s useful to realize what’s going on inside a running program. It’s fine to consume memory as useful things are being achieved, but in order to consume less memory in total, it has to be freed afterwards so that it can be used again by different data needed when analysing the next file in line.

To debug memory leaks, I use the php-meminfo extension. I quickly realized that most of the memory is occupied by AST nodes. PHP frees the memory occupied by an object when there are no more references to it ^[1]. It didn’t work in case of AST nodes because they kept pointing at each other:

Getting rid of parent/previous/next node attributes is a backward compatibility break for custom rules that read them. I’ve written an article on how to make these rules work again even without those memory-consuming references.

The object graph is now obviously cleaner and with no reference cycles:

In my testing PHPStan now consumes around 50–70 % less memory on huge projects with thousands of files. Analysing PrestaShop 8.0 codebase now takes 3 minutes instead of 9 minutes in GitHub Actions with 2 CPU cores.

Validate inline PHPDoc `@var` tag type #

There are multiple problems with inline @var PHPDoc tag. PHP developers use it for two main reasons:

To fix wrong 3rd party PHPDocs. A dependency ^[2] might have @return string in a PHPDoc but in reality can return null as well.
To narrow down the returned type. When a function returns string|null but we know that in this case it can only return string.

/** @var Something $a */
$a = makeSomething();

By looking at the analysed code we can’t really tell which scenario it is. That’s why PHPStan always trusted the type in @var and didn’t report any possible mistakes. Obviously that’s dangerous because the type in @var can get out of sync and be wrong really easily. But I came up with an idea what we could report without any false positives, keeping existing use-cases in mind.

PHPStan 2.0 validates the inline @var tag type against the native type of the assigned expression. It finds the lies spread around in @var tags:

function doFoo(): string
{
    // ...
}

/** @var string|null $a */
$a = doFoo();

// PHPDoc tag @var with type string|null is not subtype of native type string.

It doesn’t make sense to allow string|null, because the type can never be null. PHPStan says “string|null is not subtype of native type string”, implying that only subtypes are allowed. Subtype is the same type or narrower, meaning that string or non-empty-string would be okay.

By default PHPStan isn’t going to report anything about the following code:

/** @return string */
function doFoo()
{
    // ...
}

/** @var string|null $a */
$a = doFoo();

Because the @return PHPDoc might be wrong and that’s what the @var tag might be trying to fix. If you want this scenario to be reported too, enable reportWrongPhpDocTypeInVarTag, or install phpstan-strict-rules.

I’d like the PHP community to use inline @var tags less and less over time. There are many great alternatives that promote good practices and code deduplication: Conditional return types, @phpstan-assert, generics, stub files for overriding 3rd party PHPDocs, or dynamic return type extensions.

Checking truthiness of `@phpstan-pure` with impure points #

Pure functions always return the same value for the same input (arguments and current object state). They also don’t have any side effects like depending on current time, random number generator, or IO like reading file contents or accessing resources over the network.

It’s useful to mark functions and methods with @phpstan-pure if their logic should be pure. PHPStan 2.0 now enforces this annotation, meaning it will report any impure code inside as an error.

We achieved that with the help of impure points. For every statement and expression type PHP supports PHPStan decides if it’s pure or not.

Knowing impure points for any code also helps PHPStan to report more dead code. There’s no point in calling a pure method on a separate line without using its result. If it does not have any side effect, and we’re not using the returned value, then we can safely delete this line:

// Call to method Foo::pureMethod() on a separate line has no effect.
$this->pureMethod();

Also: if a void method does not have any impure points, it doesn’t have to exist:

// Method Foo::add() returns void but does not have any side effects.
private function add(int $a, int $b): void
{
    $c = $a + $b;
}

Less caching, disk space cleanup #

Getting rid of a cache without slowing down the analysis is a clear win. Less stuff to invalidate, less stuff to worry about, less disk space to occupy.

PHPStan used to cache information whether a function is variadic because of func_get_args() call or similar in its body. I realized we have this information freshly available in each run anyway, so we don’t need to cache it. This saves literally tens of thousands of files that PHPStan previously needed to save to disk and then read.

PHPStan now solely relies on the result cache to speed up the analysis.

We took this opportunity to clean up old cache items on disk, so on the first PHPStan 2.0 run you might see some previously occupied disk space free up. On a proprietary project I test PHPStan on it freed up about 1 GB of space.

The future #

I said it three years ago, and I’m saying it again. PHPStan’s future is bright. It’s my full-time job thanks to PHPStan Pro and GitHub Sponsors, splitting the revenue roughly 50-50 between them.

I love my job, I love PHP and I don’t plan to stop. Contributors are very active and indispensable. PHPStan has a thriving ecosystem of extensions as well.

I have a lot of ambitious and even crazy ideas I’d like to try out. But the first thing I will address once the dust settles on 2.0 is adding support for PHP 8.4. You can expect it to be added before the end of 2024.

Do you like PHPStan and use it every day? Consider sponsoring further development of PHPStan on GitHub Sponsors and also subscribe to PHPStan Pro! I’d really appreciate it!

That’s called reference counting. ↩︎
That probably doesn’t use static analysis. ↩︎

PHPStan 1.12: Road to PHPStan 2.0

2024-08-27T00:00:00Z

After three years since the initial PHPStan 1.0 release, we’re getting closer to PHPStan 2.0. After sifting through my list of ideas for the new major version, I realized I can move some of them forward and release them in 1.x series and hide them behind the Bleeding Edge config toggle, so they can be enjoyed by PHPStan users sooner.

This isn’t true just for PHPStan 1.12 but ever since 1.0. If you enable Bleeding Edge, you basically live in the future. You get new rules and behavior changes that will be enabled for everyone in the next major version. That’s your reward as an early adopter.

Here’s an equation:

PHPStan 2.0 = PHPStan 1.12 + Bleeding Edge + BC breaks

When you upgrade to PHPStan 1.12 and enable Bleeding Edge, you can get mostly ready for PHPStan 2.0 today.

But enough about the future. Here’s what’s new in today’s 1.12 release.

General availability of precise type inference for regular expressions #

This is a rare example of a feature that began its life in Bleeding Edge but got out of it sooner than the next major version. Because of its complexity we needed a staged rollout to weed out the bugs.

First introduced in 1.11.6, and improved by dozens of pull requests since then, this feature is about figuring out the precise type for $matches by-ref argument coming from preg_match() and other related functions:

if (preg_match('/Price: (?<currency>£|€)\d+/', $s, $matches, PREG_UNMATCHED_AS_NULL)) {
	// array{0: string, currency: non-empty-string, 1: non-empty-string}
	\PHPStan\dumpType($matches);
}

Markus Staab and Jordi Boggiano of Composer fame worked really hard on this. It brings a whole new level of precision to PHPStan’s type inference.

From what I gathered, this ability is pretty unique and not many programming languages offer it. And now we have it in PHP!

PHPStan performs four categories of sanity checks on types in PHPDocs:

Missing types: performed on level 6 and up, it enforces specifying array value types, generic types, and optionally also callable signatures.
Existing classes: looks for nonexistent classes and also trait references
Unresolvable types: looks for never bottom type that resulted from impossible intersections like string&int, referencing undefined constants like Foo::BAR, etc.
Generics type checks: checks sanity of generic types. Compares the number of type variables in a type against the number of @template above the class declaration, checks the subtyping of bounds, etc.

These type checks weren’t performed consistently for all supported PHPDocs tags. We were missing most or all of these checks for these tags:

@param-out
@param-closure-this
@param-immediately-invoked-callable and @param-later-invoked-callable
@phpstan-self-out
@mixin
@property
@method
@extends, @implements, @use

PHPStan 1.12 fixes that. Wrong and corrupted types are checked consistently across the board. Because these are essentially new rules which would cause new errors reported for most codebases, they were added only to Bleeding Edge, and will be enabled for everyone in PHPStan 2.0.

Too wide private property type #

Another addition to Bleeding Edge checks if a type could be removed from a private property union type, without affecting anything.

// if string is never assigned to `$this->a`, we can remove it from the type
private int|string $a;

PHPStan already had this rule for function and method return types, and now we can enjoy it for properties too.

PHP 8.4 runtime support #

Implementing support for new PHP version in PHPStan comes in four phases:

Make sure PHPStan runs on the new PHP version and all tests pass.
Understand added functions and changed signatures of existing functions in the new PHP version.
Understand new syntax and features. This removes false errors when analysing code written against the new PHP version.
Implement new rules specific to new syntax and features. Discover which parts of the new PHP features are tricky and need to be checked with new static analysis rules.

PHPStan 1.12 implements the first two phases. It runs on PHP 8.4 without any deprecation notices, and new functions like array_find() are already known.

Because of new syntax, the rest is dependent on upgrading to nikic/PHP-Parser v5 which has to be done in a major version.

My plan for the upcoming months is straightforward: finish and release PHPStan 2.0, and then work on PHP 8.4-specific features.

Me and PHPStan contributors put a lot of hard work into this release. I hope that you’ll really enjoy it and take advantage of these new features! We’re going to be waiting for everyone’s feedback on GitHub.

Do you like PHPStan and use it every day? Consider sponsoring further development of PHPStan on GitHub Sponsors and also subscribe to PHPStan Pro! I’d really appreciate it!

PHPStan Reports Different Errors Locally & in CI. What Should I Do?

2024-08-20T00:00:00Z

If you find that PHPStan reports different code on your machine and in continuous integration build system, here are the steps to follow to get rid of this problem.

Is it analysing the same code? #

Make sure you’re looking at the results of the same Git commit in CI as you have checked out locally, and that you have committed all the files in your working directory.

Run git rev-parse HEAD or look at git log to get the Git commit hash. CI systems usually print the current Git commit hash somewhere early in the build log.

Run git status to make sure there are no uncommitted changes you’re running the analysis against.

Is it running the same PHP version? #

Make sure to check that you’re running the same PHP version locally and in CI. You can check that with php -v.

Require PHPStan in your Composer project #

Do not run PHPStan installed somewhere globally in your operating system, nor locally, neither in CI. Install PHPStan in composer.json with your project dependencies with this command:

composer require --dev phpstan/phpstan

This way you will make sure everyone and everything is on the same PHPStan version - your machine, your teammates and most importantly, CI.

Make sure your `composer.lock` is committed in the Git repository #

Commit and version your composer.lock file in Git to make sure your dependencies are locked and always the same until you update them.

Run `composer install`, not `composer update` #

Even with composer.lock committed, make sure you run composer install to install dependencies in CI. Running composer update discards the contents of your composer.lock file and updates all dependencies. Which is something we don’t want.

Run PHPStan’s `diagnose` command to compare the environments #

Since release 1.11.8 PHPStan ships with a diagnose command. It prints useful information about its configuration and more. Do not forget to pass the correct configuration file and rule level when running the command.

The output looks like this:

PHP runtime version: 8.3.1
PHP version for analysis: 8.3.99 (from config.platform.php in composer.json)

PHPStan version: 1.11.11
PHPStan running from:
/var/www/project/vendor/phpstan/phpstan

Extension installer:
composer/pcre: 3.2.0
phpstan/phpstan-deprecation-rules: 1.2.0
phpstan/phpstan-doctrine: 1.4.8
phpstan/phpstan-nette: 1.3.5
phpstan/phpstan-phpunit: 1.4.0
phpstan/phpstan-strict-rules: 1.6.0
phpstan/phpstan-symfony: 1.4.6
phpstan/phpstan-webmozart-assert: 1.2.7
shipmonk/phpstan-rules: 3.1.0

Discovered Composer project root:
/var/www/project

Doctrine's objectManagerLoader: In use
Installed Doctrine packages:
doctrine/dbal: 3.8.6
doctrine/orm: 2.19.6
doctrine/common: 3.4.4
doctrine/collections: 2.2.2
doctrine/persistence: 3.3.3

Symfony's consoleApplicationLoader: No

Compare the output between your local machine and CI to find possible differences.

Check the config file path #

Make sure you’re running PHPStan analyse command with the same configuration file. If you’re passing a custom path with -c, make sure it’s the same one as locally.

If you’re letting PHPStan autodiscover phpstan.neon or phpstan.neon.dist file in the current working directory, it outputs this note at the beginning of the analysis:

Note: Using configuration file /var/www/project/phpstan.neon.

Make sure your local machine uses the same file as the CI environment.

Get rid of duplicate symbols #

If you have two or more different class or function definitions with the exact same name, PHPStan does not guarantee which one it’s going to give priority to. Your local machine might discover one definition first and your CI might discover a different definition first, leading to different analysis results.

Rename your classes and functions so that they are always unique to get rid of this problem.

Fix your custom non-deterministic autoloader #

Sometimes the difference in results comes down to the order of files during the analysis. Because the CI environment might have a different number of CPU cores, the files are going to be analysed in different groups and in different order than on your local machine.

If the difference is about what classes are known and unknown to PHPStan, it’s possible you’re using a custom autoloader to discover them.

A following scenario can occur:

You’re referencing a class name in your code with wrong case. For example. Your class name is AdminUser but you have adminUser somewhere in your code when referencing the same class.
On your local machine the first file that’s analysed refers to the class with the correct name - AdminUser. That makes other occurrences even with the wrong case let the class to be successfully found by PHPStan.
In CI the first file that’s analysed refers to the class with an incorrect name - adminUser. Your custom autoloader should still find the class successfully but maybe has a bug. This makes PHPStan report “unknown class” error and it also makes it memoize that this class does not exist.
When the second file that’s analysed in CI refers correctly to AdminUser, it still makes PHPStan report an error about unknown class which is a different behaviour than you’re experiencing locally.

To fix this problem, make your autoloader discover classes even with wrong case.

Open a discussion on PHPStan’s GitHub #

If none of the steps above helped you to get consistent results between running PHPStan locally and in CI, please open a discussion on GitHub, so we can help you figure out this problem.

Do you like PHPStan and use it every day? Consider sponsoring further development of PHPStan on GitHub Sponsors and also subscribe to PHPStan Pro! I’d really appreciate it!

Debugging PHPStan Performance: Identify Slow Files

2024-07-05T00:00:00Z

If you feel like PHPStan could be faster when analysing your project, you can debug what’s actually making it slow. Usually the cause of slow analysis can be pinpointed to a single file or a handful of files in a project that make PHPStan’s analysis crawl to a halt.

Before you start debugging, try enabling Bleeding Edge. It makes analysis in huge codebases run much faster. It comes with a slight backward compatibility break with the advantage of breaking bidirectional memory references, making the job of garbage collector easier.

If that didn’t help, run PHPStan again but add -vvv --debug command line options. PHPStan will run in a single thread instead of in multiple processes at once, and it will print the elapsed time and consumed memory during the analysis of each file:

/var/www/src/Database/Eloquent/Relations/MorphToMany.php
--- consumed 6 MB, total 200 MB, took 0.11 s
/var/www/src/Database/Eloquent/Relations/HasOneThrough.php
--- consumed 0 B, total 200 MB, took 0.06 s
/var/www/src/Database/Eloquent/Relations/MorphPivot.php
--- consumed 0 B, total 200 MB, took 0.06 s
/var/www/src/Database/Eloquent/Relations/Pivot.php
--- consumed 2 MB, total 202 MB, took 0.09 s
/var/www/src/Database/Eloquent/Relations/HasOneOrMany.php
--- consumed 0 B, total 202 MB, took 0.15 s
/var/www/src/Database/Eloquent/Relations/BelongsTo.php
--- consumed 0 B, total 202 MB, took 0.15 s

You can either watch this log go by in realtime with your own eyes and spot files that took too much time or memory. Or you can redirect the output to a file:

vendor/bin/phpstan -vvv --debug > phpstan.log

And parse this file with a simple script by Ruud Kamphuis that sorts the file list and puts the files that took the most time on top:

<?php declare(strict_types=1);

$log = new SplFileObject("phpstan.log");

$logs = [];
$file = null;
while (!$log->eof()) {
    $line = trim($log->fgets());
    if ($line === '') {
        continue;
    }
    if ($file === null) {
        $file = $line;
        continue;
    }
    if (preg_match('/took (?<seconds>[\d.]+) s/', $line, $matches) !== 1) {
        continue;
    }

    $logs[] = [(float) $matches['seconds'], $file];
    $file = null;
}

usort($logs, fn(array $left, array $right) => $right[0] <=> $left[0]);
$logs = array_slice($logs, 0, 20);

echo "Slowest files" . PHP_EOL;
foreach ($logs as $log) {
    echo sprintf("%.2f seconds: %s", $log[0], $log[1]) . PHP_EOL;
}

Save this file into parse.php in the same directory where phpstan.log is and run it:

php parse.php

It will output 20 files that took the most time:

Slowest files
4.46 seconds: /var/www/src/Collections/LazyCollection.php
2.71 seconds: /var/www/src/Support/Str.php
2.56 seconds: /var/www/src/Console/Command.php
2.45 seconds: /var/www/src/Validation/Validator.php
2.44 seconds: /var/www/src/Database/Query/Builder.php
2.41 seconds: /var/www/src/Collections/Collection.php
2.12 seconds: /var/www/src/Database/Eloquent/Builder.php
2.10 seconds: /var/www/src/Foundation/Testing/TestCase.php
2.01 seconds: /var/www/src/Database/Eloquent/Model.php
...

What to do with this list? It’s up to you to decide. Maybe the slowest file is really large and maybe even auto-generated. Analysing it with PHPStan doesn’t probably bring too much value, so you can exclude it from the analysis and make PHPStan immediately faster.

But if the slowest file isn’t that large, you’ve just found a real bottleneck which is an opportunity to make PHPStan faster. Take this file and open a new bug report in PHPStan’s GitHub repository so we can take a look and use it to make PHPStan faster.

Happy debugging!

Do you like PHPStan and use it every day? Consider sponsoring further development of PHPStan on GitHub Sponsors and also subscribe to PHPStan Pro! I’d really appreciate it!

PHPStan 1.11 With Error Identifiers, PHPStan Pro Reboot and Much More

2024-05-13T00:00:00Z

This release has been in the works for a year. But it doesn’t mean there hasn’t been anything else released for a year. After starting the work on PHPStan 1.11 I continued working on 1.10.x series in parallel, bringing 54 releases into the world between April 2023 and 2024. But at some point earlier this year I said “enough!” and couldn’t resist finally bringing the awesome improvements in 1.11 over the finish line and into the world.

Error Identifiers #

When I decided to add error identifiers I knew it was going to be a lot of work. They’re a way of labeling and categorizing errors reported by PHPStan useful for ignoring errors of a certain category among other things.

I had to go through all PHPStan rules and decide how the identifier should look like for all of them. I’ve settled on two-part format category.subtype pretty early on as being easy to read and memorize. Other tools like TypeScript have settled on simple numbers like TS2322. In my opinion that’s as human-friendly as IP addresses. There are reasons why we need DNS to translate that to actual names.

Another easy way out would be to mark the rule’s implementation class name as its identifier. But I’ve never considered these to be user-facing and stable. They’re implementation details. To give them public meaning would really tie our hands when evolving PHPStan. Because some rule classes report very different issues resulting in multiple identifiers, and at the same time, different rules report very similar issues in PHP code resulting in a single identifier.

So a more flexible approach was needed. You can see for yourself how it turned out. There’s a catalogue on PHPStan’s website with all the identifiers. You can group them by identifier (and see all the rules where the same identifier is reported), or group them by the rule class (and see all the identifiers reported by the same class). This page is generated by analysing PHPStan sources with PHPStan to be used on PHPStan’s website. There’s probably an Inception or Yo Dawg joke somewhere in there.

So let’s say we have an error and we want to find out its identifier in order to ignore it. If we’re using the default table output formatter, we can run PHPStan with -v and see the identifiers right in the output:

Or we can run PHPStan Pro by launching PHPStan with --pro CLI option and see the identifier in the UI next to the reported error:

Once we know the identifier we can use it in the new @phpstan-ignore comment annotation that replaces the current pair of @phpstan-ignore-line and @phpstan-ignore-next-line annotations which ignore all errors on a certain line. With @phpstan-ignore PHPStan figures out if there’s some code besides the comment on the current line (and ignores an error in that code), or if we want to ignore an error in the code on the next line:

// Both variants work:
// @phpstan-ignore echo.nonString
echo [];

echo []; // @phpstan-ignore echo.nonString

In @phpstan-ignore specifying an identifier is always required.

If we want to ignore multiple errors on the same line, we can place multiple identifiers separated by a comma in the @phpstan-ignore annotation.

echo $foo, $bar;  // @phpstan-ignore variable.undefined, variable.undefined

Yes, we need to repeat the same identifier twice if we want to ignore two errors of the same type on the same line. Better safe than sorry!

We might also want to explain why an error is ignored. The description has to be put in parentheses after the identifier:

// @phpstan-ignore offsetAccess.notFound (exists, set by a reference)
data_set($target[$segment], $segments, $value, $overwrite);

We can also use identifiers in our configuration’s ignoreErrors section. This ignores all errors that match both the message and the identifier:

parameters:
	ignoreErrors:
		-
			message: '#Access to an undefined property Foo::\$[a-zA-Z0-9\\_]#'
			identifier: property.notFound

Or we can ignore all errors of a specific identifier:

parameters:
	ignoreErrors:
		-
			identifier: property.notFound

Across PHPStan core and 1^st extensions there’s a total of 728 identifiers in 364 rule classes. ^[1] I think I managed to strike a good middle ground with the granularity between being too coarse and being too fine.

PHPStan Pro Wizard #

I introduced PHPStan Pro in September 2020 as a paid addon for PHPStan that doesn’t remove anything from the beloved open-source version, but adds extra features that make PHPStan easier to use. Since that PHPStan Pro grew steadily and contributes about one third to my income from PHPStan. That made my open-source work sustainable and I’m really grateful for that.

I’ve had many ideas how to make PHPStan Pro more useful and interesting but I mostly sat on them for the first three years since the initial release, choosing to work on open-source PHPStan instead.

Error identifiers brought the perfect opportunity to turn to PHPStan Pro again. Right now your codebase is probably full of @phpstan-ignore-line and @phpstan-ignore-next-line comments. They ignore all errors on specific lines. All future errors introduced from the point you type out these comments are silently ignored without you ever seeing them. Which is dangerous.

What if you could snap your fingers and all of these comments magically turned into the new @phpstan-ignore with the right identifiers filled out?

- // @phpstan-ignore-next-line
+ // @phpstan-ignore argument.type
  $this->requireInt($string);

PHPStan Pro introduces a migration wizard that’s going to do this for you! Let’s run PHPStan with --pro CLI option and see it in action:

With just a few clicks your codebase can be modernized and made safer thanks to this wizard.

PHPStan Pro now ships with this single wizard, but I have a lot more ideas how wizards could be used to update various aspects of your codebases related to static analysis like typehints and PHPDocs and leave them in a better state. My plan is to do regular “wizard drops” (like feature drops). As the foundation has been laid out, it shouldn’t take long for more awesome wizards to appear!

PHPStan Pro UI Revamp #

But wizards are not the only thing that has changed about PHPStan Pro. Since the beginning PHPStan Pro has been about browsing errors in a web UI instead of a terminal.

You’re probably familiar with this saying:

If you’re not embarrassed by the first version of your product, you’ve launched too late.

Well I’m definitely not guilty of that 🤣 PHPStan Pro up until today did not have a good UI. Each error was rendered in a separate box so if you had multiple errors around neighbouring lines, you could quickly lose context. They weren’t presented in a clear and understandable way. Additionally, you could lose the focus on currently showing file if you reloaded the webpage. The sidebar panel wasn’t sticky so it shifted away if you scrolled a long file. It was not possible to remap Docker path to the host’s filesystem.

I could continue down this unending embarrassing list of shortcomings of the previous version, but let me put an end to that.

The new version you’ll get once you update to PHPStan 1.11 and launch Pro with --pro is much better. Let’s have a look:

The layout is more natural and resembles an IDE. Each file is rendered just once and errors are attached to lines where they are reported. You can expand hidden lines to see more context around an error. Docker paths can be remapped so that editor links lead to the correct file.

PHPStan lets you see ignored errors too. If you’ve inherited a project and want to see what errors the previous team ignored, or if you want to check the errors lurking in your huge baseline, PHPStan Pro lets you do that with ease. By default it will show a small pill button you can use to see ignored errors near normally reported errors, but you can also change the setting to show and browse all ignored errors:

PHPStan Pro analyzes your codebase in the background and refreshes the UI with the latest errors automatically. If you don’t want to keep your hands warm while your laptop struggles to keep up with too-frequent analysis, you can choose to run it only when the PHPStan Pro window is in focus, or pause it altogether:

PHPStan Pro costs €7/month for individuals and €70/month for teams. If you decide to pay annually, you’ll get PHPStan Pro for 12 months for the price of 10 months – that’s €70/year for individual developers, €700/year for teams.

There’s a 30-day free trial period for all the plans. And there’s no limit on the number of projects - you can run PHPStan Pro on any code you have on your computer.

Start by running PHPStan with --pro or by going to account.phpstan.com and creating an account.

Is this function really pure? #

We’re not even close to the end of the list of what’s new in PHPStan 1.11.

The @phpstan-pure annotation has been supported for a long time to mark functions that don’t have any side effects. That’s useful for remembering and forgetting returned values among other things.

But PHPStan didn’t enforce the truthiness of this annotation. It always obeyed it. This release changes that. I went through the trouble of deciding what language construct is pure or not for all statement and expression types. PHPStan now understands for example that $a + $b is always pure but calling sleep(5) or assigning a property outside of constructor is impure.

Once we have that information we can use it for multiple opportunities as marking some pieces code as wrong. Pure expressions always have to be used so it doesn’t make sense to have these on a separate line without using the results:

$a + $b;
new ClassWithNoConstructor();
$cb = static function () {
    return 1 + 1;
};
$cb(); // does not do anything

Besides reporting functions annotated with @phpstan-pure but having side effects as wrong, we can now also afford marking functions with @phpstan-impure without any side effects also as wrong. And finally, void-returning functions (which are understood as impure implicitly) that do not have any side effects are also reported as wrong. What would be a point of calling a function that doesn’t have a side effect and doesn’t return any value?

Clamping this problem space from all sides allowed us to weed out some bugs by testing development versions on real-world projects.

For all of this to be applicable to real-world situations, we also added new pure-callable and pure-Closure PHPDoc types that can be called even in pure functions.

Make sure to enable bleeding edge to take advantage of these new rules.

When is a passed callable called? #

Callables are severely underdocumented in PHP projects. You could already type and enforce the signature of a callable to make it more useful for static analysis:

/**
 * @param callable(int, int): string $cb
 */

But other aspects of callables remained mysterious for PHPStan. What happens to a callback when it’s passed to another function? Is it called immediately or later? This information can become handy for purity checks described in previous section, and also for bringing exceptions under control.

$this->doFoo(function () {
    if (rand(0, 1)) {
        throw new MyException();
    }
});

It would be useful for PHPStan to know if this call to method doFoo should be surrounded with a try-catch or if the thrown MyException should be documented in @throws PHPDoc tag. But it needs to know if this callback is called immediately, or saved for later invocation.

PHPStan 1.11 introduces a new pair of PHPDoc tags for this purpose:

@param-immediately-invoked-callable
@param-later-invoked-callable

The default reasonable convention if these tags are not present is that callables passed to functions are invoked immediately, and callables passed to class methods are invoked later.

You need these PHPDoc tags only to override the defaults, so you’ll use @param-immediately-invoked-callable above methods and @param-later-invoked-callable above functions.

What is a passed closure bound to? #

PHP’s methods Closure::bind and Closure::bindTo are used to change what $this refers to in a non-static closure. Doing that can lead to confusing PHPStan:

// we're in class Foo
// $this is Foo here
$this->doSomething(function () {
    // PHPStan still thinks $this is Foo here
    // but it could be something different
});

If your function binds passed closure to some other object, you can now use new PHPDoc tag @param-closure-this to inform PHPStan about it:

/**
 * @param-closure-this \stdClass $cb
 */
function doFoo(callable $cb): void
{
    $cb->bindTo(new \stdClass());
    // ...
}

It fully works with generics and conditional types so you can really go crazy in there!

New options for possibly nonexistent offsets in arrays #

PHPStan by default tries not to complain too much about code that might be totally fine. One example is accessing offsets of arrays without checking that these offsets actually exist first.

/**
 * @param array<string, Item> $items
 */
function doFoo(array $items, string $key): void
{
    // this might exist but might not
    $selectedItem = $items[$key];
}

Tom De Wit kindly contributed a pair of new configuration options to have potential these issues reported.

To have the error reported in the example above, turn on reportPossiblyNonexistentGeneralArrayOffset.

To have the same error reported for constant arrays, also known as array shapes, turn on reportPossiblyNonexistentConstantArrayOffset.

public function doFoo(string $s): void
{
    $a = ['foo' => 1];
    echo $a[$s];
}

My personal preference is to only turn on the latter option, but your experience may vary.

Do you like PHPStan and use it every day? Consider sponsoring further development of PHPStan on GitHub Sponsors and also subscribe to PHPStan Pro! I’d really appreciate it!

The fact there are exactly two identifiers per rule class on average is a total coincidence. It made me re-check my algorithm that counts them. ↩︎

Enhancements in Handling Parameters Passed by Reference in PHPStan 1.10.60

2024-03-07T00:00:00Z

PHPStan 1.10.60 introduces enhancements in handling parameters passed by reference. These parameters, besides typical returned values, also serve as a form of output that a called function can produce:

function foo(&$p): void
{
	$p = true;
}

$v = false;
foo($v);
var_dump($v); // bool(true)

You might be surprised to learn that you can set a type for a parameter passed by reference, but it doesn’t limit the output type:

function foo(string &$p): void
{
	$p = 1;
}

$v = 'foo';
foo($v);
var_dump($v); // int(1)

Previously, PHPStan’s type inference discarded the type of a variable passed into such a parameter:

function foo(string &$p): void
{
	$p = 1;
}

$v = 'foo';
foo($v);
\PHPStan\dumpType($v); // mixed

When analysing code that calls a function, PHPStan relies on function’s signature and PHPDoc to understand what’s going to happen. It does not dive into the function implementation because it’d hurt the performance of the analyser. So changing the type of the variable to mixed was a sensible solution - we didn’t know what’s going on inside the function so we could not assume anything.

In the latest release, this behavior has changed.

All of the following changes are part of Bleeding Edge because we intend to keep our generous backward compatibility promise. You can get them in PHPStan 1.10.60 today if you include the Bleeding Edge config. Everybody else will get them as part of the next major release, PHPStan 2.0.

Checking the Type of Argument Passed into a Parameter by Reference #

The recent pull request by Lincoln Maskey initiated the development of these enhancements.

Previously, PHPStan skipped type checking for all parameters passed by reference. Consequently, code like the following did not trigger any warnings:

function foo(string &$p): void
{
	// ...
}

$v = 1;
foo($v);

This was because some internal built-in PHP functions have parameters passed by reference in their signature, but the type enforcement didn’t match that of userland functions.

However, PHPStan is now equipped to check the type in such cases, ensuring more comprehensive type validation moving forward.

Assumption of Output Type #

Instead of setting the type of the passed variable to mixed, we now assume that the user does not intend to change the type entirely:

function foo(string &$p): void
{
	// ...
}

$v = 'foo';
foo($v);
\PHPStan\dumpType($v); // string

However, this creates a problem: what if we do want to change the type? You can still achieve this using @param-out PHPDoc tag:

/**
 * @param-out int $p
 */
function foo(string &$p): void
{
	$p = 1;
}

$v = 'foo';
foo($v);
\PHPStan\dumpType($v); // int

Enforcing Assigned Type #

Psst, I’ll let you in on a little secret. Not all extra PHPDoc features static analysers offer are actually enforced by their rules. @param-out was one example. You could have assigned anything to the variable and PHPStan would not complain.

That changes today. These assignments are now checked by new set of rules:

function foo(string &$p): void
{
	// Parameter &$p by-ref type of function foo() expects string, int given.
	// Tip: You can change the parameter out type with @param-out PHPDoc tag.
	$p = 1;
}

Yes, PHPStan will even contextually hint to you that you can write a @param-out PHPDoc tag if the assignment to an integer is intentional. These tips can be seen next to a 💡 in the CLI output, and also as a small grey text on the on-line playground.

If @param-out is already involved, the message is a little bit different:

/**
 * @param-out string $p
 */
function foo(string &$p): void
{
	// Parameter &$p @param-out type of function foo() expects string, int given.
	$p = 1;
}

And if the type of @param-out is different to the input type, but we don’t reassign the variable, PHPStan is also able to notice it:

/**
 * @param-out int $p
 */
function foo(string &$p): void // Parameter &$p @param-out type of function foo() expects int, string given.
{

}

Detecting Overly Broad `@param-out` Type #

Similar to how PHPStan handles return types, it now detects when a union type in the output parameter type includes unused parts:

function foo(?string &$p): void
{
	// Function foo() never assigns null to &$p so it can be removed from the by-ref type.
	// Tip: You can narrow the parameter out type with @param-out PHPDoc tag.
	$p = 'foo';
}

If your function accepts null but the variable never leaves the function as null anymore, you should inform the caller with the @param-out tag as well:

/**
 * @param-out string $p
 */
function foo(?string &$p): void
{
	// No errors
	$p = 'foo';
}

Do you like PHPStan and use it every day? Consider supporting further development of PHPStan. I’d really appreciate it!

A guide to call-site generic variance

2023-09-19T00:00:00Z

PHPStan has supported what is called declaration-site variance for a long time. An example you might be familiar with is the infamous @template-covariant. And although not as often useful, it also has a contravariant counterpart.

To freshen your memory: you can mark a template type as covariant:

/** @template-covariant ItemType */
interface Collection
{
	/** @param ItemType $item */
	public function add(mixed $item): void;

	/** @return ItemType|null */
	public function get(int $index): mixed;
}

This allows you to pass Collection<Cat> into functions where Collection<Animal> is expected. But it comes at a cost:

/** @param Collection<Animal> $animals */
function foo(Collection $animals): void
{
	$animals->add(new Dog());
}

By itself, this is a perfectly valid code. But with Collection being covariant over its template type, we can now mix cats with dogs. That’s why PHPStan prevents us from using the ItemType in Collection::add() method’s parameter:

Template type ItemType is declared as covariant, but occurs in contravariant position in parameter item of method Collection::add().

That’s the trade-off: if you want the Collection to be covariant, it can only have the get method. If you want it to have the add method too, it has to be invariant in its ItemType.

Until now, there has not been an easy way around this. You could split the interface into a read-only one that can safely be covariant, and an invariant one:

/** @template-covariant ItemType */
interface ReadonlyCollection
{
	/** @return ItemType|null */
	public function get(int $index): mixed;
}

/**
 * @template ItemType
 * @extends ReadonlyCollection<ItemType>
 */
interface Collection extends ReadonlyCollection
{
	/** @param ItemType $item */
	public function add(mixed $item): void;
}

But that is a lot of work and can quickly get tedious. Call-site variance is a way of having PHPStan do this work for you.

Call-site variance #

As the name suggests, call-site variance (or type projections, if you prefer fancier words) moves the variance annotation from the declaration to the call site. This means that the declaration of the interface can remain invariant, and therefore contain both get and add methods:

/** @template ItemType */
interface Collection
{
	/** @param ItemType $item */
	public function add(mixed $item): void;

	/** @return ItemType|null */
	public function get(int $index): mixed;
}

If you need a specific function to accept Collection<Cat> in place of Collection<Animal>, you can instruct it so by attaching the covariant keyword to the generic type argument:

/** @param Collection<covariant Animal> $animals */
function foo(Collection $animals): void
{
	$animals->add(new Dog());
}

Correspondingly, the error has moved from the declaration to the call-site: if the implementation does something that would break type safety, like adding a Dog into the collection above, PHPStan will tell us:

Parameter #1 $item of method Collection<covariant Animal>::add() expects never, Dog given.

Call-site contravariance #

Although not as useful, it’s worth mentioning that you can also use contravariant type projections. For example, if we wanted a happy little function that fills a collection with dogs, we could make it so that it accepts not only Collection<Dog>, but also Collection<Animal>, or even Collection<mixed>:

/** @param Collection<contravariant Dog> $collection */
function fill(Collection $collection)
{
	while (true) {
		$collection->add(new Dog);
	}
}

This too has a limitation, but at least this time it’s not so drastic: if we wanted to get a value from the collection, we can:

/** @param Collection<contravariant Dog> $collection */
function fill(Collection $collection)
{
	while ($collection->get(42) === null) {
		$collection->add(new Dog);
	}
}

But because a contravariant type is not bounded from the top, we cannot make any assumption about the type of the retrieved item, and neither can PHPStan, therefore the type of $collection->get(42) would be mixed.

Star projections #

Sometimes, you just don’t care about the type of the values you’re working with. Let’s add a count() method to the Collection:

/** @template ItemType */
interface Collection
{
	/** @param ItemType $item */
	public function add(mixed $item): void;

	/** @return ItemType|null */
	public function get(int $index): mixed;

	public function count(): int;
}

This method doesn’t reference the ItemType template type at all. We are using it in a function printSize that prints the size of a collection. In this case, the function can accept a collection of anything. Inspired by other languages such as Kotlin, PHPStan provides an idiomatic way of writing this, using an asterisk:

/** @param Collection<*> $collection */
function printSize(Collection $collection): int
{
	echo $collection->count();
}

Obviously, we cannot make any assumptions about the collection’s item type whatsoever. In other words, star projections combine the limitations of covariant and contravariant projections. If we were to add() anything into the collection inside this printSize function, we would get a similar error as above:

Parameter #1 $item of method Collection<*>::add() expects never, Dog given.

And if we wanted to get a value from the collection, it would be mixed:

/** @param Collection<*> $collection */
function printSize(Collection $collection): int
{
	$item = $collection->get(0);
	// $item is mixed
}

Using RuleErrorBuilder to enrich reported errors in custom rules

2023-07-12T00:00:00Z

When writing custom rules for PHPStan, developers can either return plain strings or RuleError instances.

/**
 * @phpstan-param TNodeType $node
 * @return (string|RuleError)[] errors
 */
public function processNode(Node $node, Scope $scope): array;

The latter is a way to attach additional information to the reported errors.

RuleError is just an interface. The way you create an instance is through RuleErrorBuilder:

return [
	RuleErrorBuilder::message('This is an error message.')
		->build(),
];

Besides setting an error message RuleErrorBuilder offers the following capabilities:

->line(int $line): Set a different file line. Useful when you want to report a different line than the node which the rule was called for
->file(string $file): Set a different file path. Useful for collector rules.
->tip(string $tip): Shows an additional text next to a 💡 emoji on the command line. You can tell the user why the error is reported or how to solve it.
->nonIgnorable(): Makes the error non-ignorable by any means.
->metadata(array<mixed> $metadata): Attach additional metadata to the error that can later be read in the error formatter.
->identifier(string $identifier): Sets an error identifier. More about this below.

Error identifiers #

The flagship feature of the upcoming PHPStan 1.11 release are error identifiers. You will be able to use them to ignore specific errors:

function () {
	// @phpstan-ignore argument.type
	$this->foo->doSomethingWithString(1);

	$this->foo->doSomethingWithString(2); // @phpstan-ignore argument.type
};

There’s a generated catalogue of all the identifiers in PHPStan itself and 1^st party extensions. Each identifier links to source code where it’s reported so this serves as a great educational resource about PHPStan internals.

To ensure great experience for all users, custom rules will also be required to provide their own identifiers. At first it will only be soft-enforced in Bleeding Edge, and in PHPStan 2.0 it will be hard-enforced with a native return type.

This means that the ability to return plain strings from custom rules will eventually go away. I recommend you to switch to RuleErrorBuilder sooner rather than later.

PHPStan 1.11 with Bleeding Edge enabled will require custom rules to return errors with identifiers. As a first step, remove any PHPDoc above your processNode method. If your rule does not yet have @implements Rule<...> generic PHPDoc tag, add it:

+/**
+ * @implements Rule<StaticCall>
+ */
 class MyRule implements Rule
 {
 	public function getNodeType(): string
 	{
 		return StaticCall::class;
 	}

-	/**
-	 * @param StaticCall $node
-	 * @param Scope $scope
-	 * @return string[]
-	 */
 	public function processNode(Node $node, Scope $scope): array
 	{
 		// ...
 	}

Even without the PHPDoc both PHPStan and PhpStorm will understand that the parameter $node coming into the processNode method is a StaticCall.

After that migrate the plain strings to RuleErrorBuilder, and add error identifiers for each of them:

 	public function processNode(Node $node, Scope $scope): array
 	{
 		return [
-			'This is an error message.',
+			RuleErrorBuilder::message('This is an error message.')
+				->identifier('some.problem')
+				->build(),
 		];
 	}

For an inspiration how the identifiers should look like check out the catalogue.

The identifier must consist of lowercase and uppercase ASCII letters, and optionally can have one or more dots in the middle. See the tests for examples of valid and invalid identifiers.

PHPStan 1.11 will be released at some time in the coming months. Don’t worry, your old rules will not break with that release, but it would be great to modernize them to take advantage (and let your users take advantage) of the latest PHPStan features. Thanks!

PHPStan Blog

Restricted Usage Extensions - You Don't Always Need a Custom Rule

PHPStan 2.1: Support For PHP 8.4's Property Hooks, and More!

Property hooks #

Asymmetric visibility #

#[Deprecated] attribute #

PHPStan 2.0 Released With Level 10 and Elephpants!

Level 10 #

List type #

Lower memory consumption leads to faster performance #

Validate inline PHPDoc @var tag type #

Checking truthiness of @phpstan-pure with impure points #

Less caching, disk space cleanup #

The future #

PHPStan 1.12: Road to PHPStan 2.0

General availability of precise type inference for regular expressions #

Fix blind spots in PHPDoc tags type checks #

Too wide private property type #

PHP 8.4 runtime support #

PHPStan Reports Different Errors Locally & in CI. What Should I Do?

Is it analysing the same code? #

Is it running the same PHP version? #

Require PHPStan in your Composer project #

Make sure your composer.lock is committed in the Git repository #

Run composer install, not composer update #

Run PHPStan’s diagnose command to compare the environments #

Check the config file path #

Get rid of duplicate symbols #

Fix your custom non-deterministic autoloader #

Open a discussion on PHPStan’s GitHub #

Debugging PHPStan Performance: Identify Slow Files

PHPStan 1.11 With Error Identifiers, PHPStan Pro Reboot and Much More

Error Identifiers #

PHPStan Pro Wizard #

PHPStan Pro UI Revamp #

Is this function really pure? #

When is a passed callable called? #

What is a passed closure bound to? #

New options for possibly nonexistent offsets in arrays #

Enhancements in Handling Parameters Passed by Reference in PHPStan 1.10.60

Checking the Type of Argument Passed into a Parameter by Reference #

Assumption of Output Type #

Enforcing Assigned Type #

Detecting Overly Broad @param-out Type #

A guide to call-site generic variance

Call-site variance #

Call-site contravariance #

Star projections #

Using RuleErrorBuilder to enrich reported errors in custom rules

Error identifiers #

`#[Deprecated]` attribute #

Validate inline PHPDoc `@var` tag type #

Checking truthiness of `@phpstan-pure` with impure points #

Make sure your `composer.lock` is committed in the Git repository #

Run `composer install`, not `composer update` #

Run PHPStan’s `diagnose` command to compare the environments #

Detecting Overly Broad `@param-out` Type #