psalm / psalm.dev Goto Github PK

https://getpsalm.org/r/8c745449ed

<?php

$foo = true ? 'foo';

the home page code editor has no feedback for parse errors, so it looks like everything is fine, or that getpsalm.org is not working until you click the "get link" button.

whilst one can write code up on psalm.dev to check if a given set of code passes/fails psalm, it may be beneficial to have a more focused tool for determining if a given value type is compatible against another type (i.e. param/return).

ideally something like one of those online regex tools that give you an input for the type and an input for the thing to test against, with optional debug-level breakdown.

may require a third field for "stubs".

does psalm already expose apis for "input type string, test against type string" or would this be a massive headache?

@muglug currently all snippets are failing with:

Psalm runner output:

Internal Psalm error on line 51 - /var/www/vhosts/psalm.dev/httpdocs/src/OnlineChecker.php: Call to undefined method Psalm\Internal\Analyzer\ProjectAnalyzer::checkClassReferences()

I suppose OnlineChecker relied on internal API that got changed.

Today I learn that psalm.dev has support for different PHP version via query parameter - vimeo/psalm#5442 (comment)

So It would be really helpfull for users if there was an clear choice to choose used PHP version on the UI itself.

This option doesn't exist in psalm (anymore?)?

Recently psalm.dev started being extremely slow for me. For example, opening https://psalm.dev/r/33c0431227 took over 40 seconds until onload:

I also noticed github bot respons delays, which hints at performance issues at psalm.dev

You can access .git folder from https://psalm.dev (e.g.. https://psalm.dev/.git/config) and you can download it.
If you download the .git folder you can inspect the committed files and read the history. This is not the case but theoretically this could be a security issue if some secret is pushed.

(If there's an article of the same name, prioritize that over the automatically generated name)

E.g. http://php.net/is_array does something similar. The canonical url is https://www.php.net/manual/en/function.is-array.php

This would help developers looking at issues reported in different file formats.

I'm not familiar with the static site generator used here. HTML <meta> redirects should be possible on static hosting.

Pls add RSS feed for https://psalm.dev/articles, one could then subscribe using something like Feedly and not miss out on any news!

The upgrade guide is available here: https://codemirror.net/docs/migration/

To sum up, everything has changed, so we may just as well use something else.

The rationale for upgrading is mostly small syntax highlighting annoyances.

Combined with #12, this would allow blog posts (such as your own) to have error-highlighted code examples as post embeds.

Best combined with #12 for archival purposes.

It would be great if various psalm versions could be checked using query param, similar to how different PHP versions can be passed via query param.
e.g. at least the last v4 + all the v5 versions.

This would often help to identify if an issue already existed previously/worked correctly in previous versions.

Starting a thread here from vimeo/psalm#7537

https://psalm.dev/r/dad1de849f (click Fix code button).

Results in :

<br />
<b>Notice</b>:  Uninitialized string offset: 14 in <b>/var/www/vhosts/psalm.dev/httpdocs/vendor/vimeo/psalm/src/Psalm/FileManipulation.php</b> on line <b>62</b><br />
{"results":[],"version":"dev-master@bf569d1b07a56f9d5a42af102e4465182e33c187","fixed_contents":"<?php\n","hash":"a559a8d3e218ba361a1a6d790b194c79","type_map":[],"fixable_errors":[]}

Which cannot be parsed as JSON.

Can this be done with composer update put into, say, cron.hourly?

Hello guys.

I'm having a small issue with Psalm. I can't tell if I'm doing anything wrong or it's a known issue or simply a bug.

Can anybody help me with this?

https://psalm.dev/r/8de151ce74

Enabling button

• If route matches /r/{token:[a-f0-9]+} and
• If textarea#code has not changed then
• Enable button that copies the content into a pre-filled issue-template featuring github-flavoured markdown to easily post an issue on vimeo/psalm

Disabling button

• If textarea#code is changed, or
• Route does not match /r/{token:[a-f0-9]+} then
• Disable button

When posting a lot of code on psalm.dev then it will always show "Internal Psalm error on line undefined - undefined" error

Originally reported by @kkmuffme in vimeo/psalm#3239

what's the cpu usage/risk of running php -l on code alongside psalm?

re: vimeo/psalm#1666

see bottom right sidebar, e.g at https://psalm.dev/docs/running_psalm/configuration/

https://psalm.dev/docs/annotating_code/type_syntax/atomic_types/ has array\<int, string>, but array<int, string> is expected

I haven't looked into whether this was previously escaped differently.

&...; encoding may work (<)

1. click on https://psalm.dev/r/f5c8212ac4
2. go to settings, check "Force return types to be as tight as possible"
3. observe that issues are now highlighted
4. click on "Get link"
5. page refreshes, issues are not highlighted anymore and option is unchecked

As someone wanting to read the documentation

if would be nice if there were prev/next links on
https://psalm.dev/docs/running_psalm/issues/AbstractMethodCall/

Previous being AbstractInstantiation
and next being ArgumentTypeCoercion

I'm not familiar with MKDocs, but I'm guessing this is possible

how feasible would it to have a psalm baseline editor window, for replicating issues like vimeo/psalm#2815 ?

Currently I'm getting the following while trying to run a snippet:

Notice: Undefined index: /var/www/vhosts/psalm.dev/httpdocs/src/../src/somefile.php in /var/www/vhosts/psalm.dev/httpdocs/src/OnlineChecker.php on line 129

Warning: ksort() expects parameter 1 to be array, null given in /var/www/vhosts/psalm.dev/httpdocs/src/OnlineChecker.php on line 133

Warning: Invalid argument supplied for foreach() in /var/www/vhosts/psalm.dev/httpdocs/src/OnlineChecker.php on line 135
{"results":[],"version":"dev-master@91638781746519c5d03c18bd37b0725adfd0974d","fixed_contents":null,"hash":"fa8da89d01b934beb72cfe84bb636624","type_map":[]}

After the applied fix of vimeo/psalm#7609 via #72 the highlighting got broken.

See: https://psalm.dev/r/8754ae5fb4
Or screenshot here vimeo/psalm#7609 (comment)

from @tomtomau

To report errors of dead code detection not working as expected, it would be awesome to be able to enable this option from the web previewer. It would probably make sense to be off by default though.

(I'd send a PR but I'm not sure how to update CM here.)

I've recently contributed (codemirror/codemirror5#6816) new-ish PHP keywords to the CodeMirror editor. These changes have now been released as CodeMirror 5.64.0, so feel free to update the editor :)

$ docker-compose exec php-apache composer install
Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Nothing to install, update or remove
Package league/commonmark-ext-table is abandoned, you should avoid using it. Use league/commonmark instead.
Generating autoload files
composer/package-versions-deprecated: Generating version class...
composer/package-versions-deprecated: ...done generating version class
17 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> composer bin all install
Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Package operations: 21 installs, 0 updates, 0 removals
    Failed to download psr/simple-cache from dist: The zip extension and unzip/7z commands are both missing, skipping.
Your command-line PHP is using multiple ini files. Run `php --ini` to show them.
    Now trying to download from source


  [RuntimeException]
  git was not found in your PATH, skipping source download


install [--prefer-source] [--prefer-dist] [--prefer-install PREFER-INSTALL] [--dry-run] [--dev] [--no-suggest] [--no-dev] [--no-autoloader] [--no-scripts] [--no-progress] [--no-install] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--apcu-autoloader-prefix APCU-AUTOLOADER-PREFIX] [--ignore-platform-req IGNORE-PLATFORM-REQ] [--ignore-platform-reqs] [--] [<packages>]...

Script composer bin all install handling the post-install-cmd event returned with error code 1

Probably it's best to add both git and unzip to the Dockerfile.

Hi,

I was looking to see if I was able to push a PR to add Psalter to the website but unless I'm mistaken, there seems to already be code for that.

Either I never found out how it's supposed to work or it's not actually working.

Should I go forward and try to implement it?

Since a couple of days the font seems to have changed to Times New Roman. In my opinion it is now very hard to read the documentation, as the font is very thin (see the image below).

I think this is a bug, since I get a HTTP status 404 for the file https://cloud.typography.com/751592/7707372/css/fonts.css.

https://psalm.dev/r/e4eb7a3e05

Issue is from line 15, key-of<TMapping> seems to break it.

https://psalm.dev/r/845866d4c7

In:

fix_button.parentNode.removeChild(fix_button);

With Composer 2.1 default download method changed to zip/dist (changelog entry, PR), even for dev-* versions. This means .gitattributes of dependencies are no longer ignored, specifically vimeo/psalm:dev-master no longer brings along vendor/vimeo/psalm/tests folder.

This causes issues when dependencies are installed in a freshly built container, as vendor/vimeo/psalm/tests/Internal/Provider/FakeFileProvider.php (required in src/OnlineChecker.php) is not available when installed this way.

https://psalm.dev/r/62bd6e1edb

seems like it would trigger a json decoding exception, but triggers Warning: Use of undefined constant JSON_THROW_ON_ERROR - assumed 'JSON_THROW_ON_ERROR'

Hello, I faced an issue Not all code paths of foo end in a return statement while the method either throw an exception or returns the right value inside a try/finally

https://psalm.dev/r/b429a9a176

Today I accidentally broke psalm.dev by careless merge. I kinda assumed schema changes would get applied automatically, but they aren't.

We need a way to automatically deploy schema changes, so some kind of SQL migration engine is needed.

It's really easy to drop all your changes on the https://psalm.dev/ sandbox if you follow one of the links from the error report.
I think there should be a confirmation window before leaving the sandbox with non-default content, or probably open a new window for these links, or saving the code in the LocalStorage and restore it.

When using psalm.dev to attempt to reproduce an error only to find there's no errors in the reduced example code, it's not always feasible to immediately update a project to dev-master to see if the problem goes away.

How feasible is it to allow end-users to select a version of psalm to test against?

https://psalm.dev/docs/annotating_code/supported_annotations/#pure-callable is in supported_annotations. I'd expect it in https://psalm.dev/docs/annotating_code/type_syntax/atomic_types/ instead?

• Can be used to stub out third-party code
• Could be used as informal stub proposal prior to making pull requests

Go to https://psalm.dev/docs/annotating_code/supported_annotations/
Check "PHPDoc tags" subsection. There is a list of supported PHPDoc annotations. Each annotation specified in the list, probably, was supposed to occupy an individual line. However, the whole list is on the single one.

Checked on Firefox 72 and Chrome 79

https://cloud.typography.com/751592/7707372/css/fonts.css 404 (Not Found)

on https://psalm.dev/r/3d33f66c11

--- a/assets/sass/front.scss
+++ b/assets/sass/front.scss
@@ -73,6 +73,10 @@ div.cm_container {
     }
 }
 
+#psalm_output {
+    white-space: pre-wrap;
+}
+

I didn't see the exact command you used to produce the assets anywhere

The pre-wrap means that long errors continue to wrap to the next line.

This fixes the formatting of error messages such as for the following (should have multiple spaces in the web UI, but those previously got collapsed)

<?php
  
var_export('test   x' === 'test x');

vimeo/psalm#6989 reported a case where psalm is failing due to an assert() in php-parser but psalm.dev continues the analysis. I think psalm.dev should behave as if we were in dev environment because this is usually the way Psalm runs

When working on a change locally I noticed failed http requests to /extra/*ttf URLs. It appears that folder is supposed to contain fonts, but it's missing from the source tree, and not generated during the build either.