-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Column number in DetailNode
should start with 1
#14780
Comments
This issue in response to @rnveach 's #14710 (comment) which IMO is true considering the fact that the cmdline docs say that both the line and column numbers "will" differ. This however proved false as the line no's are in perfect sync. @rnveach , @romani , I couldn't understand how just each newline (\n) of javadoc is in perfect sync with the column numbers? PS: the column numbering in IDEs would exceed by 1 bcoz AST displays 0 based positioning |
There should be no
even |
Ideally yes @romani , to avoid confusion this would help a lot..
Could you please tell me why this is observed? |
no idea. Somebody need to debug it.
we should start from 1, to match what user is seeing in all IDE and text editors. |
Will do. The parser is antlr based I believe.... so maybe @nrmancuso , any insights on why this might be happening?
Totally agree with this. It would help a lot to avoid all the confusion |
This is issue #4997 . It should be slightly separate from this issue as we have a de-sync with the current numbers. Once they are insync, if position should be upped so there is no 0, then it should fall under #4997. |
This comment was marked as outdated.
This comment was marked as outdated.
I am removing the approved label until we have a clear picture of the scope of the work to be done here. As I read through the description and comments:
It is not clear to me if the problem is in our ANTLR grammar, JavaParser, or in the CLI. What I need to see here to approve this again:
|
Doc should show how it works now, even it is weird. |
Please restate this, sounds like we still have a lot of confusion about the problem and how we are proposing to fix it. This comment leads me to believe that you think this is a documentation/CLI issue, while @MANISH-K-07 is ready to start making changes to the ANTLR grammar:
My comment at #14780 (comment) stands. |
This comment was marked as outdated.
This comment was marked as outdated.
Yes, this is why you need to debug and research, then provide your findings here before we approve and you start writing code. Always expect to do this for issues of any appreciable value and scope. Writing code is the easiest part; truly understanding the issue is a big part of the work, and helping others to understand is another important aspect. Think about it like this: you start writing code, testing, etc, then send a PR only to find out that there is a massive misunderstanding, then you have to do it all over again. Then the next reviewer comes, points out a bunch of issues with your approach, then rinse and repeat. It is better to do a lot of work in the issue with research/explanations/discussion, since this work is reusable and ensures that everyone is on the same page. |
This comment was marked as off-topic.
This comment was marked as off-topic.
I haven't looked into this much, but this seems more like an antlr issue, or our conversion of antlr to AST. When we create ASTs, we do a direct conversion from antlr's type. Debugging this code, shows we are giving column 0. So we take that as is, with no change. AST is provided and used for everything, so when we provide column 0, everything else receives column 0. Things are probably made more complex as violations possibly seem to be 1 based. This is because we add a 1 in As another example, when don't provide a column number to Also ASTs don't know about tab widths, so column number in the AST is not truly the column number. It is more the character index in the line. This is probably why ANTLR calls it's method Fixing this issue will probably require little fixes all over the place. |
@MANISH-K-07 Unless I am missing something, this issue doesn't seem like a desync, but is more Until #4997 is fixed, all our ASTs are 0-based. Your first post tree shows this for both ASTs. So they are technically in sync, right? If there a de-sync between violations and ASTs, this follows what I am saying in my previous post, which still stems from our ASTs are 0-based. |
This comment was marked as resolved.
This comment was marked as resolved.
DetailNode
should start with 1
I have downloaded the latest checkstyle from: https://checkstyle.org/cmdline.html#Download_and_Run
https://checkstyle.org/cmdline.html#Command_line_usage
I have executed the cli and showed it below, as cli describes the problem better than 1,000 words
The de-sync of column numbers (-1) can be found at the javadoc content of the AST :
Leading asterix is being considered as position '0' because the javadoc is parsed as a separate file.
This is why column numbers shown in the AST generated through cli option
-J, -- treeWithJavadoc
differ by 1 for javadoc content.The option works in a way to sync the line numbers accurately. This should be extended to column numbers too
We should expect an AST something like :
Update: Similar to #4997 , but for
DetailNode
.The text was updated successfully, but these errors were encountered: