Fix binary name computation for default-package classes in the KSP processor - #2129
Merged
Conversation
copybara-service
Bot
force-pushed
the
test_977860974
branch
from
September 8, 2026 17:03
ca23eb3 to
18cf357
Compare
…ocessor The KSP processor was added a couple of weeks ago, and I found two things in it while reading it against the APT version. 1. Binary names for classes in the default package are wrong. getBinaryName always strips '<package>.' from the qualified name, but for a root-package class there is no such prefix, so it drops the first character and leaves a stray dot: a provider Foo ends up written as .oo in the service file. The Java AutoServiceProcessor handles the unnamed package explicitly (it just returns the class name), so the KSP side should do the same. This only bites people who put providers in the default package, which is rare, but the generated file is just wrong when it happens. 2. The generated META-INF/services/<interface> file is an aggregating output but is declared isolating (aggregating=false). Each file collects every @autoservice provider of that interface anywhere in the module, so a provider in a brand-new source file changes it. With aggregating=false, KSP won't invalidate the file when an unrelated new source is added, so on an incremental build a newly added provider never shows up in the service file. Setting aggregating=true tells KSP to regenerate it whenever there's new input. No test added: the KSP test harness (room3) needs a full KSP/Kotlin compile that I couldn't run in my environment, and the existing tests only cover packaged classes. Both changes are behaviour-preserving for the common packaged case. Fixes #2128 COPYBARA_INTEGRATE_REVIEW=#2128 from rootkiller6788:fix-autoservice-ksp-default-package-aggregating cf6ade9 PiperOrigin-RevId: 977976344
copybara-service
Bot
force-pushed
the
test_977860974
branch
from
September 8, 2026 17:10
18cf357 to
1f74d9a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix binary name computation for default-package classes in the KSP processor
The KSP processor was added a couple of weeks ago, and I found two things in it while reading it against the APT version.
Binary names for classes in the default package are wrong. getBinaryName always strips '.' from the qualified name, but for a root-package class there is no such prefix, so it drops the first character and leaves a stray dot: a provider Foo ends up written as .oo in the service file. The Java AutoServiceProcessor handles the unnamed package explicitly (it just returns the class name), so the KSP side should do the same. This only bites people who put providers in the default package, which is rare, but the generated file is just wrong when it happens.
The generated META-INF/services/ file is an aggregating output but is declared isolating (aggregating=false). Each file collects every @autoservice provider of that interface anywhere in the module, so a provider in a brand-new source file changes it. With aggregating=false, KSP won't invalidate the file when an unrelated new source is added, so on an incremental build a newly added provider never shows up in the service file. Setting aggregating=true tells KSP to regenerate it whenever there's new input.
No test added: the KSP test harness (room3) needs a full KSP/Kotlin compile that I couldn't run in my environment, and the existing tests only cover packaged classes. Both changes are behaviour-preserving for the common packaged case.
Fixes #2128
FUTURE_COPYBARA_INTEGRATE_REVIEW=#2128 from rootkiller6788:fix-autoservice-ksp-default-package-aggregating cf6ade9