Bruce Weirdan

This is basically how Composer works, and building Psalm from GitHub snapshots isn't exactly a supported installation method. We use COMPOSER_ROOT_VERSION in CI ourselves: https://github.com/vimeo/psalm/blob/d3c1222152e000b6a81f37e0a1728b85c38c3659/.github/workflows/ci.yml#L45-L48 It could be added to...

Actually that's not what I meant. I was thinking about adding two more doc pages: * Alternative installation methods: deb, rpm, brew formulas, arch AUR, phive, etc. * Packaging Psalm:...

I think @sebcode meant https://github.com/vimeo/psalm/blob/c620f6e80d0abfca532b00bda366062aaedf6e5d/src/Psalm/Internal/Analyzer/ClassAnalyzer.php#L1795 (in `analyzeClassMethod()`). Removing that line indeed 'fixes' the issue, but without it issues in other class methods (e.g. `b()`) disappear as soon as you edit...

Actually, it's not specific to the LSP environment. Running Psalm in CLI first, removing that line and re-running Psalm results in the same issue reported. It's a bug in how...

> Cause it's not a valid syntax supported by callable It is valid syntax (an alias for `callable(mixed...)`), see https://github.com/vimeo/psalm/blob/6140f6881c3a83eca20be295454562ced3645255/tests/TypeParseTest.php#L747-L753

It also appears to depend on how the callable is created/referenced: https://psalm.dev/r/5a07f093b5

@azjezz can you make sure the PSL commit you're running this on is accessible somewhere?

Psalm just needs a little help: https://psalm.dev/r/df9f6e0be7

References are intrinsically problematic to analyze (see https://en.wikipedia.org/wiki/Action_at_a_distance_(computer_programming)) , so I would say yes. You can rewrite this as a class where (hidden) references are (implicitly) typed, so providing this...

And you autoload config from `composer.json` too.