Fixes false negatives in UnnecessaryAbstractClass

[BraisGabin]

This PR fixes a false positive in UnnecessaryAbstractClass.

Before this PR the class B wasn't flagged:

interface A {
    val i: Int
}
abstract class B : A

And the same here:

abstract class A {
    abstract val i: Int
}
abstract class B : A()

This PR also improves the messages reported for this rule.

[codecov]

Codecov Report

Merging #4399 (cfcaf6d) into main (70e05ac) will increase coverage by 0.01%.
The diff coverage is 56.00%.

@@             Coverage Diff              @@
##               main    #4399      +/-   ##
============================================
+ Coverage     84.33%   84.35%   +0.01%     
- Complexity     3272     3281       +9     
============================================
  Files           473      472       -1     
  Lines         10351    10356       +5     
  Branches       1826     1828       +2     
============================================
+ Hits           8730     8736       +6     
  Misses          668      668              
+ Partials        953      952       -1     

Impacted Files	Coverage Δ
...h/detekt/core/baseline/IndentingXMLStreamWriter.kt	56.33% <45.00%> (+0.62%)	⬆️
...sch/detekt/rules/style/UnnecessaryAbstractClass.kt	86.66% <100.00%> (-0.29%)	⬇️
...detekt/rules/style/UnderscoresInNumericLiterals.kt	87.23% <0.00%> (+4.30%)	⬆️

---

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 70e05ac...cfcaf6d. Read the comment docs.

[schalkms]

I guess the mentioned code snippets aren't flagged a second time by the empty rule set, right?

[schalkms]

Where did you improve the message description?

This PR also improves the messages reported for this rule.

[BraisGabin]

You are right. I didn't "improve the message". Before there were some issues that had the message "An abstract class without an abstract member can be refactored to a concrete class." but it should be "An abstract class without a concrete member can be refactored to an interface." and the improvement was that. I set the correct message to some issues that were getting the wrong one.

[BraisGabin]

I guess the mentioned code snippets aren't flagged a second time by the empty rule set, right?

I guess that some cases are flagged by that rule set too. And I think that it's good that both rules flag it because one developer could have one of those issues disabled.

[schalkms]

If I remember correctly, we excluded those cases for exactly this reason. Thus, the same code is not flagged twice by two different rules. I could be wrong here, however.

I guess that some cases are flagged by that rule set too. And I think that it's good that both rules flag it because one developer could have one of those issues disabled.

[BraisGabin]

I didn't introduce those cases in this PR. Those cases where there already, they weren't tested but they were flagged. I just extended the tests to ensure that I didn't break anything.

[schalkms]

I'm afraid, I didn't understand this statement. As I understood the description of the rule, you fixed a false-positive in this PR (e.g. abstract class B : A as well as abstract class B : A()).

I didn't introduce those cases in this PR. Those cases where there already, they weren't tested but they were flagged.

[BraisGabin]

This rule was already flagging code at the same time as the empty rule set. I didn't introduce that issue here. For example:

abstract class A : B {}

It was flagged by UnnecessaryAbstractClass and by EmptyClassBlock.

For that reason I say that I didn't introduce this "double report", it was there. For sure, now there are more "double reports" but that is because now UnnecessaryAbstractClass is working as expected.

[schalkms]

Thanks for the elaboration, Brais! It's good to merge.