-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Prove regression from #1893 #1899
Conversation
…ent" This reverts commit f147caf.
Right, I've pushed a fix that allows a trailing comment on the same line as a I'd have thought this should be a config option, but as #1893 was merged without a new config I've assumed it's intended that trailing comments are allowed. |
8723383
to
9577ba8
Compare
9577ba8
to
0690ce0
Compare
@@ -137,12 +137,19 @@ public function process(File $phpcsFile, $stackPtr) | |||
return; | |||
} | |||
|
|||
$end = $phpcsFile->findNext(T_SEMICOLON, ($stackPtr + 1)); | |||
$end = $phpcsFile->findNext(T_SEMICOLON, ($stackPtr + 1)); | |||
$nextComment = $phpcsFile->findNext(T_COMMENT, ($end + 1)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be Tokens::$emptyTokens
to allow for phpcs:ignore
, etc.?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Side note: What we are checking for here is the next inline comment, if that's on the same line as the use
declaration then that can be classed as the "end" of the use
declaration instead of the semicolon.
As I see it: Allowing for any "empty token" would mean a /*
could be allowed (which it shouldn't be IMO) and other such tokens that shouldn't or couldn't be there.
I'm happy to be told that it should use Tokens::$emptyTokens
I'm just of the opinion that the only thing that can come next should be an inline comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
3.2.0
changed how overrides are annotated, which added several tokens for comments containing phpcs:
overrides: https://github.com/squizlabs/PHP_CodeSniffer/releases/tag/3.2.0
My PR changed T_COMMENT
to Tokens::$emptyTokens
in order to allow the T_PHPCS_*
tokens. That also allows T_DOC_COMMENT_*
, which seemed safe but isn't 100% correct in hindsight. I think this should be an array with T_COMMENT
and T_PHPCS_*
.
@jrfnl Does that sound right to you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll have a look at this PR later today.
@iammattcoleman i've quickly tried to add
This is the diff I tried: diff --git a/src/Standards/PSR2/Sniffs/Namespaces/UseDeclarationSniff.php b/src/Standards/PSR2/Sniffs/Namespaces/UseDecindex 4448a08..390629b 100644
--- a/src/Standards/PSR2/Sniffs/Namespaces/UseDeclarationSniff.php
+++ b/src/Standards/PSR2/Sniffs/Namespaces/UseDeclarationSniff.php
@@ -138,13 +138,16 @@ class UseDeclarationSniff implements Sniff
}
$end = $phpcsFile->findNext(T_SEMICOLON, ($stackPtr + 1));
- $nextComment = $phpcsFile->findNext(T_COMMENT, ($end + 1));
+ $nextComment = $end;
- // The end of the line is allowed to be a comment as well as a semi colon.
- if ($nextComment !== false && $tokens[$nextComment]['line'] === $tokens[$end]['line']) {
+ do {
+ $nextComment = $phpcsFile->findNext(Tokens::$emptyTokens, ($nextComment + 1));
+ } while ($nextComment !== false && $tokens[$nextComment]['line'] === $tokens[$end]['line']);
+
+ if ($nextComment !== false) {
$end = $nextComment;
}
-
+
if ($end === false) {
return;
} |
Gah, I see my problem but don't have time to fix right now. We need the |
0690ce0
to
50dacfd
Compare
50dacfd
to
1f1e919
Compare
OK - I've pushed in another commit that uses |
@gsherwood @jrfnl This should probably be included in 3.2.3. |
Yep, unless you want 3.2.3 to be broken :) |
@gsherwood I'm helping with the update to PHP 7.2 for Ubuntu 18.04. As of now, PHP_CodeSniffer 3.2.2 is slated to be included. I've let them know that there are some important fixes coming soon, but I felt you should know that they're currently packaging 3.2.2 along with its known issues. |
As per @iammattcoleman @dhensby request, I've had a look at this PR. I believe the logic can be simplified slightly by just checking for either next statement or the start of the next line, whichever comes first and not focusing completely on "next comment". I've just send in a PR to @dhensby's repo with an optional suggestion for amending this PR. |
Since the original downstream PR to amend this PR, @iammattcoleman and me have identified some additional issues and the downstream PR has been updated to allow for problems in the fixer when encountering various combinations of trailing comments after |
... covering different variations of comments after the last use statement.
…us combinations of comments
PSR2/UseDeclaration: simplify the fix
I've merged the downstream PR - all looks good - thanks for the thorough investigation |
@dhensby Thanks for working with me to get this sorted. |
@jrfnl no problem! Thanks for the help :) |
@dhensby Thanks for finding and fixing this before release. Very much appreciated. Thanks to those who reviewed as well. |
see #1898
The test that was merged with #1893 didn't actually test that lines after a user statement weren't blank as PHPCS would determine this to be the end of the file due to lack of class declaration or other valid code lines.