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

CHANGE(pmd): @W-17099496@: Upgrade PMD to 7.7.0 #112

Merged
merged 1 commit into from
Oct 30, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@
gson = "2.11.0"
hamcrest = "2.2"
junit-jupiter = "5.10.2"
pmd = "7.6.0" # !!! IMPORTANT !!! KEEP THIS IN SYNC WITH PMD_VERSION INSIDE OF: src/constants.ts
pmd = "7.7.0" # !!! IMPORTANT !!! KEEP THIS IN SYNC WITH PMD_VERSION INSIDE OF: src/constants.ts
slf4j-nop = "2.0.13" # For now, we throw slf4j logs away (using this no-op module). We might use an actual logger in the future.

[libraries]
Expand Down
2 changes: 1 addition & 1 deletion packages/code-analyzer-pmd-engine/src/constants.ts
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
// !!! IMPORTANT !!! KEEP THIS IN SYNC WITH gradle/libs.versions.toml
export const PMD_VERSION: string = '7.6.0';
export const PMD_VERSION: string = '7.7.0';

// !!! IMPORTANT !!! KEEP THIS IN SYNC WITH gradle/libs.versions.toml
export enum PmdLanguage {
Expand Down
4 changes: 4 additions & 0 deletions packages/code-analyzer-pmd-engine/test/pmd-engine.test.ts
Original file line number Diff line number Diff line change
Expand Up @@ -278,6 +278,10 @@ function expectDoesNotContainRuleWithName(ruleDescriptions: RuleDescription[], r
}

describe('Tests for the runRules method of PmdEngine', () => {
beforeAll(() => {
jest.setTimeout(60000);
});
Comment on lines +281 to +283
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Increasing timeout from default 5 seconds to 60 seconds to avoid sporadic failures.


const expectedOperationWithLimitsInLoopViolation: Violation = {
ruleName: "OperationWithLimitsInLoop",
message: 'Avoid operations in loops that may hit governor limits',
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -1170,7 +1170,7 @@
"CodeStyle",
"javaLanguage"
],
"description": "Methods that return boolean results should be named as predicate statements to denote this. I.e, 'isReady()', 'hasValues()', 'canCommit()', 'willFail()', etc. Avoid the use of the 'get' prefix for these methods.",
"description": "Methods that return boolean or Boolean results should be named as predicate statements to denote this. I.e., 'isReady()', 'hasValues()', 'canCommit()', 'willFail()', etc. Avoid the use of the 'get' prefix for these methods.",
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The use of a goldfile is really serving its purpose well here.

I've confirmed that the only rule definition changes are the java rules changes as described in the https://docs.pmd-code.org/pmd-doc-7.7.0/pmd_release_notes.html

So looks good.

"resourceUrls": [
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_codestyle.html#booleangetmethodname"
]
Expand Down Expand Up @@ -1680,17 +1680,17 @@
]
},
{
"name": "DefaultLabelNotLastInSwitchStmt",
"name": "DefaultLabelNotLastInSwitch",
"severityLevel": 3,
"type": "Standard",
"tags": [
"Recommended",
"BestPractices",
"javaLanguage"
],
"description": "By convention, the default label should be the last label in a switch statement.",
"description": "By convention, the default label should be the last label in a switch statement or switch expression. Note: This rule has been renamed from \"DefaultLabelNotLastInSwitchStmt\" with PMD {{PMD_VERSION}}.",
"resourceUrls": [
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#defaultlabelnotlastinswitchstmt"
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#defaultlabelnotlastinswitch"
]
},
{
Expand Down Expand Up @@ -2729,48 +2729,6 @@
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#junit4suitesshouldusesuiteannotation"
]
},
{
"name": "JUnit4TestShouldUseAfterAnnotation",
"severityLevel": 3,
"type": "Standard",
"tags": [
"Recommended",
"BestPractices",
"javaLanguage"
],
"description": "In JUnit 3, the tearDown method was used to clean up all data entities required in running tests. JUnit 4 skips the tearDown method and executes all methods annotated with @After after running each test. JUnit 5 introduced @AfterEach and @AfterAll annotations to execute methods after each test or after all tests in the class, respectively.",
"resourceUrls": [
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#junit4testshoulduseafterannotation"
]
},
{
"name": "JUnit4TestShouldUseBeforeAnnotation",
"severityLevel": 3,
"type": "Standard",
"tags": [
"Recommended",
"BestPractices",
"javaLanguage"
],
"description": "In JUnit 3, the setUp method was used to set up all data entities required in running tests. JUnit 4 skips the setUp method and executes all methods annotated with @Before before all tests. JUnit 5 introduced @BeforeEach and @BeforeAll annotations to execute methods before each test or before all tests in the class, respectively.",
"resourceUrls": [
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#junit4testshouldusebeforeannotation"
]
},
{
"name": "JUnit4TestShouldUseTestAnnotation",
"severityLevel": 3,
"type": "Standard",
"tags": [
"Recommended",
"BestPractices",
"javaLanguage"
],
"description": "In JUnit 3, the framework executed all methods which started with the word test as a unit test. In JUnit 4, only methods annotated with the @Test annotation are executed. In JUnit 5, one of the following annotations should be used for tests: @Test, @RepeatedTest, @TestFactory, @TestTemplate or @ParameterizedTest. In TestNG, only methods annotated with the @Test annotation are executed.",
"resourceUrls": [
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#junit4testshouldusetestannotation"
]
},
{
"name": "JUnit5TestShouldBePackagePrivate",
"severityLevel": 3,
Expand All @@ -2785,20 +2743,6 @@
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#junit5testshouldbepackageprivate"
]
},
{
"name": "JUnitAssertionsShouldIncludeMessage",
"severityLevel": 3,
"type": "Standard",
"tags": [
"Recommended",
"BestPractices",
"javaLanguage"
],
"description": "JUnit assertions should include an informative message - i.e., use the three-argument version of assertEquals(), not the two-argument version.",
"resourceUrls": [
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#junitassertionsshouldincludemessage"
]
},
{
"name": "JUnitSpelling",
"severityLevel": 3,
Expand Down Expand Up @@ -2827,34 +2771,6 @@
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_errorprone.html#junitstaticsuite"
]
},
{
"name": "JUnitTestContainsTooManyAsserts",
"severityLevel": 3,
"type": "Standard",
"tags": [
"Recommended",
"BestPractices",
"javaLanguage"
],
"description": "Unit tests should not contain too many asserts. Many asserts are indicative of a complex test, for which it is harder to verify correctness. Consider breaking the test scenario into multiple, shorter test scenarios. Customize the maximum number of assertions used by this Rule to suit your needs. This rule checks for JUnit4, JUnit5 and TestNG Tests, as well as methods starting with \"test\".",
"resourceUrls": [
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#junittestcontainstoomanyasserts"
]
},
{
"name": "JUnitTestsShouldIncludeAssert",
"severityLevel": 3,
"type": "Standard",
"tags": [
"Recommended",
"BestPractices",
"javaLanguage"
],
"description": "JUnit tests should include at least one assertion. This makes the tests more robust, and using assert with messages provide the developer a clearer idea of what the test does.",
"resourceUrls": [
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#junittestsshouldincludeassert"
]
},
{
"name": "JUnitUseExpected",
"severityLevel": 3,
Expand Down Expand Up @@ -3332,17 +3248,31 @@
]
},
{
"name": "NonCaseLabelInSwitchStatement",
"name": "NonCaseLabelInSwitch",
"severityLevel": 3,
"type": "Standard",
"tags": [
"Recommended",
"ErrorProne",
"javaLanguage"
],
"description": "A non-case label (e.g. a named break/continue label) was present in a switch statement. This is legal, but confusing. It is easy to mix up the case labels and the non-case labels.",
"description": "A non-case label (e.g. a named break/continue label) was present in a switch statement or switch expression. This is legal, but confusing. It is easy to mix up the case labels and the non-case labels. Note: This rule was renamed from `NonCaseLabelInSwitchStatement` with PMD {{PMD_VERSION}}.",
"resourceUrls": [
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_errorprone.html#noncaselabelinswitch"
]
},
{
"name": "NonExhaustiveSwitch",
"severityLevel": 3,
"type": "Standard",
"tags": [
"Recommended",
"BestPractices",
"javaLanguage"
],
"description": "Switch statements should be exhaustive, to make their control flow easier to follow. This can be achieved by adding a `default` case, or, if the switch is on an enum type, by ensuring there is one switch branch for each enum constant. This rule doesn't consider Switch Statements, that use Pattern Matching, since for these the compiler already ensures that all cases are covered. The same is true for Switch Expressions, which are also not considered by this rule.",
"resourceUrls": [
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_errorprone.html#noncaselabelinswitchstatement"
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#nonexhaustiveswitch"
]
},
{
Expand Down Expand Up @@ -4073,20 +4003,6 @@
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_design.html#switchdensity"
]
},
{
"name": "SwitchStmtsShouldHaveDefault",
"severityLevel": 3,
"type": "Standard",
"tags": [
"Recommended",
"BestPractices",
"javaLanguage"
],
"description": "Switch statements should be exhaustive, to make their control flow easier to follow. This can be achieved by adding a `default` case, or, if the switch is on an enum type, by ensuring there is one switch branch for each enum constant.",
"resourceUrls": [
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#switchstmtsshouldhavedefault"
]
},
{
"name": "SystemPrintln",
"severityLevel": 3,
Expand Down Expand Up @@ -4130,17 +4046,17 @@
]
},
{
"name": "TooFewBranchesForASwitchStatement",
"name": "TooFewBranchesForSwitch",
"severityLevel": 3,
"type": "Standard",
"tags": [
"Recommended",
"Performance",
"javaLanguage"
],
"description": "Switch statements are intended to be used to support complex branching behaviour. Using a switch for only a few cases is ill-advised, since switches are not as easy to understand as if-else statements. In these cases use the if-else statement to increase code readability.",
"description": "Switch statements are intended to be used to support complex branching behaviour. Using a switch for only a few cases is ill-advised, since switches are not as easy to understand as if-else statements. In these cases use the if-else statement to increase code readability. Note: This rule was named TooFewBranchesForASwitchStatement before PMD {{PMD_VERSION}}.",
"resourceUrls": [
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_performance.html#toofewbranchesforaswitchstatement"
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_performance.html#toofewbranchesforswitch"
]
},
{
Expand Down Expand Up @@ -4241,6 +4157,90 @@
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_errorprone.html#unconditionalifstatement"
]
},
{
"name": "UnitTestAssertionsShouldIncludeMessage",
"severityLevel": 3,
"type": "Standard",
"tags": [
"Recommended",
"BestPractices",
"javaLanguage"
],
"description": "Unit assertions should include an informative message - i.e., use the three-argument version of `assertEquals()`, not the two-argument version. This rule supports tests using JUnit (3, 4 and 5) and TestNG. Note: This rule was named JUnitAssertionsShouldIncludeMessage before PMD {{PMD_VERSION}}.",
"resourceUrls": [
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#unittestassertionsshouldincludemessage"
]
},
{
"name": "UnitTestContainsTooManyAsserts",
"severityLevel": 3,
"type": "Standard",
"tags": [
"Recommended",
"BestPractices",
"javaLanguage"
],
"description": "Unit tests should not contain too many asserts. Many asserts are indicative of a complex test, for which it is harder to verify correctness. Consider breaking the test scenario into multiple, shorter test scenarios. Customize the maximum number of assertions used by this Rule to suit your needs. This rule checks for JUnit (3, 4 and 5) and TestNG Tests. Note: This rule was named JUnitTestContainsTooManyAsserts before PMD {{PMD_VERSION}}.",
"resourceUrls": [
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#unittestcontainstoomanyasserts"
]
},
{
"name": "UnitTestShouldIncludeAssert",
"severityLevel": 3,
"type": "Standard",
"tags": [
"Recommended",
"BestPractices",
"javaLanguage"
],
"description": "Unit tests should include at least one assertion. This makes the tests more robust, and using assert with messages provide the developer a clearer idea of what the test does. This rule checks for JUnit (3, 4 and 5) and TestNG Tests. Note: This rule was named JUnitTestsShouldIncludeAssert before PMD {{PMD_VERSION}}.",
"resourceUrls": [
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#unittestshouldincludeassert"
]
},
{
"name": "UnitTestShouldUseAfterAnnotation",
"severityLevel": 3,
"type": "Standard",
"tags": [
"Recommended",
"BestPractices",
"javaLanguage"
],
"description": "This rule detects methods called `tearDown()` that are not properly annotated as a cleanup method. This is primarily intended to assist in upgrading from JUnit 3, where tear down methods were required to be called `tearDown()`. To a lesser extent, this may help detect omissions even under newer JUnit versions or under TestNG, as long as you are following this convention to... Learn more: https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#unittestshoulduseafterannotation",
"resourceUrls": [
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#unittestshoulduseafterannotation"
]
},
{
"name": "UnitTestShouldUseBeforeAnnotation",
"severityLevel": 3,
"type": "Standard",
"tags": [
"Recommended",
"BestPractices",
"javaLanguage"
],
"description": "This rule detects methods called `setUp()` that are not properly annotated as a setup method. This is primarily intended to assist in upgrading from JUnit 3, where setup methods were required to be called `setUp()`. To a lesser extent, this may help detect omissions even under newer JUnit versions or under TestNG, as long as you are following this convention to name the... Learn more: https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#unittestshouldusebeforeannotation",
"resourceUrls": [
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#unittestshouldusebeforeannotation"
]
},
{
"name": "UnitTestShouldUseTestAnnotation",
"severityLevel": 3,
"type": "Standard",
"tags": [
"Recommended",
"BestPractices",
"javaLanguage"
],
"description": "The rule will detect any test method starting with \"test\" that is not properly annotated, and will therefore not be run. In JUnit 4, only methods annotated with the `@Test` annotation are executed. In JUnit 5, one of the following annotations should be used for tests: `@Test`, `@RepeatedTest`, `@TestFactory`, `@TestTemplate` or `@ParameterizedTest`. In TestNG, only methods... Learn more: https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#unittestshouldusetestannotation",
"resourceUrls": [
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_bestpractices.html#unittestshouldusetestannotation"
]
},
{
"name": "UnnecessaryAnnotationValueElement",
"severityLevel": 3,
Expand Down Expand Up @@ -4810,7 +4810,7 @@
"ErrorProne",
"javaLanguage"
],
"description": "An operation on an Immutable object (String, BigDecimal or BigInteger) won't change the object itself since the result of the operation is a new object. Therefore, ignoring the operation result is an error.",
"description": "An operation on an immutable object will not change the object itself since the result of the operation is a new object. Therefore, ignoring the result of such an operation is likely a mistake. The operation can probably be removed. This rule recognizes the types `String`, `BigDecimal`, `BigInteger` or any type from `java.time.*` as immutable.",
"resourceUrls": [
"https://docs.pmd-code.org/pmd-doc-{{PMD_VERSION}}/pmd_rules_java_errorprone.html#uselessoperationonimmutable"
]
Expand Down