generate extensions of wrapper types owned by other modules - #852
Open
Tatenda-k wants to merge 1 commit into
Open
generate extensions of wrapper types owned by other modules#852Tatenda-k wants to merge 1 commit into
Tatenda-k wants to merge 1 commit into
Conversation
ktoso
reviewed
Jul 29, 2026
ktoso
reviewed
Jul 29, 2026
ktoso
reviewed
Jul 29, 2026
ktoso
reviewed
Jul 29, 2026
ktoso
reviewed
Jul 29, 2026
ktoso
reviewed
Jul 29, 2026
Tatenda-k
force-pushed
the
main
branch
3 times, most recently
from
August 2, 2026 21:50
146fdf0 to
9867f20
Compare
Teaches wrap-java to generate a Swift extension of a wrapper type that is defined in a different Swift module, containing only the members whose signature or return type references at least one type wrapped by the module being generated. A module can only wrap a Java member when it can name every type in that member's signature. Members mentioning a type wrapped by a downstream module were silently dropped, and the downstream module had no way to add them back except by hand -- java.lang.Class's reflection methods are the motivating case, previously patched in by JavaClass+Reflection.swift. Adds `extendForeignClasses` to the configuration: a module lists Java classes whose Swift wrapper is owned elsewhere, and wrap-java emits an `extension` of that wrapper containing exactly the members whose signature references a type this module owns. Members the owning module could already express are left alone, so nothing is duplicated.
Collaborator
|
Small comment while I'm reviewing -- I think this is good, but I'm wondering if we can get away without specififying the extended types in the configuration file. I'll look into it some more, but if you're interested in figuring that out that'd be great :) |
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
2 participants
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.
What
Teaches
wrap-javato generate a Swiftextensionof a wrapper type that is defined in a different Swift module, containing only the members whose signatures or return type references at least one type wrapped by the module being generated.Opt in per-module via a new manifest field:
"extendForeginclasses": ["java.lang.Class"]
Update
I have generated the foreign extensions.
I added classes to the
extendForeignClassesarrays by running a script that regenerates every module and captures each [warning] Unable to translate '' '': Java class '' has not been translated . It then builds a Java-class → owning-module map from the classes map of every Sources/**/swift-java.config, and adds to the list if the dropped member's unresolved type is wrapped by a different module.#18