by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Tyson Andre
    @TysonAndre

    https://github.com/phan/phan/wiki/Issue-Types-Caught-by-Phan#compaterror - Phan's php version compatibility checks are more targeted as making sure that code you wrote in a newer php version wouldn't have syntax errors in older php versions (e.g. if you ran php 7.0 on some servers but 7.2 on other servers).

    https://www.php.net/manual/en/migration71.incompatible.php https://www.php.net/manual/en/migration72.incompatible.php some of these were changed to defaults (e.g. warning about non-countable to count()), others just aren't implemented

    but the output report doesn't flag any php version specific erorrs

    And Phan warns when you set --target-php-version 7.0 about functionality that required a newer version (it doesn't catch the subtler changes - I haven't looked into whether any projects do do that, but a plugin would be possible in theory for some of them)

    Also, in minor version releases, they aim to make as few incompatible changes as possible, but I'd still suggest looking at those links

    Tabakhase
    @tabakhase

    hm Im seeing some crazy again...
    (with docker -> codeclimate-phan engine that is)

    not sure yet what/where/who broke...

    error: (CC::CLI::Analyze::EngineFailure) engine phan failed with status 99 and stderr
    engine produced invalid output: {:message=>"Description must be present: `{\"type\"=>\"issue\", \"check_name\"=>\"PhanTypeInvalidDimOffset\", \"description\"=>nil, \"categories\"=>[\"Bug Risk\"], \"severity\"=>\"normal\",

    line in question is just a potential undef <?php echo $lang['MSG_TITLE']; ?>
    i also see a bunch of "correctly formated PhanTypeInvalidDimOffset" so it doesnt seem broken in itself

    and for the fun part

    • this fails on one CI server - but works fine on another one ...
      (and both use same CC & cc-phan image hashes....)
    Tyson Andre
    @TysonAndre
    My first guess is that it's trying to json_encode invalid utf-8 (e.g. for the array shape $lang) and that fails and makes the description null (in JSON_PARTIAL_OUTPUT_ON_ERROR). I'm not sure what would fail on different docker images.
        public static function jsonEncode($value) : string
        {
            $result = \json_encode($value, \JSON_UNESCAPED_SLASHES | \JSON_UNESCAPED_UNICODE | \JSON_PARTIAL_OUTPUT_ON_ERROR);
    mb_convert_encoding is useful if it's installed, e.g. this fragment would replace invalid codepoints such as "\x80" with as a placeholder
            ini_set('mbstring.substitute_character', 0xFFFD);
            $str = mb_convert_encoding($str, 'UTF-8', 'UTF-8');
    Tyson Andre
    @TysonAndre
    Tabakhase
    @tabakhase

    hm... invalid utf-8
    the file reported in that error itself is "clean" (pure ascii)
    key-wise $lang "should" be clean... but value-wise some of $lang is hebrew&french&chinese and has all sort of funny stuff in it...

    • so possible issue?

    and its the same docker-images...

    what actually pops opens a more intresting question
    -> adding this broken file into exclude results in "no change in issues" on the "is-ok" host ((so it never reported this issue ever)
    and actually comparing issue counts, the "not-ok" machine finds ~2000 more issues - (almost all PhanTypeInvalidDimOffset´s)
    -> appears this is consuming a larger number of files than the other
    ((currently i think thats to blame on codeclimate, but not sure yet))

    Tabakhase
    @tabakhase
    interestinglyphan is the only engine with diffrent issue-counts...
    everything else matches 1:1 wherever its run...
    (and i run basically "anything there is + customs" so phpstan, phan, phpcodesniffer, patternscan, runnerscripted, sonar-php, csslint, structure, duplication, phpmd, eslint, shellcheck, fixme, php7mar, php7cc)
    Tabakhase
    @tabakhase
    after some more digging, include_paths ends up beeing the same on both hosts
    • but the "order" defers - what breaks some, fixes some other inspections ;D (but thats another topic)
      with that i´d confirm "diffrent message for the error-file" and with that, utf8-issue is very likely to actually be "it"
    Adrian
    @adrian-enspired
    trying to run phan on @property-read SomeClass $some.class fails with a PhanUnextractableAnnotation. i've tried variations, like {$some.class} and ${"some.class"} without luck. I'm seeing this on version 1.1.10 - does anyone know if it's fixed in current versions?
    ...or if phan understands some other syntax?
    Tyson Andre
    @TysonAndre
    Only @property-read SomeClass $validPHPIdentifier is supported right now. I'm not aware of a phpdoc standard to allow escaped identifiers in @property
    I filed phan/phan#2938
    Adrian
    @adrian-enspired
    thanks!
    Adrian
    @adrian-enspired
    since updating to phan 2.2.3, i've been getting some false positive PhanUnreferencedClass errors. in all cases, the class is referenced once, and only like Classname::class - however, there are a number of classes used like this, and not all trigger the error. phan does find other errors in the same file, so i know it's not being excluded from analysis. any ideas?
    Adrian
    @adrian-enspired
    goes something like this, but i have not been able to figure out "why" well enough to reproduce reliably. Does seem to always happen to the same specific classes.
    namespace X\Y\Z;
    class Foo {}
    namespace A\B\C;
    use X\Y\Z\Foo;
    $something = Foo::class;
    Tyson Andre
    @TysonAndre
    It's probably because Phan switched to an AST_CLASS_NAME node instead of AST_CLASS_CONST node due to changes in php-ast. It only needed to look up the class (for the string literal value of $something when it was treated like a class constant, so now it's not referenced unless it sees $something used as a class-like
    e.g. this standalone file
    <?php
    namespace X\Y\Z;
    class Foo{}
    
    namespace A\B\C;
    use X\Y\Z\Foo;
    $something = Foo::class;
    I filed phan/phan#2945
    Adrian
    @adrian-enspired
    thanks again!
    permanovd
    @permanovd

    Hi!

    Is there a way to require types on every argument of function with phan (and return type too)?

    f.e.

      public static function getNameByUserId($id) {
        // ...
      }

    And phan will emit:

    • No type specified for argument $id.
    • No return type for function.

    Thanks.

    phan --plugin UnknownElementTypePlugin
    And suppress the issue types you don't plan to use initially
    permanovd
    @permanovd
    @TysonAndre Thank you :)
    Ghost
    @ghost~5d8ca8e1d73408ce4fcc1da7
    Hello.
    I have any question with a problem to exclude files from the check via Phan.
    I have a custom config, leave in the project directory ./.phan/config.php. Inside this config file is follow setting.
    'exclude_file_list' => [
        'Medoo.php',
        'SIDB5.php',
        'SIDB423.php',
    ],
    However, after ./vendor/bin/phan --allow-polyfill-parser it checks also this files.
    Thanks a lot for your time and helping.
    The files leave inside the directory ./-/, there is set as include.
    'directory_list' => [
        './-/',
    ],
    Tyson Andre
    @TysonAndre
    exclude_file_list are paths relative to the project root. Try -/Medoo.php or ./-/Medoo.php (I forget which). Or use exclude_file_regex, which allows you to pass patterns to match anything, e.g. those basenames
        // A regular expression to match files to be excluded
        // from parsing and analysis and will not be read at all.
        //
        // This is useful for excluding groups of test or example
        // directories/files, unanalyzable files, or files that
        // can't be removed for whatever reason.
        // (e.g. '@Test\.php$@', or '@vendor/.*/(tests|Tests)/@')
        'exclude_file_regex' => '@^vendor/.*/(tests?|Tests?)/@',
    --allow-polyfill-parser may affect whether issues get emitted, but it doesn't affect the list of files to parse/analyze
    Ghost
    @ghost~5d8ca8e1d73408ce4fcc1da7

    Thanks a lot for your fast reply.

    'exclude_file_list' => [
        '-/Medoo.php',
        '-/SIDB5.php',
        '-/SIDB423.php',
    ],

    That works. I tried before the path, like ./-/Medoo.php; but it not worked.

    Adrian
    @adrian-enspired
    using phan 2.4.1, i'm getting a PhanSuspiciousWeakTypeComparison with code like
    function foo(array $a = []) { return in_array('something', $a); }
    the message says "... $a of type (no types)" which i assume means it thinks the array is empty, when it reality it only might be empty (and might not, and in some (actual) code paths, IS not).
    ensuring $a has a @param array or whatever[] annotation does not clear the error.
    anyone know if this is intentional, or if there's a workaround (aside from suppressing)?
    Tyson Andre
    @TysonAndre
    I can reproduce it in 2.4.1. It's fixed on dev-master.
    I thought it was introduced in 2.4.2-dev, which is why the fix wasn't released yet
    Adrian
    @adrian-enspired
    thx!
    Lexidor Digital
    @lexidor
    Hi, I am so sorry for bothering you all (on new year's day). I've used phan in the past (while version 0.12.13 was still hot of the press). I tried to set up the vscode phan extension, but I must have made a mistake in the process. Running vendor/bin/phan on intentionally broken code reports errors as expected, but there is no red squiggle in the editor. I have the phan extension (1.2.0) enabled globally and I have composer-required phan. My phan.executablePath is set to /usr/bin/php. phan.analyzedProjectDirectory is set to the root of my project. My file association for .php is 'php'. The phan settings in .phan/settings.php check-out (else the stand-alone executable would not work).
    I just realized that I am the only person online. I'll try again tomorrow.
    Lexidor Digital
    @lexidor
    image.png
    Yep, a PEBCAK, as expected.
    Strange that vendor/bin/phan keeps running when it encounters this, but the extension stops running, oh well.
    Tyson Andre
    @TysonAndre

    vendor/bin/phan in phan.analyzedProjectDirectory is newer than the one in /home/lexidor/.vscode/... - The former has the plugin installed, but the latter doesn't. The former would also abort if passed a plugin that didn't exist.

    the phanScriptPath can be used to pass a path to phan or phan.phar

            "phan.phanScriptPath": {
              "type": [
                "string",
                "null"
              ],
              "default": null,
              "markdownDescription": "Optional (Advanced). If provided, this overrides the Phan script to use, e.g. `/path/to/phan_git_checkout/phan`. (Modifying requires restart)"
            },
    Tyson Andre
    @TysonAndre

    TysonAndre/vscode-php-phan#13 was in the backlog - the largest blocker for that is not having seen any similar language client code to base it or other language client features off of.

    Also, I published vscode-php-phan 1.2.1 just now, which updated the bundled phan from 2.3.1 to 2.4.6 (which has that plugin).

    Lexidor Digital
    @lexidor
    Thanks a ton. I did not know that vscode-php-phan bundled a phan version. I thought it grabbed the one in vendor/bin/phan. Thanks a ton for the new version!
    Sarel van der Walt
    @sarelvdwalt

    I'm being dumb here I think... my composer.json has php version requirement set to >=7.1

        "require": {
            "php": ">=7.1",

    My php version is actually 7.3.14, so that is still in line with the settings.
    When I run php vendor/bin/phan --color I get, among others, this:
    src/AH/AQueueBundle/Manager/QueueManager.php:13 PhanUndeclaredTypeProperty Property \AH\AQueueBundle\Manager\QueueManager->em has undeclared type \Doctrine\ORM\EntityManager

    Here's the thing though, that's only an issue for 7.4 - and only fixable if you use the php 7.4 way of declaring it.

    The code in question is this:

    class QueueManager
    {
        /** @var EntityManager $em */
        protected $em;
    
        /** @var EntityRepository $repo */
        protected $repo;
    If I change it to protected EntityManager @em then I get (as expected) a PhanSyntaxError because that's a 7.4 thing and I'm on 7.3.