Allow for codegen targets to be used directly by JVM compiler requests #14751
Conversation
# Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust]
# Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust]
# Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust]
# Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust]
Both of these should likely be handled in the same way: via the |
# Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust]
# Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust]
…en input codegen type # Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust]
# Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust]
chrisjrn
changed the title
src/python/pants/jvm/compile.py
Outdated
| if not component.representative.has_field(input): | ||
| continue | ||
| if len(request_types) > 1: | ||
| raise ClasspathSourceAmbiguity( |
There was a problem hiding this comment.
at the moment, this will result in a late failure, and only if a user attempts to use a source file with conflicting implementations as a dependency. I could re-write to fail fast, but the code will eventually need to fail here once #14041 is in place.
There was a problem hiding this comment.
It's still not clear to me why this matching isn't happening inside of ClasspathEntryRequest.classify_impl. If it did, both 1) only matching the representative, 2) late erroring... would be handled by the existing code below, right? Because you'd match multiple impls.
There was a problem hiding this comment.
Yup, that all checks out. I'll make that refactor before landing this.
src/python/pants/jvm/compile.py
Outdated
| @@ -47,6 +54,38 @@ class _ClasspathEntryRequestClassification(Enum): | |||
| INCOMPATIBLE = auto() | |||
|
|
|||
|
|
|||
| @dataclass(frozen=True) | |||
| class JVMRequestTypes: | |||
There was a problem hiding this comment.
Nit: a more meaningful name would be good.
src/python/pants/jvm/compile.py
Outdated
| if not component.representative.has_field(input): | ||
| continue | ||
| if len(request_types) > 1: | ||
| raise ClasspathSourceAmbiguity( |
There was a problem hiding this comment.
It's still not clear to me why this matching isn't happening inside of ClasspathEntryRequest.classify_impl. If it did, both 1) only matching the representative, 2) late erroring... would be handled by the existing code below, right? Because you'd match multiple impls.
src/python/pants/jvm/compile_test.py
Outdated
| @@ -193,7 +194,7 @@ def classify( | |||
| members: Sequence[type[ClasspathEntryRequest]], | |||
| ) -> tuple[type[ClasspathEntryRequest], type[ClasspathEntryRequest] | None]: | |||
| req = ClasspathEntryRequest.for_targets( | |||
| UnionMembership({ClasspathEntryRequest: members}), | |||
| JVMRequestTypes(tuple(members), FrozenDict()), | |||
There was a problem hiding this comment.
This test should probably be expanded to also test some codegen impls.
…. Much better. # Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust]
# Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust]
chrisjrn
force-pushed
the
chrisjrn/14730-real-jvm-codegens
branch
from
7373631
to
39890bd
Compare
# Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust]
|
@stuhood Submitting for re-review just in case |
# Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust]
This amends
ClasspathEntryRequest.for_targetsto accept a codegen source request target and output aClasspathEntryRequestthat corresponds to a relevant JVM compilation request.With this approach, it seems that any
GenerateSourcesRequestwithoutputthat is compatible with aClasspathEntryRequestwill Just Work™. To demonstrate this in action, there's backend registration support for the Java and Scala protobuf generators included in this PR too.The main current limitation is when multiple language backends are enabled for a given codegen source type. A solution for this would address #14041, and realistically needs to take multiple JVM languages into account.