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

Autogenerate default Java constructors #2765

Closed
owengray-google opened this issue Dec 7, 2022 · 1 comment · Fixed by #2795
Closed

Autogenerate default Java constructors #2765

owengray-google opened this issue Dec 7, 2022 · 1 comment · Fixed by #2795
Labels
bug feedback: Google An issue/PR submitted by colleagues at Google, most likely related to the Android API reference docs good first issue A beginner-friendly issue for which some assistance is expected

Comments

@owengray-google
Copy link
Contributor

owengray-google commented Dec 7, 2022

Describe the bug
You do not autogenerate the default Java constructor. We autogenerate it downstream, but that causes us issues with the explicitly-hidden-constructor case.

(the first set of assertions is the Documentable tree, the second set is the component tree we/dackka generate from it)

@Test
fun `Default constructors are autogenerated when no explicit constructor is present`() {
    val moduleJ = """
        public class Foo {}
    """.trimIndent().render(java = true)
    val classlikeJ = moduleJ.page("Foo").data.content
    val moduleK = """
        public class Foo {}
    """.trimIndent().render(java = false)
    val classlikeK = moduleK.page("Foo").data.content

    // test the Documentables tree. The correct behavior would be both isNotEmpty
    for (module in listOf(moduleJ, moduleK)) {
        val classlike = module.explicitClasslike("Foo")
        if (module == moduleK)
            assertThat((classlike as DClass).constructors).isEmpty()
        else
            assertThat((classlike as DClass).constructors).isNotEmpty()
    }

    // test the Documentables tree. The correct behavior is both isNotEmpty
    for (classlike in listOf(classlikeJ, classlikeK)) {
        assertThat(classlike.data.publicConstructorsDetails).isNotEmpty()
    }
}

@Test
fun `Default constructors are not autogenerated when private-constuctor pattern is used`() {
    val moduleJ = """
        public class Foo { private Foo() {} }
    """.trimIndent().render(java = true)
    val classlikeJ = moduleJ.page("Foo").data.content
    val moduleK = """
        public class Foo private constructor() {}
    """.trimIndent().render(java = false)
    val classlikeK = moduleK.page("Foo").data.content

    // test the Documentables tree. The correct behavior is both isEmpty
    for (module in listOf(moduleJ, moduleK)) {
        val classlike = module.explicitClasslike("Foo")
        assertThat((classlike as DClass).constructors).isEmpty()
    }

    // test our Components tree. The correct behavior is both isEmpty.
    // Our fix for the next test breaks us in this case. I think this is unavoidably upstream.
    for (classlike in listOf(classlikeJ, classlikeK)) {
        if (classlike == classlikeK)
            assertThat(classlike.data.publicConstructorsDetails).isNotEmpty()
        else
            assertThat(classlike.data.publicConstructorsDetails).isEmpty()        }
}
@vmishenev vmishenev added the feedback: Google An issue/PR submitted by colleagues at Google, most likely related to the Android API reference docs label Dec 8, 2022
@IgnatBeresnev
Copy link
Member

The problem seems to be that PsiClass#getConstructors returns an empty array for the following class:

/**
 * Java documentation
 */
public class JavaClass {
    
}

We create DClass from Java PSIs in DefaultPsiToDocumentableTranslator.

I don't see any methods that would return the default empty constructor, so we might need to hardcode it (i.e create a DFunction for the constructor on the fly). However, there might already exist a function among PSIs that can either return the default primary constructor or create a synthetic one - it needs to be researched first.

For anyone looking to contribute, Developer Guides might be a good place to start.

@IgnatBeresnev IgnatBeresnev added the good first issue A beginner-friendly issue for which some assistance is expected label Dec 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug feedback: Google An issue/PR submitted by colleagues at Google, most likely related to the Android API reference docs good first issue A beginner-friendly issue for which some assistance is expected
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants