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.

Sign up for GitHub

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

Jump to bottom

Issue #14084: fix Checker violation for nonnegative integer argument #14673

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Issue #14084: fix Checker violation for nonnegative integer argument #14673

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
11 changes: 0 additions & 11 deletions config/checker-framework-suppressions/checker-index-suppressions.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,17 +11,6 @@
</details>
</checkerFrameworkError>

<checkerFrameworkError unstable="false">
<fileName>src/main/java/com/puppycrawl/tools/checkstyle/DetailAstImpl.java</fileName>
<specifier>argument</specifier>
<message>incompatible argument for parameter bitIndex of BitSet.get.</message>
<lineContent>return getBranchTokenTypes().get(tokenType);</lineContent>
Copy link
Member

Choose a reason for hiding this comment

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

This is details of implementation that we use bitset. But we are changing API method. It is not good.
API is generic, and if somebody wants to put -1 in our method, they have full right in this, we should not throw exception, and just return false.

Copy link
Contributor Author

@Lmh-java Lmh-java Mar 18, 2024 •
edited

Choose a reason for hiding this comment

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

Done. I use 1 as the boundary since the smallest flag value of tokenType is 1, and also to pass Pitest mutation.

Copy link
Member

@nrmancuso nrmancuso Mar 26, 2024 •
edited

Choose a reason for hiding this comment

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

API is generic, and if somebody wants to put -1 in our method, they have full right in this, we should not throw exception, and just return false.

But we are changing API method. It is not good.

@romani we are still changing the behavior of our API for this update (from IndexOutOfBoundsException -> silent fail). Can we just annotate the method's parameter to specify that it should be nonnegative? Dancing around the dependency on Checker at compile time is getting old; if we are going to use this tool, let's use it correctly.

Copy link
Member

@romani romani Mar 26, 2024 •
edited

Choose a reason for hiding this comment

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

I am afraid to use checker as compile time dependency for our API .

For now we just remove Checker violation, by workaround. No change in behavior, or may be minor change to better, less exceptions.

Copy link
Member

Choose a reason for hiding this comment

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

I am afraid to use checker as compile time dependency for our API .

Then I don’t see any point in using it at all. Changing a part of our API to silently fail to be able to remove some suppression from a file is not an improvement to the project.

Copy link
Member

@nrmancuso nrmancuso Mar 26, 2024 •
edited

Choose a reason for hiding this comment

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

We should absolutely throw an exception here. If we cannot come to an agreement on this particular checker (index) then we should avoid sending PRs for this one until we agree on how we are handling it. Changing production code in our core API to silently fail is not a positive change.

Copy link
Member

Choose a reason for hiding this comment

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

@rnveach , please share your opinion here on exception or just return of false

Copy link
Member

@rnveach rnveach Mar 30, 2024 •
edited

Choose a reason for hiding this comment

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

I question the whole point of the new code check. We are reliant on ANTLR generating these numbers. I am not sure we have any contract with them which they should not be negative. Even if they did specify it somewhere in some document, I would think this is something we shouldn't enforce since its such low level and behinds the scene. As long as the method doesn't have a problem with positive/zero/negative, then I don't think we should check this.

I am not for an exception and not for this new condition.

Copy link
Member

Choose a reason for hiding this comment

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

It would not be a concern if we have tokens as enum , so it will be type safe. But we have int so user can put anything to such methods that is comply by type, for example index of some loop in custom Check.

Copy link
Member

Choose a reason for hiding this comment

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

As long as the method doesn't have a problem with positive/zero/negative

It does. It throws exception. After fix it will return false. I like it more as "search" should not throw exceptions and just return true/false.

<details>
found : int
required: @NonNegative int
</details>
</checkerFrameworkError>

<checkerFrameworkError unstable="false">
<fileName>src/main/java/com/puppycrawl/tools/checkstyle/DetailAstImpl.java</fileName>
<specifier>argument</specifier>
Expand Down
2 changes: 1 addition & 1 deletion src/main/java/com/puppycrawl/tools/checkstyle/DetailAstImpl.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -384,7 +384,7 @@ private BitSet getBranchTokenTypes() {

@Override
public boolean branchContains(int tokenType) {
return getBranchTokenTypes().get(tokenType);
return tokenType >= 1 && getBranchTokenTypes().get(tokenType);
Copy link
Member

Choose a reason for hiding this comment

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

this is good.

✔ ~/java/github/checkstyle/checkstyle
$ head -n 25 ./target/generated-sources/antlr/com/puppycrawl/tools/checkstyle/grammar/java/JavaLanguageLexer.java
// Generated from com/puppycrawl/tools/checkstyle/grammar/java/JavaLanguageLexer.g4 by ANTLR 4.13.1
package com.puppycrawl.tools.checkstyle.grammar.java;

import com.puppycrawl.tools.checkstyle.grammar.CommentListener;
import com.puppycrawl.tools.checkstyle.grammar.CompositeLexerContextCache;
import com.puppycrawl.tools.checkstyle.grammar.CrAwareLexerSimulator;

import org.antlr.v4.runtime.Lexer;
import org.antlr.v4.runtime.CharStream;
import org.antlr.v4.runtime.Token;
import org.antlr.v4.runtime.TokenStream;
import org.antlr.v4.runtime.*;
import org.antlr.v4.runtime.atn.*;
import org.antlr.v4.runtime.dfa.DFA;
import org.antlr.v4.runtime.misc.*;

@SuppressWarnings({"all", "warnings", "unchecked", "unused", "cast", "CheckReturnValue", "this-escape"})
public class JavaLanguageLexer extends Lexer {
	static { RuntimeMetaData.checkVersion("4.13.1", RuntimeMetaData.VERSION); }

	protected static final DFA[] _decisionToDFA;
	protected static final PredictionContextCache _sharedContextCache =
		new PredictionContextCache();
	public static final int
		COMPILATION_UNIT=1, PLACEHOLDER1=2, NULL_TREE_LOOKAHEAD=3, BLOCK=4, MODIFIERS=5,

}

@Override
Expand Down
11 changes: 9 additions & 2 deletions src/test/java/com/puppycrawl/tools/checkstyle/DetailAstImplTest.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -355,8 +355,9 @@ public void testInsertSiblingBetween() throws Exception {

@Test
public void testBranchContains() {
final DetailAstImpl root = createToken(null, TokenTypes.CLASS_DEF);
final DetailAstImpl modifiers = createToken(root, TokenTypes.MODIFIERS);
final DetailAstImpl root = createToken(null, TokenTypes.COMPILATION_UNIT);
final DetailAstImpl classDef = createToken(root, TokenTypes.CLASS_DEF);
final DetailAstImpl modifiers = createToken(classDef, TokenTypes.MODIFIERS);
createToken(modifiers, TokenTypes.LITERAL_PUBLIC);

assertWithMessage("invalid result")
Expand All @@ -365,6 +366,12 @@ public void testBranchContains() {
assertWithMessage("invalid result")
.that(root.branchContains(TokenTypes.OBJBLOCK))
.isFalse();
assertWithMessage("invalid result")
.that(root.branchContains(TokenTypes.COMPILATION_UNIT))
.isTrue();
assertWithMessage("negative tokenType")
.that(root.branchContains(-1))
.isFalse();
}

private static DetailAstImpl createToken(DetailAstImpl root, int type) {
Expand Down