* Fix going to definition on return type
If a return type of a method or function is set incorrectly (with the PHP doc), then the references are not added for the `function() : MyClass` symbol, so the "Go to definition" feature of the LSP won't work. I don't believe an invalid return type or not should stop the symbol location being tracked (and not allowing code navigation).
In moved the symbol location tracking to be before the return early short circuit.
* Update SymbolLookupTest.php
Co-authored-by: Matthew Brown <github@muglug.com>
Currently it's not possible to "Go to definition" (LSP) on nullable args like `function( ?MyClass )` as the reference is stored a `MyClass|null` in the reference map, which will now resolve to a class name.
This PR removed any nullable type from the union before adding it to the reference map (as the reference map is only use to indicate a symbol was used in a given location, I think this makes sense).
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.
This is useful for use cases such as saving multiline taint detection results.
Only the compact and console reports seem to use color right now.
In many cases, adding color codes to a text file would make it harder to read
in an editor.
E.g. `psalm --report=report.txt --report=report.pylint`.
It may be useful to have both a machine-readable and human readable
report, e.g. during taint analysis.
Previously, psalm would generate neither report if the report option was
repeated.
This change avoids calling `str_replace()` on the original docblock and
instead only operates on the parsed (and modified) lines. This now makes
it so that if there are substrings of the docblock that match a tag
match, it won't get prematurely removed, therefore avoiding mangling of
the parsed docblock's description.
Fixes: #3735