Skip to content

Issue #4717: Added JavadocParserErrorStrategy which extends BailErrorStrategy#4825

Merged
Vladlis merged 1 commit intocheckstyle:masterfrom
therootusr:issue_4717
Jul 28, 2017
Merged

Issue #4717: Added JavadocParserErrorStrategy which extends BailErrorStrategy#4825
Vladlis merged 1 commit intocheckstyle:masterfrom
therootusr:issue_4717

Conversation

@therootusr
Copy link
Copy Markdown

@therootusr
Copy link
Copy Markdown
Author

@Vladlis Thank you for the solution. Please have a look.

@codecov-io
Copy link
Copy Markdown

codecov-io commented Jul 25, 2017

Codecov Report

Merging #4825 into master will not change coverage.
The diff coverage is 100%.

Impacted file tree graph

@@          Coverage Diff           @@
##           master   #4825   +/-   ##
======================================
  Coverage     100%    100%           
======================================
  Files         288     288           
  Lines       15435   15435           
  Branches     3501    3500    -1     
======================================
  Hits        15435   15435
Impacted Files Coverage Δ
...heckstyle/checks/javadoc/AbstractJavadocCheck.java 100% <ø> (ø) ⬆️
...rawl/tools/checkstyle/JavadocDetailNodeParser.java 100% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 46fa809...57d1070. Read the comment docs.

@rnveach
Copy link
Copy Markdown
Contributor

rnveach commented Jul 26, 2017

@PS-SP TC failed.

@therootusr
Copy link
Copy Markdown
Author

@rnveach Yes, I checked. One reason is throwing unchecked exception in code which can be taken care of but another is with the unused catch parameter here at JavadocDetailNodeParser.java#L129. Right now we don't need to do anything with that exception object.

@therootusr
Copy link
Copy Markdown
Author

diff report

@Vladlis
Copy link
Copy Markdown
Contributor

Vladlis commented Jul 26, 2017

@PS-SP
PR and report look good.
Please either resolve or suppress (with explanation) TC violations.

@therootusr
Copy link
Copy Markdown
Author

@Vladlis

Please either resolve or suppress (with explanation) TC violations.

Resolved.

@Vladlis Vladlis requested review from rnveach and romani July 26, 2017 09:27
import static com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractJavadocCheck.MSG_JAVADOC_MISSED_HTML_CLOSE;
import static com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractJavadocCheck.MSG_JAVADOC_PARSE_RULE_ERROR;
import static com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractJavadocCheck.MSG_JAVADOC_WRONG_SINGLETON_TAG;
import static com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractJavadocCheck.MSG_KEY_UNRECOGNIZED_ANTLR_ERROR;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this message no longer possible to receive? If so, shouldn't we remove the field and properties message?

Copy link
Copy Markdown
Author

@therootusr therootusr Jul 26, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it shouldn't be possible any longer. This one at messages.properties#L1 also seems unutilized.

The reason I didn't remove unrecognized one is that right now it looks like that report should be called under all circumstances. But it might so happen that under some weird input or for some other reason ANTLR fails to report to listener and then we might again require it. So I thought that after some time of usage when we can be sure that never does ANTLR fail to report to listener, we can remove all the unutilized message keys together in one issue so that all other message.properties get cleaned.

Copy link
Copy Markdown
Contributor

@rnveach rnveach Jul 26, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think it should be removed. We will still have it's code in history if we need it again.
@romani You agree?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@PS-SP
Please remove this property.
@rnveach @romani
I thought we have some inspection to detect unused properties. If not - should we add one?

Copy link
Copy Markdown
Contributor

@rnveach rnveach Jul 26, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Vladlis It is a public property, so it probably can't tell the difference between something we give to the users and something we just use for ourselves. Had it been private, it probably would have thrown up a flag.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Vladlis

Please remove this property.

Done

@rnveach
Copy link
Copy Markdown
Contributor

rnveach commented Jul 26, 2017

http://4717-diff.getforge.io/apache-ant/index.html#A26
http://4717-diff.getforge.io/apache-ant/xref/home/cortana/Desktop/checkstyle/contribution/checkstyle-tester/repositories/apache-ant/src/main/org/apache/tools/zip/Simple8BitZipEncoding.java.html#L234

Details: mismatched input 'org.apache.tools.zip' expecting <EOF> while parsing JAVADOC
@see org.apache.tools.zip.ZipEncoding#encode(java.lang.String)

Why does this fail recognition?
According to http://www.oracle.com/technetwork/articles/java/index-137868.html , it should be acceptable: @see package.Class#method(Type, Type,...)

Edit: It seems the line separation between @see and org is causing the failure. This should be an issue as it looks valid to me.

@therootusr
Copy link
Copy Markdown
Author

@rnveach
Because of the LEADING_ASTERISK, which is supported in DESCRIPTION in here at JavadocParser.g4#L879. reference rule doesn't support LEADING_ASTERISK

@rnveach
Copy link
Copy Markdown
Contributor

rnveach commented Jul 26, 2017

@PS-SP If you agree it should be acceptable, make a issue for it. Otherwise explain why it isn't valid javadoc.

@therootusr
Copy link
Copy Markdown
Author

therootusr commented Jul 26, 2017

@rnveach I agree it should be valid. @see tag is already being worked under #4752. We can change that issue topic if need be

@rnveach
Copy link
Copy Markdown
Contributor

rnveach commented Jul 26, 2017

@PS-SP Since you already started that issue, unless your fix already includes the fix for the issue I pointed at, I think it should be a new issue. Placing too much into 1 issue over complicates the issue and will be harder to manage.

@therootusr
Copy link
Copy Markdown
Author

@rnveach Can be done there itself. Please check my summary comment there I just made.

@rnveach
Copy link
Copy Markdown
Contributor

rnveach commented Jul 26, 2017

@PS-SP And your long winded post proves to me that too much is going on there.
Please rebase to resolve conflicts.

@therootusr
Copy link
Copy Markdown
Author

@rnveach Rebased.

That PR wasn't intended to drag on for so long and to be so big. But things kept coming one after the other and here we are. Just one little problem needs to be addressed now and hopefully I will be able to update PR finally.

@rnveach
Copy link
Copy Markdown
Contributor

rnveach commented Jul 27, 2017

@romani Please review.

@romani
Copy link
Copy Markdown
Member

romani commented Jul 27, 2017

@PS-SP , please rebase.
changes in property files are unfortunate , but all was done in them is a sorting. I hope it will not make too much problems to rebase.

I like more detailed messaged. As CI pass, we good to merge this PR.

@therootusr
Copy link
Copy Markdown
Author

@romani rebased

@Vladlis Vladlis merged commit ebeedf9 into checkstyle:master Jul 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants