* Support compleitions on class references
This provides completions on class references (as opposed to initiated objects via the type map), so you can do `MyClass::` and get completitions for static methods and constants etc.
* Only provide completions for references that don't exist
* Remove file map cache when re-analyzing files
When the project is re-analyzed under the single thread condition (not using a process pool), the filemaps are not cleared before re-analyzing files. This means that file maps only get appended to. If you delete the contents of a file via the LSP, the file map will still be populated with all the old values for example.
In doing this I had to write a few more tests to check my assumptions too, so adding those additional tests.
* Rename test
* Formatting
* Formatting again!
Fixesvimeo/psalm#5048
The issue was caused by missing dependency of a class that Psalm tried
to inspect through reflection. Fixed by using composer autoloader which
avoids the need to use reflection.
* fix#5010 function exec() is disabled
* Improve error message
Co-authored-by: Thomas Bley <thomas.bley@bringmeister.de>
Co-authored-by: Matthew Brown <github@muglug.com>
* #4997 added more precise stub for `count()` returning `0` or `positive-int` on known types
* #4997 updated `count()` to support `\SimpleXmlElement` and `\ResourceBundle` counting, as well as handling hardcoded 2-element-arrays cases
This patch:
* adds support for `count(\SimpleXmlElement)` (https://www.php.net/manual/en/simplexmlelement.count.php)
* adds support for `count(\ResourceBundle)` (https://www.php.net/manual/en/resourcebundle.count.php)
* removes usage of global constants from stub (not supported - see https://www.php.net/manual/en/function.count.php)
* adds support for identifying fixed-element-count arrays, for example `count(callable&array)`, which is always `2`
* #4997 adapted `FunctionCallReturnTypeFetcher` to infer `TPositiveInt` for `count(TNonEmptyArray)` and `count(TNonEmptyList)`
* The `FunctionCallReturnTypeFetcher` is responsible for defining the precise type of a `\count(T)`
expression when given a `T`, so we baked the whole type resolution for `positive-int`, `0` and
`positive-int|0` directly in there.
While this complicates things, it is also true that it is not possible right now (for the stubs)
to provide the level of detail around `count()` that is required by the type inference system
for such a complex function with so many different semantics.
* Split unit test over multiple jobs in GitHub Actions, lowering the total run time
* rename FileManipulationTest to FileManipulationTestCase so it does not run as a standalone Test
