Fix a false positive for CastToNullableType for casting a literal `null` to a nullable type. This can be necessary when providing null as a function argument where the incoming type is parameterized. In this case using e.g. `null as? String` is less meaningful and generates a compiler warning that the cast cannot succeed.
This rule is based on discussion #4890.
Checks for suppression of one or more rules that have been decided to
never be suppressed within a code base. For example, if we've set
MaximumLineLength to a value, every file must be compliant, and if there
is a special case where compliance is discouraged, we can simply exclude
this file within YML configuration.
This rule cannot prevent itself from being suppressed, but should serve
to discourage the over use of `@Suppress` annotations.
* Allow additionalJavaSourceRootPaths to be defined on @KotlinCoreEnvironmentTest
* update api
* Rename top level nested classes to WithDefaultSources and WithAdditionalJavaSources
* fix compilation error in java < 11
* fix upstream merge
* fix: do not attempt to compile snippet with java class from resource
* manually fix indentation of test snippets
Co-authored-by: Markus Schwarz <post@markus-schwarz.net>
* implement first idea on values with reasons
* have ExplainedValues implement List by delegation
* Parse explained value defaults
* fix error message
* [WIP] support ExplainedValues in yaml
* print markdown value in DefaultValue directly
* quote values in yaml maps
* Update detekt-api/src/main/kotlin/io/gitlab/arturbosch/detekt/api/ConfigProperty.kt
Co-authored-by: Brais Gabín <braisgabin@gmail.com>
* Update detekt-api/src/main/kotlin/io/gitlab/arturbosch/detekt/api/ConfigProperty.kt
Co-authored-by: Brais Gabín <braisgabin@gmail.com>
* add test case for missing reason
* fail fast in case of invalid configuration
* rename explainedValues to valuesWithReason
* add api documentation
* resolve and suppress code smells
* suppress UNCHECKED_CAST
* merge RuleCollectorSpec
* reformat spec
* fix indentation of test code
Co-authored-by: Markus Schwarz <post@markus-schwarz.net>
Co-authored-by: Brais Gabín <braisgabin@gmail.com>
Fix an issue where UselessCallOnNotNull would report issues when some of the argument types resolved as ErrorType. While it correctly handles cases where the BindingContext cannot resolve a type (the first test case), in cases where a call is made on an unknown type (the second test case, e.g. via takeIf{}) the BindingContext will report it as an ErrorType. Since ErrorType.isNullable() apparently returns false we need to make an exception to ensure the rule behaves as expected.
* Update MagicNumber rule to exclude .kts files
The MagicNumber rule should not be enforced in script files,
because you cannot have constants in these files.
Closes#4863
* Adapt Exclusion.kt for MagicNumber rule
CanBeNonNullable reports that properties of parameterized types can be marked as non-nullable even when this is impossible, just because the parameterized type is itself nullable (i.e. does not inherit from a non-nullable type). Instead, the rule should only report cases where a property is explicitly marked nullable but does not need to be.
Add a new rule which enforces the recommendation of the Kotlin coding conventions to prefer `==` over `?:` when converting a `Boolean?` into a `Boolean`: https://kotlinlang.org/docs/coding-conventions.html#nullable-boolean-values-in-conditions. This is simple to implement and enforces consistency for the two essentially equivalent methods of coalescing nullable boolean values.
The coding conventions only specify this preference for usages "in a conditional statement" but the same rationale applies to any statement which converts a Boolean? to a Boolean, so I have implemented it for any situation. An alternative is to add a configuration setting to toggle application only in if statements.
Unfortunately, this rule requires type resolution since there are technically valid usages of e.g. `value ?: true` for cases where `value` is not a `Boolean?` but an `Any?`. Running without type resolution will not be able to distinguish between these valid usages and ones which could be converted to `== false`.
* UnnecessaryInnerClass: fix false positives labeled expression to outer class
Fix an issue where inner classes which reference their outer class via a labeled
expression would still be reported as unnecessary. This seems to be due to a
missing visitExpressionWithLabel() check which resolves the label name: if the
label is referencing a parent class, then the nested class must be `inner`.
I wasn't able to find a way to resolve the labeled expression as a ClassId to
match the existing class check from KtReferenceExpression, so I settled for
using the class name instead, which is easy to obtain. This means there's a fair
bit of duplication in overriden checkForOuterUsage() methods to check parent
classes which could probably be removed, but I didn't see a particularly clean
way to do so.
* UnnecessaryInnerClass: add test for double-nested inner classes using labeled expressions
It appears that the contributor list in the readme has been replaced by an autogenerated image of the contributors; the contribution guide should no longer suggest contributors add their name there.
Add a unit test for a bug in which safe qualified references to a nullable field
in the parent class (i.e. as `?.`) would not be marked as warnings in release
1.20.0. This issue has been inadvertently fixed by
https://github.com/detekt/detekt/pull/4738, but adding a unit test will guard
against future regressions.
I was able to confirm this test fails by checking out the 1.20.0 tag and running
the unit test; against that tag the fix was to override the
visitSafeQualifiedExpression() function with the same logic as
visitCallExpression().
* Report KDoc comments that refer to encapsulated properties of a class
New rule to address the issue of breaking encapsulation principle when KDoc comments have references to encapsulated (private) properties.
Clients do not need to know the implementation details.
* Rename rule to 'KDocReferencesNonPublicProperty' and fix naming
* Set 'protected' modifier as allowed
* Improve tests
* Fix rule documentation
