e.g. you run the tests with a php83 executable but your default php is PHP 7.4, it will suddenly change while running the tests leading to false positive errors
Historically it was often not quite clear to users what PHP version
Psalm assumes, and why. This PR addresses this issue by printing the
version and where we got it from right before scanning the files.
* Use separate exit code to indicate Psalm finding issues
This will allow to distinguish successful run that found some issues
from crashes.
* Fix e2e test expectations
* Documented exit statuses
* Run tests in random order
Being able to run tests in any order is a pre-requisite for being able
to run them in parallel.
* Reset type coverage between tests, fix affected tests
* Reset parser and lexer between test runs and on php version change
Previously lexer was reset, but parser kept the reference to the old
one, and reference to the parser was kept by StatementsProvider. This
resulted in order-dependent tests - if the parser was first initialized
with phpVersion set to 7.4 then arrow functions worked fine, but were
failing when the parser was initially constructed with settings for 7.3
This can be demonstrated on current master by upgrading to
nikic/php-parser:4.9 and running:
```
vendor/bin/phpunit --no-coverage --filter="inferredArgArrowFunction" tests/ClosureTest.php
```
Now all tests using PHP 7.4 features must set the PHP version
accordingly.
* Marked more tests using 7.4 syntax
* Reset newline-between-annotation flag between tests
* Resolve real paths before passing them to checkPaths
When checkPaths is called from psalm.php the paths are resolved, so we
just mimicking SUT behaviour here.
* Restore newline-between-annotations in DocCommentTest
* Tweak Appveyor caches
* Tweak TravisCI caches
* Tweak CircleCI caches
* Run tests in parallel
Use `vendor/bin/paratest` instead of `vendor/bin/phpunit`
* Use default paratest runner on Windows
WrapperRunner is not supported on Windows.
* TRAVIS_TAG could be empty
* Restore appveyor conditional caching
The idea behind this is that Psalm should not use project autoloader for
its own things. So if we have a project with autoloader and no code,
then any project autoloader hit means Psalm failed to load something
itself.
Right now it highlights several issues in CoreGenericClasses stub:
- usage of `callback` instead of `callable`
- `@property-read` not resolving template parameters
When Psalm is installed with `composer global require vimeo/psalm` it
brings in `ocramius/package-versions`, effectively making it a global
composer plugin (so it runs for all `composer install`s, even for
totally unrelated projects).
However `ocramius/package-versions` has a peculiar quirk: it fails when
there's no `composer.lock` present, and there's no `composer.lock` for
projects that have no dependencies (like the end-to-end test projects).
The net result is that end-to-end tests always fail wherever Psalm is
installed globally.
This PR fixes it by disabling composer plugins for end-to-end tests.
* Extract function getPsalmHelpText() from psalm.php
* Extract initialiseConfig from psalm.php
* Add -c as valid short option for psalter and psalm-refactor
* Use initialiseConfig in psalter, psalm-refactor and psalm-language-server as well as psalm
* Rely on psalm --alter resolving directory from config file in test
* Remove erronous condition for config file path
This code was based on me wrongly thinking that the config file location
was seprated from the argument name with a space instead of an equals
sign
* Use config dir as current dir in psalm and psalm-refactor, as with psalter and psalm-language-server
* Remove redundant duplicated code
* Refactor: move calls to \Psalm\Config::setComposerClassLoader inside initialiseConfig
* PHPCS fix
* Extract function get_path_to_config from command scripts
* Refactor - extract functions from \Psalm\Config::loadFromXML
* Refactor - reduce verbosity of config loading code
* Allow running e2e tests on windows
* Fix testCompactReport on Windows
* convert line endings to make testCompactReport pass on Windows
* Add resolveFromConfigFile config option
Treats all paths as relative to the location of the config file, not
the current working directory of the process.
This commit just changes psalm, further commits will be needed to
apply the change to psalter and the LSP server.
* Copy asset xml files into project root for testing, delete during teardown
Needed since paths are now resolved relative to the position of the
file.
Not sure why I only saw a test failre for 1.xml - would have expected it
for all eight files.
* Fix following rebase
* Move psalm --init handly code above working directory setting code
If there's no psalm.xml yet we can't use the location of psalm.xml to
set our working directory
* Move Psalm version output code above working directory resolution
Working directory doesn't need to be known to output version constant
* Rely on new config file based working directory in end to end test
* Dont use rely on config dir for --alter - not currently working
* Fix code style error
* Add failing test for supporting config without `resolveFromConfigFile="true"`
* Don't treat config directory as a path to check
* Document resolveFromConfigFile setting
