Excavator: Upgrades Baseline to the latest version #129
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
robert3005
force-pushed
the
roomba/latest-baseline-oss
branch
from
7871dcc to
90ca781
Compare
added 4 commits
May 6, 2020 23:46
|
👍 |
iamdanfox
approved these changes
May 7, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
excavator is a bot for automating changes across repositories.
Changes produced by the roomba/latest-baseline-oss check.
Release Notes
0.66.0
[improvement] Ignore DesignForExtension for ParameterizedTest (#673)
0.66.1
1.0.0
1.1.0
1.1.1
-PerrorProneApply.1.2.0
1.3.0
It's possible to restore caching by adding
com.palantir.baseline.restore-test-cache = trueto yourgradle.properties.1.4.0
1.5.0
1.6.0
1.6.1
1.7.0
./gradlew format -Pcom.palantir.baseline-format.eclipse.1.8.0
() -> {}1.8.1
1.8.2
EnableRuleMigrationSupportinJUnit5RuleUsageerrorprone-rule1.9.0
checkImplicitDependenciestask will no longer suggest a fix of the current project.1.10.0
executeoversubmitwhen the result is ignored1.10.1
1.11.0
InputStreamSlowMultibyteReaderror prone check at ERROR severity1.12.0
baseline-ideaplugin now generates configuration more closely aligned with Gradle defaults.UnusedMethodandUnusedVariable.stream.sorted().findFirst()intostream.min(Comparator.naturalOrder())DangerousStringInternUsage: Disallow String.intern() invocations1.12.1
UnusedMethodandUnusedVariablewhich automaticall remove code with side effects.1.13.0
LogSafePreconditionsConstantMessageSlf4jLogsafeArgsin test codeDuration#getNanosmistakes and bans URL in equals methods1.14.0
OptionalOrElseThrowThrowsto prevent throwing from orElseThrow1.15.0
1.16.0
1.17.0
TypeParameterUnusedInFormalserrorprone check is disabled when compiling on Java 13, to workaround an error-prone bug.1.17.1
1.17.2
1.18.0
dependencies are ignored due to false positives as these dependencies
will not appear as dependencies in the generated byte-code, but are in
fact necessary dependencies to compile a given module.
1.19.0
PreconditionsConstantMessageon gradle plugins2.0.0
2.1.0
2.1.1
2.2.0
project) as can interfere with publishing.2.2.1
2.2.2
runtimeClasspathconfiguration by default.2.3.0
{}in safelog exception messages2.4.0
StrictUnusedVariablecheck will catch any unused arguments (e.g. AuthHeaders) to public methods. If you need to suppress this, rename your variable to have an underscore prefix (e.g.s/foo/_foo/) or just run./gradlew classes -PerrorProneApplyto auto-fix2.4.1
module-info.classwhen checking class uniqueness2.4.2
src/*/resourcesdirectory anymore.2.4.3
2.5.0
2.6.0
PreferAssertjto assist migration to AssertJ from legacy test frameworks. It may be necessary to add a dependency onorg.assertj:assertj-corein modules which do not already depend on AssertJ. If there's a technical reason that AssertJ cannot be used,PreferAssertjmay be explicitly disabled to prevent future upgrades from attempting to re-run the migration.2.7.0
StrictUnusedVariablenow ignores variables prefixed with_and the suggested fix will rename all unused parameters in public methods instead of removing them@RunWith(Suite.class)that references JUnit5 classes, as this can cause tests to silently not run!2.8.0
2.8.1
2.9.0
_prefixbaselineErrorProne { patchChecks += 'PreferAssertj' }2.9.1
StrictUnusedVariablecorrectly converts previously suppressed variablesunusedto_2.9.2
StrictUnusedVariablewill preserve side effects2.10.0
checkJUnitDependenciestask detects misconfigured JUnit dependencies which could result in some tests silently not running.2.10.1
2.11.0
2.11.1
2.11.2
assertThatimports2.12.0
UnusedVariableerror prone rule by default2.13.0
@TestTemplateannotation is now used to detect whether a class is test code.2.14.0
2.15.0
No documented user facing changes
2.16.0
isEqualTochecks intohasValuechecks2.17.0
2.18.0
2.19.0
2.20.0
UnnecessaryParenthesesby defaultThrowErrorto discourage throwing Errors in production codeErrors are often handled poorly by libraries resulting in unexpected
behavior and resource leaks. It's not obvious that 'catch (Exception e)'
does not catch Error.
This check is intended to be advisory - it's fine to
@SuppressWarnings("ThrowError")in certain cases, but is usually notrecommended unless you are writing a testing library that throws
AssertionError.
Slf4jLevelCheckto validate that slf4j level checks agree with contained logging.2.20.1
2.21.0
2.22.0
Automated release, no documented user facing changes
2.23.0
Calling address.getHostName may result in a DNS lookup which is a network request,
making the invocation significantly more expensive than expected depending on the
environment.
This check is intended to be advisory - it's fine to
@SuppressWarnings("ReverseDnsLookup") in certain cases, but is usually not
recommended.
2.24.0
verifyZeroInteractionsnow gets rewritten toverifyNoMoreInteractions, which has the same behaviour.com.palantir.safe-logging:preconditions).2.25.0
com.palantir-java-formatwhich is also used to determine the version used by IntelliJ.2.26.0
./gradlew formatDiffto reformat the relevant sections of any uncommitted changed Java files (relies ongit diff -U0 HEADunder the hood)2.27.0
DangerousParallelStreamUsagechecks forCollection.parallelStream()andStreamSupportutility methods with parallel=true.Throwables must be logged without an Arg wrapper as the last parameter, otherwise unsafe data may be leaked from the unsafe message or the unsafe message of a cause.
2.28.0
FinalClasserror prone check, replacing the checkstyle implementation2.28.1
RedundantModifierinterpretation of implicit modifiers2.28.2
2.28.3
The most common issue this fixes is failures on
SafeArg.of("name", null)assuming that the null literal value parameter may be a throwable.
2.29.0
StrictCollectionIncompatibleTypeto guard collection usageThese checks don't imply bugs, and automation will fix failing cases automatically, so it's not necessary to block compilation.
FinalClass moved to warning rather than suggestion because there are a few edge cases (e.g. dependent projects using mockito without inline mock maker) where releases can run into issues if the bots don't fix findings in time.
2.30.0
InvocationTargetException, otherwise anUndeclaredThrowableExceptionwill be throwneach time the delegate throws an exception.
2.31.0
2.32.0
assertstatements in test code.Tests should use more specific AssertJ checks, which cannot be disabled by turning off asserts. Arguably the
assertkeyword should never be used, preferring preconditions. This way production environments cannot reach code paths that are impossible to test.2.33.0
Slf4jThrowablecheck to ensure throwable args are logged last2.34.0
JooqResultStreamLeak, which ensures that result streams and cursors returned from jOOQ results are closed in a try-with-resources block.2.35.0
2.35.1
The refaster rule breaks the common pattern:
Suppliers.memoize(supplier::get).2.35.2
2.36.0
StreamEmptywith error proneStreamOfEmptyto allow refactors to retain type arguments.2.37.0
AssertjPrimitiveComparisonfor primitive comparisonsPrefer using AssertJ fluent comparisons over logic in an assertThat
statement for better failure output. assertThat(a == b).isTrue()
failures report 'expected true' where assertThat(a).isEqualTo(b)
provides the expected and actual values.
2.38.0
> 40% speedup when run against Google's codebase with errors enabled.
2.39.0
mockito-errorproneto get Mockito error-prone checks.2.40.0
CatchSpecificityandThrowSpecificityto avoid unnecessarily broad throwables.Prefer more specific catch types than Exception and Throwable.
When methods are updated to throw new checked exceptions they expect
callers to handle failure types explicitly. Catching broad types defeats
the type system. By catching the most specific types possible we
leverage existing compiler functionality to detect unreachable code.
SafeArg.of(when it's a last argument) are no longer unexpectedly split onto the next line.2.40.1
PreferJavaTimeOverloaderror-prone check is turned off as it produces noisy false positives relating to custom AssertJ utilities.2.40.2
2.41.0
No documented user facing changes
2.42.0
NonComparableStreamSortto validate that stream types implement comparable, as opposed to validating that casting to comparable does not cause a compiler error.This commit reduces the severity to WARNING because it's
possible that the check will flag code that happens to work
today, but we strongly recommend against sorting streams of
a type that is not directly comparable without a custom
comparator because it is likely to break later due to lack
of enforcement by the type system.
not enabled by default by providing a comma delimited list of check
names to the
-PerrorProneApplyoption.2.43.0
Automated release, no documented user facing changes
2.44.0
can result in subtle resource leaks. Prefer replacing existing gauge
values using
registerWithReplacement.This check doesn't apply unless a new enough version of Tritium
is available on the compilation classpath.
2.44.1
2.45.0
diff<br>- if (condition) statement;<br>+ if (condition) {<br>+ statement;<br>+ }<br>2.45.1
baseline-ideaplugin now correctly marks test resources as test resources in IntelliJ.2.46.0
2.47.0
com.palantir.baseline-class-uniquenessplugin now records conflicts in abaseline-class-uniqueness.lockfile. This should be checked-in to git and makes it easier to incrementally improve projects, rather than requiring a big-bang migration.2.48.0
2.48.1
./gradlew --write-lockswill now update the baseline-class-uniqueness.lock file.2.48.2
2.48.3
2.49.0
2.49.1
LoggerEnclosingClassedge cases for type parameters and anonymous classesTo enable or disable this check, please contact the maintainers of Excavator.