Error parsing \Doctrine\ODM\MongoDB\Aggregation\Stage\GraphLookup\Match with php8

[antonmarin]

wrong usage or bug?

is there any way to ignore this file as it is not used in project?

sh-4.2$ php -v
PHP 8.0.7 (cli) (built: Jun 16 2021 12:25:08) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.7, Copyright (c) Zend Technologies
    with Zend OPcache v8.0.7, Copyright (c), by Zend Technologies
    with Xdebug v3.0.4, Copyright (c) 2002-2021, by Derick Rethans

sh-4.2$ php ${PWD}/composer-require-checker.phar check --ignore-parse-errors --config-file=${PWD}/composer-check-requirements.json ${PWD}/composer.json
ComposerRequireChecker 3.3.0@4063254c611acf34f1c15b29b6bcc47d2e7a9a9e

In LocateASTFromFiles.php line 50:
                                                                                                                                                          
  Parsing the file [${PWD_FOLDER_HERE}/vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Aggregation/Stage/GraphLookup/Match.php] resulted in an error.  

//composer-check-requirements.json
{
    "symbol-whitelist": [
        "array",
        "bool",
        "callable",
        "false",
        "fastcgi_finish_request",
        "float",
        "int",
        "iterable",
        "null",
        "object",
        "parent",
        "self",
        "static",
        "string",
        "true",
        "void",
        "last",

        "tideways_xhprof_disable",
        "tideways_xhprof_enable",
        "TIDEWAYS_XHPROF_FLAGS_CPU",
        "TIDEWAYS_XHPROF_FLAGS_MEMORY",

        "Google\\Authenticator\\GoogleAuthenticator"
    ],
    "php-core-extensions": [
        "Core",
        "Phar",
        "Reflection",
        "SPL",
        "date",
        "pcre",
        "standard"
    ],
    "scan-files": [
        //some not related files here
    ]
}

//composer.json
...
    "autoload": {
        "psr-4": {
            "": "src"
        },
        "classmap": [
            // several Kernels here
            "some_dir/Kernel.php",
        ]
    },
    "autoload-dev": {
        "psr-4": {
            "Tests\\Unit\\": "tests/unit",
            "Tests\\Integration\\": "tests/integration",
            "Tests\\Functional\\": "tests/functional",
        }
    }

[Ocramius]

I suggest installing maglnet/composer-require-checker via composer in an isolated directory: this problem is caused by an outdated nikic/php-parser version in use inside the .phar release.

Also see:

• #140
• #256
• #281

Meanwhile, closing this, as the issue is with the dependencies of this tool, not the tool itself.

[antonmarin]

I can't use composer global installation in my CI pipeline, so can you publish docker image? I can create pr with Dockerfile

[Ocramius]

You can do following:

mkdir -p tools/composer-require-checker
cd tools/composer-require-checker
echo "{}" > composer.json
composer require maglnet/composer-require-checker
cd -
tools/composer-require-checker/vendor/bin/composer-require-checker

My endorsed approach would be to have a composer.json and a composer.lock under tools/composer-require-checker

[Ocramius]

Also avoid composer global: it's just trouble.

[antonmarin]

I see now. Looks strange )) This way creates some difficulties with building. Mb docker image would be more simple to use?

[Ocramius]

Mb docker image would be more simple to use?

It would have the same problems of a .phar release, with the addition of multiple system-level CVEs on top of it.

[antonmarin]

I mean, i can create PR with Dockerfile with tool installed the way you offered. Then maintainer can publish it in dockerhub. I think it would be simple to use and support. Users would use smth like docker run -v $PWD:/app $repo and maintainers don't do anything, as dockerhub would update image automatically on tag or master(on your choice)

[antonmarin]

Update: I tried the way you offered in #issuecomment-878953040 and got the same error

[Ocramius]

Users would use smth like docker run -v $PWD:/app $repo and maintainers don't do anything, as dockerhub would update image automatically on tag or master(on your choice)

Problem with that is keeping an updated composer.lock that works for everyone. People running on PHP 7.4 and people running on PHP 8.0 have different requirements (like this bug shows). The combinatory explosion is too much to handle, and it is better to just let people install the set of dependencies that works best for them.

Re-opening as per https://github.com/maglnet/ComposerRequireChecker/issues/283#issuecomment-878965126, since the proposed solution didn't solve the problem

[Ocramius]

I think what needs to happen in your case, is that nikic/php-parser needs to be initialized in PHP 7.4 mode.

If you load vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Aggregation/Stage/GraphLookup/Match.php (try php vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Aggregation/Stage/GraphLookup/Match.php ), you will probably already get a crash if you are on PHP 8.

[antonmarin]

sh-4.2$ pwd
${project_folder}/tools/composer-require-checker

sh-4.2$ php vendor/bin/composer-require-checker check --ignore-parse-errors -vvv --config-file=${project_folder}/composer-check-requirements.json ${project_folder}/composer.json
ComposerRequireChecker 3.3.0@4063254c611acf34f1c15b29b6bcc47d2e7a9a9e
Collecting defined vendor symbols... 
In LocateASTFromFiles.php line 50:
                                                                                                                                                          
  [RuntimeException]                                                                                                                                      
  Parsing the file [${project_folder}/vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Aggregation/Stage/GraphLookup/Match.php] resulted in an error.  
                                                                                                                                                          

Exception trace:
  at ${project_folder}/tools/composer-require-checker/vendor/maglnet/composer-require-checker/src/ComposerRequireChecker/ASTLocator/LocateASTFromFiles.php:50
 ComposerRequireChecker\ASTLocator\LocateASTFromFiles->__invoke() at ${project_folder}/tools/composer-require-checker/vendor/maglnet/composer-require-checker/src/ComposerRequireChecker/DefinedSymbolsLocator/LocateDefinedSymbolsFromASTRoots.php:34
 ComposerRequireChecker\DefinedSymbolsLocator\LocateDefinedSymbolsFromASTRoots->__invoke() at ${project_folder}/tools/composer-require-checker/vendor/maglnet/composer-require-checker/src/ComposerRequireChecker/Cli/CheckCommand.php:112
 ComposerRequireChecker\Cli\CheckCommand->execute() at ${project_folder}/tools/composer-require-checker/vendor/symfony/console/Command/Command.php:299
 Symfony\Component\Console\Command\Command->run() at ${project_folder}/tools/composer-require-checker/vendor/symfony/console/Application.php:978
 Symfony\Component\Console\Application->doRunCommand() at ${project_folder}/tools/composer-require-checker/vendor/symfony/console/Application.php:295
 Symfony\Component\Console\Application->doRun() at ${project_folder}/tools/composer-require-checker/vendor/symfony/console/Application.php:167
 Symfony\Component\Console\Application->run() at ${project_folder}/tools/composer-require-checker/vendor/maglnet/composer-require-checker/bin/composer-require-checker.php:32
 include() at ${project_folder}/tools/composer-require-checker/vendor/maglnet/composer-require-checker/bin/composer-require-checker:3

[Ocramius]

No, I mean that trying the Match.php file from PHP itself will fail on PHP 8.

This is likely due to this deprecation: https://github.com/doctrine/mongodb-odm/blob/85d2b9f9664517ca0ece48547be3e68f7a2a2e8f/lib/Doctrine/ODM/MongoDB/Aggregation/Stage/Match.php#L12

[antonmarin]

Problem with that is keeping an updated composer.lock that works for everyone. People running on PHP 7.4 and people running on PHP 8.0 have different requirements (like this bug shows). The combinatory explosion is too much to handle, and it is better to just let people install the set of dependencies that works best for them.

Seems like require-checker is used as a part of project, as phpstan do, so mb it should be used as composer require --dev?

No, I mean that trying the Match.php file from PHP itself will fail on PHP 8.

Yep, php fails run it, and it's expected. Unexpected is that Match is not used anywhere including vendor files, so i don't understand why tool tries to load it. Is any way to exclude it? (i've already tried exclude-from-classmap and it didn't help as this class is not in classmap)

Update: And one more unexpected that --ignore-parse-errors not ignored this Parse error.

sh-4.2$ php vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Aggregation/Stage/GraphLookup/Match.php
[13-Jul-2021 10:44:49 UTC] PHP Parse error:  syntax error, unexpected token "match", expecting identifier in ${project_path}/vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Aggregation/Stage/GraphLookup/Match.php on line 15

[Ocramius]

i don't understand why tool tries to load it

This tool tries to scan for all defined symbols eagerly, so that we have a map of which component declares which symbol. Since PHP autoloading does not work with functions, this means that every file declared in autoload: definitions in every dependency is scanned.

Is any way to exclude it?

As far as I know, we haven't built any exclusion map yet: that would be an interesting addition.

[antonmarin]

I see now. So seems like there are 2 ways to fix my error:

1. Identify why --ignore-parse-errors didn't work in this case
2. Implement a way to exclude some files from scan

Am i right?

[Ocramius]

Identify why --ignore-parse-errors didn't work in this case

This certainly requires investigation, since this is 100% a parse error

Implement a way to exclude some files from scan

Feasible too, but only after having investigated the first bit.

Sorry for the detour around dependency management!