Generate Poko function declarations in FIR #465
Merged
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
drewhamilton
force-pushed
the
drew/fir-generated-poko-functions
branch
from
2689e85 to
205f21f
Compare
drewhamilton
force-pushed
the
drew/fir-generated-poko-functions
branch
from
205f21f to
a25f117
Compare
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.
Previously, we only modified code at the IR layer; finding the
Any.equals,Any.hashCode, andAny.toStringfunctions, modifying their dispatch receiver to the Poko class and generating the body. With this change, when K2 is enabled, we instead generate these function declarations for each Poko class in FIR, and then (still) fill in the body in IR. This should make it possible for theoretical FIR-based linters to recognize that Poko classes have implemented these functions.This new approach is hidden behind an experimental flag,
poko.experimental.enableFirDeclarationGeneration, and is disabled by default. It should not be used in production yet.Incidentally, this diverges from data classes, which do not declare these functions in FIR. I'm not sure if this is an intentional choice or just a holdover from pre-FIR days.Data classes declare these functions in FIR in a more complicated way than this in order to account for various possibilities in the superclass, like final overrides andexpect/actualdelarations. We'll have to mimic the resulting behavior before promoting this to default-enabled.