This is a first pass at adding annotations to handle suppressing rules, as per #10. I do not consider it done, or even close to it. I expect there will be at least one or two refactoring passes, maybe more, as this is kind of brute force. I also expect that the annotation format might change.

That said, it does work and implements ignore and no-ignore annotations (namespaced to @psecio\parse\ignore and @psecio\parse\no-ignore). The annotations can be applied to any code level as long as you are using a doc block. The annotation parsing is also case-insensitive at the moment. So the following should all be valid:

/**
 * @psecio\parse\ignore DisplayErrors
 */
class Foo
{
    /**
     * @psecio\parse\ignore GlobalsUse
     */
    public function bar()
    {
        /** @Psecio\Parse\Ignore logicaloperators */
        if ($a and $b) {
            echo "BAZ!";
        }
    }
}

I've included a couple of files to test against in tests/testFiles/annotation-tests/. There's also in-code notes on how the annotation parser can be made more versatile.

What's missing

(that I'm aware of)

• reporting errors on invalid annotations or bad rule names
• unit tests
• --ignore-annotations

For rule names, I'd like to eventually have it complain if either of the following occur:

• Disabled rule: rule exists but disabled on the command line
• Invalid rule: rule does not exist

Possible refactorings

(in no particular order but numbered for reference):

1. Pull annotation parsing into a helper class.
2. Somehow "plug in" to CallbackVisitor rather than occupying it. This could be hooks, or additional callbacks added. It's a little tricky, because the visitor needs to know what the annotation parsing adds and removes.
3. Something else?

Conclusion

I'm open to any and all suggestions. I'll probably be working on this again tomorrow night, but it's hard to say for sure.

This replaces PR #23. Please see discussion there, but continue here. The new PR was necessary because I bungled merging in #25. I might have been able to recover, but this was easier.

This PR implements most of @hanneskod's suggestions for #23, with some modifications.

I also flattened the tests directory structure a bit by switching to PSR-4 on the tests. I went ahead and applied this to all the tests, not just the ones created here. I'd recommend doing this for the whole project. Makes it much cleaner.

Hello. I research about analyzers. In them, parser not be able to recognize include, require and etc expression. I want to know, how dose your program recognize path? Did you use other library or tools? or did you develop this part in your app?

Thank you.

Implements Issue #22.

Under tests/Psecio/Parse, implemented ParseTest.php, ParseTestVisitor.php and Tests/TestSessionRegenFalse_ParseTest.php (yeah, crazy name there. May need to figure out a better naming convention).

• ParseTest.php implements an abstract base class for all the parsing-based tests.
• ParseTestVisitor.php implements a simple parse tree visitor for use in testing.
• Tests/TestSessionRegenFalse_ParseTest.php implements several parse string tests for TestSessionRegenFalse, including one for the problem I found and fixed in PR #15.
• Tests/TestAvoidGlobalsUse_ParseTest.php implements parse string tests for TestAvoidGlobalsUse.

Implementing a test is as simple as creating a test case that extends \tests\Psecio\Parse\ParseTest. It must implement parseSampleProvider() and buildTest(). The buildTest() method should return an instance of the unit under test (e.g. TestSessionRegenFalse). Then parseSampleProvider() should return a list of PHP code string (with initial <?php omitted) and result pairs. Each PHP code string will be parsed, with the results evaluated against the results of buildTest() via the PhpParser\NodeTraverser. If the results match the result value, the test passes. Otherwise, it fails.

Both phpcs and phpmd support special comments that suppress the reporting for certain files, checks or sections of a code.

This would be a good addition for reducing 'noise' for cases where you know an error will be reported, but you are aware of its implications and see no way around it (for example, if the file is auo-generated by some tool).

I know in #87 you expressed some hesitation about using newer versions of dependencies, so allow me to explain what I've done.

• ~~My first commit just removed the old version numbers where a newer one was already given as an option.~~
• ~~You may wonder why I updated the PHP version requirement from 5.4 to 5.5.9; that's because some of the deps already required a minimum of 5.5.9 (for the newer versions), plus there's no need to support anything older if it's already been EOL for some time.~~
• ~~Then in the next one, I updated php-parser and phpunit, ran the tests, and updated the code and tests to reflect the changes in php-parser ^3.0.~~
• ~~Before I changed anything in composer.json, I ran the tests and noticed one test failing. After updating the versions, the code, and the tests, the same test was still failing.~~
• ~~After making my updates, I did start having trouble with the integration test causing a fatal error. My dev environment did have xdebug enabled, but the error I was getting wasn't the one you documented. It seemed very odd to me, but I would be interested to see if it would still show up if xdebug were taken out of the picture.~~

If there's anything you're not comfortable with, let me know and I'll change it back. ~~Also, if you have any ideas on why the integration test might be failing, I'd love to hear them. I spent a while trying to track it down and I didn't find any reason for the particular object being null at that point. What's weirder: when I added a line of debugging code, it went away. Makes no sense at all.~~

I'm trying to run parse against my codebase, but after a while it stops with this:

Fatal error: Maximum function nesting level of '100' reached, aborting! in /home/nick/testcomposer/vendor/psecio/parse/src/Psecio/Parse/TestCollection.php on line 45

It spits out a stack trace, but doesn't give any idea to what file it was working on when it had the problem. Is there any way to debug this?

A lot of renaming :smile:

Some devitaions from @redbeardcreator's suggestion:

• SessionRegenerateId instead of SessionRegen
• A simple Eval was not possible as the name collides with the actual eval() function. I used EvalFunction instead.

I put the naming convention in CONTRIBUTING.md, along with some other guidelines (see if you like).

I also moved ParseTest to the Rule namespace as Rule\RuleTestCase and made some minor changes to comply with psr-2.

Instead of changing the list-tests command to list-rules I opted for info. I have this idea that we could supply more educational help about to checks being made using the info command

psecio-parse info logicaloperators

I will describe this idea more clearly another day (now sleep!) :smile:

Merging will close #49.

Adds getLongDescription to rules and displays said descriptions with RulesCommand.

DocblockDescriptionTrait reads description and long description from the class level doc comment. Se src/Rule/DisplayErrors.php for a concrete example. And execute bin/psecio-parse rules displayerrors to view the generated output.

eloquent/blox is used to parse the docblock.

RuleCollection rewritten to be case insensitive.

Merging will close #11.

If I understand the intent of TestLogicalOperatorsFound correctly this is how I think it should be written.

The use of PhpParser\Node\Expr\BinaryOp\NotIdentical confused me, I don't think I understand what this test did before. It didn't really work though as it issued a warning when scanning this code (due to the or at the end of $operator):

if (stristr($line, $operator) !== false) {
    // ...
}

With this pr this code pass the test

if (true && true) {
   // ...
}

And this code fails the test

if (true and true) {
   // ...
}

Is that how the test was intended?

(Related to issue #27)

In #10 there's a discussion about adding annotations to functions to tell Parse to bypass them to not include them in the results. It needs to be determined how the comments (with the annotation) relates to the function and where the best place would be to check this.

$ composer install
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 24 installs, 0 updates, 0 removals
  - Installing akamon/mockery-callable-mock (v1.0.0): Downloading (failed)    Failed to download akamon/mockery-callable-mock from dist: The "https://api.github.com/repos/Akamon/mockery-callable-mock/zipball/e11211690c940fe0b089fa26018faab0cf2e3a88" file could not be downloaded (HTTP/1.1 404 Not Found)
    Now trying to download from source
  - Installing akamon/mockery-callable-mock (v1.0.0): Username for 'https://github.com':

Can't install this extension to my project since it's too new for it, I use nikic/php-parser 4.* in my code, but this package uses 2.0 version

I think it'd be awesome to update all other packages too

Hey,

installation is failing for me due to the composer constraint "symfony/console": "2.5 - 3.2",

    "require":{
        "php": ">=5.4",
        "nikic/php-parser": "^2.0",
        "symfony/console": "2.5 - 3.2",
        "symfony/event-dispatcher": "2.4 - 3.4"
    },

with

    - Installation request for psecio/parse ^0.8.0 -> satisfiable by psecio/parse[0.8].
    - Conclusion: remove symfony/console v3.4.20
    - Conclusion: don't install symfony/console v3.4.20
    - psecio/parse 0.8 requires symfony/console 2.5 - 3.2 -> satisfiable by symfony/console[...].

Is there any reason to fixate the version on max 3.2. or can we move to 3.4?

Cheers Pascal

Hello,

I'm discovering psecio-parse and I've just ran it on my codebase.

I've opened this issue to report errors when running it against a PHP 7.1 codebase:

private const MY_PRIVATE_CONST = 'hello';

^ this will throw an error "Syntax error, unexpected T_CONST, expecting T_FUNCTION"

public function hello(?string $name): string

^ this will throw an error "unexpected ?, expecting T_VARIABLE

I believe these errors come from nikic/php-parser, right? Your composer.json locks it to version 2.0 (resolving to 2.1.1 back from 2016) when version 4.0 is out and supports newer syntax. So maybe updating the parser would simply solve these issues.

Also, it would be great if you could provide phar archives for releases and don't limit the symfony/console dependency to version 3.2 max ;)

Cheers and I wish the best to this project! :)

~Nico

The openssl_verify function has the unfortunate interface of returning 1 if the signature is correct, 0 if it is incorrect, and -1 on error. This means if you do a naive comparison like if (!openssl_verify(...)) then errors will make it seem as if verification succeeded. Ideally verification should be done with something like if (openssl_verify(...) !== 1).

It'd be great if parse could detect this!