[AOSP-pick] Set moduleInfo on light class construction #7451
Conversation
This file contains 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
The existing pattern is that derived classes are supposed to call `setModuleInfo` during their initialization. Most do, but some have missed it, and this results in the Kotlin plugin not being able to appropriately identify the classes. I'm changing the code pattern to require `ModuleInfo` to be passed in via the constructor. The parameter is currently nullable in the super AndroidLightClassBase for the cases that don't have module information yet, so this change shouldn't affect any behavior. I'll follow up with another change to actually set the module information. Bug: n/a Test: covered by existing Change-Id: I2358ac1cd475880d76310df6b56fe04d64173017 AOSP: 5e907fbd0f6a77a1f8afcc8bcf399bb9e3e78a0a
sellophane
requested review from
mai93,
ujohnny,
LeFrosch and
agluszak
as code owners
github-actions
bot
added
the
awaiting-review
LeFrosch
approved these changes
Mar 10, 2025
github-actions
bot
removed
the
awaiting-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Cherry pick AOSP commit 5e907fbd0f6a77a1f8afcc8bcf399bb9e3e78a0a.
The existing pattern is that derived classes are supposed to call
setModuleInfoduring their initialization. Most do, but some havemissed it, and this results in the Kotlin plugin not being able to
appropriately identify the classes.
I'm changing the code pattern to require
ModuleInfoto be passed invia the constructor. The parameter is currently nullable in the super AndroidLightClassBase for the cases that don't have module information yet, so this change shouldn't affect any behavior. I'll follow up with another change to actually set the module information.
Bug: n/a
Test: covered by existing
Change-Id: I2358ac1cd475880d76310df6b56fe04d64173017
AOSP: 5e907fbd0f6a77a1f8afcc8bcf399bb9e3e78a0a