Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Tabakhase
    @tabakhase
    Hey there, has 'directory_list' changed on how its handled? -- using codeclimate, they did a update ~22h ago and now all reports are "empty" -- changing directory_list to "../src" seems to fix that, but to my understanding those paths should be from project-root, not relative to the cfg where that block is in (whats /.phan/config.php)
    Tabakhase
    @tabakhase
    Tyson Andre
    @TysonAndre
    Filed phan/phan#2139 to track this, will take a look when I have free time
    Tabakhase
    @tabakhase

    looking into a blame on the engine-file poked me onto this phan/phan@f2ffee6
    "fixed bugs in codeclimate engine" from 10 months ago - and if i see that right, b726 on the hub is a year old

    • so this change never made it in "until now"?
      given that, im not even sure what would be the correct form to sepc the paths, with or without ../?
      maybe my paths were wrong all along and "my real fix" would be using force-codeclimate-filelist: true...

    other than that, seems like a nice update Code quality improved on 108 points and degraded on 741 points :thumbsup:

    docker inspect codeclimate/codeclimate-phan:b726 | grep '"Created":'
            "Created": "2017-12-18T22:30:14.056701617Z",
    the commit is from 20 Jan 2018
    Adrian
    @adrian-enspired
    After updating from 1.1.2 to 1.1.7, phan warns about PhanTypeComparisonToInvalidClass for the following: if (__CLASS__ !== get_class($this)). I don't follow what is "impossible/invalid" about this comparison. Phan seems to be resolving CLASS correctly (the complete, correct classname appears in the report).
    Tyson Andre
    @TysonAndre
    That should be fixed in 1.1.8-dev (https://github.com/phan/phan/pull/2228/files#diff-fe3f5566ae0d5d7d5106da433415a18a) - Phan was previously incorrectly inferring that __CLASS__ started with a backslash (it doesn't)
    Adrian
    @adrian-enspired
    thx!
    DemonicKrace
    @DemonicKrace
    Hi, I got a mission to update a project's(orginal php project, very old project, no use any framework) php version from php 5.6 to php 7.2. And I only want to analyze code forward compatible. Anyone have any good idea to set /.phan/conifg.php? thx!
    Tyson Andre
    @TysonAndre

    You might also want to look at php7cc and php7mar (other tools have been written since then, but I'm not that familiar with them). Phan has some incompatibility checks, but it's not the main focus of this project

    https://github.com/phan/phan/wiki/Incrementally-Strengthening-Analysis#just-backward-compatibility describes config settings that may be useful during the migration.

    phan --init creates a reasonable default if you're asking how to create a phan config(it has options to create without composer - see phan --help for details)

    https://github.com/gisostallenberg/php-to-7-aid - I haven't ever used that, but that was also mentioned in a blog post I saw
    https://github.com/phan/phan/tree/master/.phan/plugins#invokephpnativesyntaxcheckpluginphp may also help during a migration to avoid causing syntax errors in php 5.6 (if set up with both a php 5.6 and 7.2 binary)
    DemonicKrace
    @DemonicKrace
    Thanks for your info!
    Adrian
    @adrian-enspired
    phan is telling me that fqcn::class is an undeclared class constant. I thought I'd seen a github issue for this, but can't find it now. Anyone know if this is a known issue?
    Tyson Andre
    @TysonAndre
    That usually happens when the class fqcn hasn't been parsed by Phan (i.e. not in a configured directory).
    Adrian
    @adrian-enspired
    ahh... that makes sense. thanks!
    Tabakhase
    @tabakhase
    @TysonAndre uhm, phan/phan@0cdcd68 made it onto the codeclimate docker-hub "3 hours ago"...
    is there a chance to downgrade this from alpine:3.9 to alpine:3.8? php5-* packages are not in 3.9 :/ https://pkgs.alpinelinux.org/contents?file=&path=&name=php5-*&branch=v3.9&repo=main&arch=x86_64
    (wanting it for php_native_syntax_check_binaries)
    Oli Griffiths
    @oligriffiths
    Can anyone explain why the class name of a FQSEN is lowercased? https://github.com/phan/phan/blob/master/src/Phan/Language/Context.php#L160
    I am working on an autoloader to autoload classes when analyzing, but the classname being passed to hasClassWithFQSEN is lowercased
    Oli Griffiths
    @oligriffiths
    @TysonAndre are you able to explain?
    Tyson Andre
    @TysonAndre
    $namespace_map_entry = $this->namespace_map[$map_flags][$name] ?? null; - $name needs to be lowercased because namespaces are case-insensitive and a canonical version is needed to add/look up in namespace_map - if you call hasClassWithFQSEN use a different variable
    Tyson Andre
    @TysonAndre

    phan/phan@0cdcd68 made it onto the codeclimate docker-hub "3 hours ago"...
    is there a chance to downgrade this from alpine:3.9 to alpine:3.8? php5-* packages are not in 3.9 :/ https://pkgs.alpinelinux.org/contents?file=&path=&name=php5-*&branch=v3.9&repo=main&arch=x86_64
    (wanting it for php_native_syntax_check_binaries)

    No - That doesn't seem like a common use case, php 5 wouldn't be supported by up to date OSes, and I'm not sure how you're extending that. If you're using codeclimate as a base (i.e. not codeclimate the website), you could fork https://github.com/phan/phan/blob/master/plugins/codeclimate/Dockerfile and build that yourself.

    Downgrading would eventually cause problems with new php releases using new libraries/compiler features, so I don't plan to do that

    Tabakhase
    @tabakhase

    I'm not sure how you're extending that.

    gitlab-ci - and then "cc reports in merge-requests" -- so driven by owncode pipelines, i can hack in some handy
    - if [ $(echo "$CODECLIMATE_PARTRUN" | grep -E '^phan' | wc -l) -ge 1 ]; then { echo -e "FROM codeclimate/codeclimate-phan:latest\n USER root\n RUN apk add --no-cache php5 php5-cli php5-common php5-calendar php5-curl php5-dom php5-gd php5-json php5-mcrypt php5-mysqli php5-openssl php5-posix php5-soap php5-xml php5-zlib\n USER app"; } | docker build --pull -t "codeclimate/codeclimate-phan:latest" -; fi
    and agree its kinda edgy,
    that question to downgrade was more a joke in a "uff, my ci just broke :/" moment
    ((i run lint-php-parallel so its not like i actually need it ether i guess, was just poking for the quickest fix)) ;)
    so no stress on this at all =) @TysonAndre

    Oli Griffiths
    @oligriffiths
    @TysonAndre yeah I figured that was the case. The issue is that makes it almost impossible to lookup a class in composer as it is case sensitive.
    111111111
    @deadpahn
    I'm trying to run PHAN in a way to see what compatibility issues I will run into from upgrading php7.0 to 7.2. I can find the correct arguments to do this. I have set " 'target_php_version' => '7.2'," but the output report doesn't flag any php version specific erorrs, or at least I'm not seeing them.
    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 :)