Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Commenting.PackageSniff fix seems broken when first doc comment is an inline one #172

Closed
micaherne opened this issue Jun 26, 2024 · 6 comments · Fixed by #173
Closed

Commenting.PackageSniff fix seems broken when first doc comment is an inline one #172

micaherne opened this issue Jun 26, 2024 · 6 comments · Fixed by #173
Assignees
Labels
bug Something isn't working

Comments

@micaherne
Copy link
Contributor

micaherne commented Jun 26, 2024

I'm seeing multiple issues with PackageSniff with code similar to this:

namespace availability_strathenrol;

use enrol_plugin;

class frontend extends \core_availability\frontend {

    protected function get_javascript_init_params($course, \cm_info $cm = null, \section_info $section = null) {
        $instances = enrol_get_instances($course->id, false);

        /** @var enrol_plugin[] $plugins */
        $plugins = enrol_get_plugins(false);
    }
}

PHPCS is correctly identifying that there is no package tag:

1 | ERROR   | [x] DocBlock missing a @package tag for file frontend.php. Expected @package availability_strathenrol
    |         |     (moodle.Commenting.Package.Missing)

But running the fix gives these two issues:

  1. It tries to add the tag to the inline docblock where it's clearly not appropriate.

  2. In the first pass it adds the tag to the end of the inline comment on the same line:

/** @var enrol_plugin[] $plugins * @package availability_strathenrol
*/

This is then detected as still violating the sniff, so it runs a second pass and adds it again on the line with the closing tag.

So the final diff is this:

-        /** @var enrol_plugin[] $plugins */
+        /** @var enrol_plugin[] $plugins * @package availability_strathenrol
+ * @package availability_strathenrol
+ */
@micaherne
Copy link
Contributor Author

This is with the latest dev-main 85e9e0a.

@stronk7
Copy link
Member

stronk7 commented Jun 27, 2024

Hi @micaherne ,

thanks for reporting the problem, it looks really ugly! I'll give a try to it now, looking forward an acceptable solution, thanks!

@stronk7 stronk7 added the bug Something isn't working label Jun 27, 2024
@stronk7
Copy link
Member

stronk7 commented Jun 27, 2024

Ok, tracing down the problem it seems that the troubles are caused by Docblocks::getDocBlockPointer() that, when invoked for an arbitrary pointer (for example, the <php open tag, that uses to be pointer = 0) it's returning the FIRST phpdoc block in the file (in your case corresponding to the $plugins type-hinting block). And that's a bug.

In the mean time, and as a workaround, I think that if you add the file or class phpdoc block (the later is preferred in modern code), then you won't face the problem (it only happens when both phpdoc blocks are missing). If any of the blocks exist... then the fixer works ok, so far.

I'm creating a test and, hopefully, a fix... ciao :-)

stronk7 added a commit to stronk7/moodle-cs that referenced this issue Jun 27, 2024
Previously, we were allowing the getDocTagFromOpenTag()
method to advance too much when looking for file phpdoc
blocks. Now we stop as soon as any of the stop tokens is found.

Note that this case is very edge one, only reproducible when
there are lots of missing class/function phpdoc block, causing
some other phpdoc block to be picked.

In any case, I think that it's perfectly ok to shortcut the
search that way, it can save us some precious iterations.

Fixes moodlehq#172
stronk7 added a commit to stronk7/moodle-cs that referenced this issue Jun 27, 2024
Previously, we were allowing the getDocTagFromOpenTag()
method to advance too much when looking for file phpdoc
blocks. Now we stop as soon as any of the stop tokens is found.

Note that this case is very edge one, only reproducible when
there are lots of missing class/function phpdoc block, causing
some other phpdoc block to be picked.

In any case, I think that it's perfectly ok to shortcut the
search that way, it can save us some precious iterations.

Fixes moodlehq#172
@stronk7
Copy link
Member

stronk7 commented Jun 27, 2024

I've created #173 that, hopefully, fixes this edge case (it's really edge!). In any case, if accepted, it will also save a few iterations when looking for those file phpdoc blocks. 🤞

Ciao :-)

@stronk7
Copy link
Member

stronk7 commented Jun 27, 2024

@micaherne , if you've any other case, different (structurally), from the above, it would be great to know about it. With the proposed patch, I think we are covered for any other combination.

Ciao :-)

@stronk7 stronk7 self-assigned this Jun 27, 2024
@micaherne
Copy link
Contributor Author

micaherne commented Jun 27, 2024

Brilliant, thanks @stronk7! I haven't spotted any other issues with it so hopefully that'll be it.

stronk7 added a commit to stronk7/moodle-cs that referenced this issue Jun 29, 2024
Previously, we were allowing the getDocTagFromOpenTag()
method to advance too much when looking for file phpdoc
blocks. Now we stop as soon as any of the stop tokens is found.

Note that this case is very edge one, only reproducible when
there are lots of missing class/function phpdoc block, causing
some other phpdoc block to be picked.

In any case, I think that it's perfectly ok to shortcut the
search that way, it can save us some precious iterations.

Fixes moodlehq#172
stronk7 added a commit to stronk7/moodle-cs that referenced this issue Jun 29, 2024
Previously, we were allowing the getDocTagFromOpenTag()
method to advance too much when looking for file phpdoc
blocks. Now we stop as soon as any of the stop tokens is found.

Note that this case is very edge one, only reproducible when
there are lots of missing class/function phpdoc block, causing
some other phpdoc block to be picked.

In any case, I think that it's perfectly ok to shortcut the
search that way, it can save us some precious iterations.

Fixes moodlehq#172
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants