Removed UnnecessaryAbstractClass if it inherits from a abstract class

[gouri-panda]

closes: #4753

Removed UnnecessaryAbstractClass if it inherits from abstract class an interface or that has concrete members.

[BraisGabin]

This test shouldn't change, right?

[gouri-panda]

@BraisGabin If we don't change it, the tests will fail. I don't understand your question.

[BraisGabin]

But this one was right. An abstract class that only extends an interface is an unnecessary abstract class. The only one that should change is the case where an abstract class extend another abstract class because there you can't use an interface. (maybe I'm missing something here)

[gouri-panda]

Should I revert that?

[BraisGabin]

Yes. This test shouldn't change.

[schalkms]

Thanks for the fix - appreciate it!

[schalkms]

@gouri-panda please try to rebase this branch and fix the following rule violation. Then this PR is good to go. 👍

UnnecessaryAbstractClass.kt:83:25: Function check has 3 return statements which exceeds the limit of 2. [ReturnCount]

[amitd291]

The following enhancement to this logic will ensure the rule still fails for interface super types (as discussed in @BraisGabin's comment):

hasInheritedMember(true) && !isParentInterface() -> return

private fun KtClass.isParentInterface() =
    (bindingContext[BindingContext.CLASS, this]?.unsubstitutedMemberScope as? LazyClassMemberScope)
        ?.supertypes?.firstOrNull()?.isInterface() == true

[gouri-panda]

@amitdash291 Thanks for advice and code :)

[amitd291]

I think there's a corner case to test here. What if the class implements an interface and inherits from an abstract class in that order. For eg the following may fail the rule whereas it's expected to pass:

interface I

abstract class A
// some abstract fields here

abstract class B: I, A()

cc @gouri-panda @BraisGabin

[BraisGabin]

Is that even valid Kotlin code? Shouldn't the class be defined the first one? I can't check right now. Anyway, a test extending both, a class and an interface seems like a really good case to have a test. @guori-panda, can you add such test?

[amitd291]

@BraisGabin yes interestingly this is valid Kotlin code, given below is the test case (that compiles):

@Test
fun `does not report abstract class that inherits from an interface and an abstract class in that order`() {
    val code = """
        interface I

        @Deprecated("We don't care about this first class")
        abstract class A {
            abstract val i: Int
        }
        
        abstract class B: I, A()
    """
    val findings = subject.compileAndLintWithContext(env, code)
    assertThat(findings).isEmpty()
}

[amitd291]

Refer reply to the code suggestion earlier.

[BraisGabin]

@gouri-panda sorry for all the changes. Can you fix the conflicts and add the tests that @amitdash291 point out here: #5009 (comment) ?

After that (and if that test passes) I think that this is ready to merge.

[gouri-panda]

@BraisGabin @amitdash291 Sure :)

[BraisGabin]

Thanks for the updates :). This still has conflicts, could you check that?

[BraisGabin]

Suggested change

	abstract class B: A(), I
	abstract class B: A(), I
	abstract class C: I, A()

We should check both cases.

[gouri-panda]

Sure! Let me add another test case as well!

[amitd291]

@gouri-panda I have an idea to solve this in a generic manner. If you're okay I can raise a PR on your fork branch gouri-panda:fix-4753?

[gouri-panda]

I was thinking if we check one of the parent is abstract, then we can return. But go for it :)

[amitd291]

@gouri-panda
I have pushed my changes as a PR to your fork's branch here
In summary I have checked if not all the parents are interfaces, which is equivalent of the fact that at least one parent is abstract.
Please refer to this commit (there are a few other merge commits)

[BraisGabin]

Thanks for the fix @gouri-panda and @amitdash291