In many sitations, stub files will receive a shallow _and_ deep scan when project files require extra analysys on things like parent classes. This makes stub file scanning inconsistent (orders become much less predictable for example), and adds extra process time to scan the files twice. In the case of stubs providing classes and functions for large projects, this is a non-trivial amount of time.
As deep scanning stubs should take just about as long as a shallow scan, it makes sense to just always deep scan them.
Fixes#3568.
* Add new config: sealAllMethods
* Add some more tests
* Fix codesniffer issue with preg_quote
* Fix missing method in test
Co-authored-by: Olle <noemail>
as suggested in the PR it's best to make the setting configurable.
In order not to break existing installations, we default to keeping the
old behaviour, but in a later version of psalm, we might change the
default.
compared to AfterFunctionCallAnalysisInterface which gets only called
after a call to a function declared within the project, a plugin
implementing AfterEveryFunctionCallAnalysisInterface will get called for
every function call, including calls of PHP builtins.
On the other hand, this interface doesn't allow modification of the code
nor tweaking the return type, but it's still useful for accounting
purposes and for depreacting calls to PHP builtins
this fixes#2804
if a composer.json is present and a PHP version requirement is
configured, we set the php version to the minimal PHP version that
satisfies the composer requirement.
Additionally, this adds a `phpVersion` attribute to the <psalm> tag. If
that's set, it takes precedence over what has been detected in
composer.json.
And finally, the --php-version command line flag continues to work and
takes precedence over the setting in the <psalm> tag
this fixes#2628
* check if phpstorm meta path is a file or directory, making a note if it was a directory, re: #2640
* import is_file()
* overcautiously glob into meta directory
This change introduces an option to have the configuration split across
several files using standard XInclude tags. This may be useful for more
complex configs, or to include auto-generated parts into a manually
written config file.
