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

Compiler hooks #4474

Merged
merged 20 commits into from
Nov 4, 2022
Merged

Compiler hooks #4474

merged 20 commits into from
Nov 4, 2022

Conversation

BoD
Copy link
Contributor

@BoD BoD commented Oct 24, 2022

Tentative API.
Related to #4026.

@netlify
Copy link

netlify bot commented Oct 24, 2022

Deploy Preview for apollo-android-docs canceled.

Name Link
🔨 Latest commit bf6bd32
🔍 Latest deploy log https://app.netlify.com/sites/apollo-android-docs/deploys/6362737d1bcba4000967448d

}
}
if (hasTypeName) {
// XXX addSuperinterface(ClassName.bestGuess(interfaceName)) doesn't compile for an unknown reason, but this is equivalent
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no explanation. Using addSuperinterface triggers:

Overload resolution ambiguity: 
public final fun addSuperinterface(superinterface: KClass<*>, delegate: CodeBlock = ...): TypeSpec.Builder defined in com.squareup.kotlinpoet.TypeSpec.Builder
public final fun addSuperinterface(superinterface: TypeName, delegate: CodeBlock = ...): TypeSpec.Builder defined in com.squareup.kotlinpoet.TypeSpec.Builder

but that doesn't make sense to me. Maybe an issue related to r8?

Copy link
Contributor

@martinbonnin martinbonnin Oct 24, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's because we relocate the stdlib and KClass is relocated so the KClass from the addSuperinterface method is a different one from the one in build.gradle.kts

All in all, I think it's ok to have users of this feature rely on the external plugin. This way we don't have to keep kotlinpoet and don't risk breaking existing consumers.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch about KClass!

Ok to make it work with the external plugin, I agree that it's acceptable for this somewhat advanced feature

@martinbonnin
Copy link
Contributor

As explained above, I think it's ok to have this feature only if you're using the external plugin (maybe even detect it with reflection and throw if someone tries to use this with the shadowed plugin?).

Looking forward, it'd be nice to use the hooks:

  • internally for generateAsInternal
  • externally, with apollo-compiler-hooks that exposes RenamingHooks, DefaultToNullHooks, AddTypenameInterfaceHooks

Moving even forward. There's a question whether this is the correct level of abstraction. It's convenient and somewhat optimized because all the FileSpec hold in memory but we could also expose kotlin files and apollo metadata, similar to what the Kotlin compiler is doing, and have users use PSI to parse/rewrite the source.

@@ -457,6 +458,37 @@ public final class com/apollographql/apollo3/compiler/codegen/kotlin/helpers/Dat
public static final fun makeDataClassFromProperties (Lcom/squareup/kotlinpoet/TypeSpec$Builder;Ljava/util/List;)Lcom/squareup/kotlinpoet/TypeSpec$Builder;
}

public final class com/apollographql/apollo3/compiler/hooks/AddInternalCompilerHooks : com/apollographql/apollo3/compiler/hooks/DefaultApolloCompilerKotlinHooks {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be internal

public fun <init> ()V
public fun overrideResolvedType (Lcom/apollographql/apollo3/compiler/codegen/ResolverKey;Lcom/squareup/kotlinpoet/ClassName;)Lcom/squareup/kotlinpoet/ClassName;
public fun postProcessFileSpec (Lcom/squareup/kotlinpoet/FileSpec;)Lcom/squareup/kotlinpoet/FileSpec;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think most of that can be internal too?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant for DefaultApolloCompilerKotlinHooks to be public as an easy way to implement the hooks (extend it and only implement what you need).

AddInternalCompilerHooks, ApolloCompilerKotlinHooks$Identity and ApolloCompilerKotlinHooksChain are referenced from apollo-gradle-plugin-external so can't be internal but can be @ApolloInternal :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant for DefaultApolloCompilerKotlinHooks to be public as an easy way to implement the hooks

Fair enough.

can't be internal but can be @ApolloInternal

👍

@BoD BoD marked this pull request as ready for review October 26, 2022 15:37
@BoD BoD requested a review from sav007 as a code owner October 26, 2022 15:37
@BoD BoD merged commit fb51daf into main Nov 4, 2022
@BoD BoD deleted the compiler-apis branch November 4, 2022 09:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants