[swift2objc] feat:support swift tuples(return types)#3158
Open
Hassnaa9 wants to merge 21 commits intodart-lang:mainfrom
Open
[swift2objc] feat:support swift tuples(return types)#3158Hassnaa9 wants to merge 21 commits intodart-lang:mainfrom
Hassnaa9 wants to merge 21 commits intodart-lang:mainfrom
Conversation
Hassnaa9
changed the title
PR HealthBreaking changes ✔️
This check can be disabled by tagging the PR with Changelog Entry ✔️
Changes to files need to be accounted for in their respective changelogs. This check can be disabled by tagging the PR with License Headers ✔️
All source files should start with a license header. Unrelated files missing license headers
This check can be disabled by tagging the PR with API leaks ✔️The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.
This check can be disabled by tagging the PR with |
Contributor
|
One of the bot failures is just coveralls network issues, but the other looks legit: https://github.com/dart-lang/native/actions/runs/22406283204/job/64913395071?pr=3158 |
Contributor
Author
I think it's due to nested declaration, |
Contributor
Author
|
@liamappelbe Done |
liamappelbe
reviewed
Feb 25, 2026
Contributor
Author
|
Hi @liamappelbe , After I investigated the failure So i updated Do you think this properly addresses the root cause, or might there be a deeper structural issue we should consider? |
Contributor
No, unfortunately that's not the right fix, since it still has the problem where the namers won't be nested correctly. Do you know what I mean by that? Nested declarations need to be uniquely named with their parent's scope. The Conceptually though, the thing you're trying to do is valid, and I'm a bit confused how we haven't run into this before. Now I'm thinking our test coverage is just not good enough, and you're exposing an existing bug. Let me take a look at it and I'll send you a patch in a bit. |
Contributor
|
Yeah, there's actually an existing bug you're hitting. I'm able to reproduce it in a new test at HEAD, but that also exposes another bug. That shouldn't block your PR tho, so just apply this patch to your transform.dart file, and I'll fix the other issue and add a test later. Usually you can just save this diff to a file and then do diff --git a/pkgs/swift2objc/lib/src/transformer/transform.dart b/pkgs/swift2objc/lib/src/transformer/transform.dart
index da9ee70d..b1960dbb 100644
--- a/pkgs/swift2objc/lib/src/transformer/transform.dart
+++ b/pkgs/swift2objc/lib/src/transformer/transform.dart
@@ -31,6 +31,8 @@ class TransformationState {
// Bindings that will be generated as stubs.
final stubs = <Declaration>{};
+
+ late final UniqueNamer globalNamer;
}
/// Transforms the given declarations into the desired ObjC wrapped declarations
@@ -61,7 +63,7 @@ List<Declaration> transform(
state.stubs.addAll(listDecls.stubDecls);
state.bindings.addAll(listDecls.stubDecls);
- final globalNamer = UniqueNamer(
+ state.globalNamer = UniqueNamer(
state.bindings.map((declaration) => declaration.name),
);
@@ -72,9 +74,9 @@ List<Declaration> transform(
final transformedDeclarations = [
...topLevelDecls.map(
- (d) => maybeTransformDeclaration(d, globalNamer, state),
+ (d) => maybeTransformDeclaration(d, state.globalNamer, state),
),
- transformGlobals(globals, globalNamer, state),
+ transformGlobals(globals, state.globalNamer, state),
].nonNulls.toList();
return [
@@ -112,10 +114,20 @@ Declaration? maybeTransformDeclaration(
}
if (declaration is InnerNestableDeclaration &&
- declaration.nestingParent != null) {
+ declaration.nestingParent != null &&
+ !nested) {
// It's important that nested declarations are only transformed in the
- // context of their parent, so that their parentNamer is correct.
- assert(nested);
+ // context of their parent, so that their parentNamer is correct. So find
+ // the top level declaration this is nested in, and transform that first.
+ maybeTransformDeclaration(
+ _topLevelNestingParent(declaration),
+ state.globalNamer,
+ state,
+ );
+
+ // Now that the parents are transformed, this declaration should haven been
+ // transformed, and will be in the cache.
+ return state.map[declaration]!;
}
return switch (declaration) {
@@ -136,3 +148,8 @@ List<Declaration> _getPrimitiveWrapperClasses(TransformationState state) =>
.map((entry) => entry.value)
.nonNulls
.toList();
+
+Declaration _topLevelNestingParent(Declaration declaration) =>
+ declaration is InnerNestableDeclaration && declaration.nestingParent != null
+ ? _topLevelNestingParent(declaration.nestingParent!)
+ : declaration; |
Contributor
Contributor
|
@Hassnaa9 you can wait for #3173 to land (probably monday), or you can apply this patch and we can get this PR landed today. |
Contributor
Author
|
@liamappelbe I think the tuple tests were exposing issues because they went through a different transformation path than the usual flow. I applied the patch you suggested to transform.dart Really many thanks for your clarifications, I benefited a lot from them! |
liamappelbe
approved these changes
Feb 27, 2026
liamappelbe
requested changes
Feb 27, 2026
Contributor
liamappelbe
left a comment
liamappelbe
left a comment
There was a problem hiding this comment.
Uh oh, looks like you've still got a test failure: https://github.com/dart-lang/native/actions/runs/22470168665/job/65085133495?pr=3158
Contributor
Author
@liamappelbe i think while transforming nested tuples could hit a is it will be okay? the solution would be instead of |
Contributor
I don't like it (feels brittle), but I think we're reaching the limits of what can be done with this sort of approach to naming. The proper fix is to completely rewrite how naming is done to use a transformer approach. I had to do this for FFIgen a while ago. But obviously I don't expect you to do that, so you can apply your quick fix for now. Can you just add a TODO next to your fix, like this? |
Contributor
Author
|
@liamappelbe Ok, I added the TODO line |
Contributor
|
Yeah, that's the same issue I hit. Probably best just to wait for my fix to land then. |
Contributor
|
Fix has landed. Try syncing to HEAD |
Contributor
Author
|
@liamappelbe I think all is good now except the null check workaround we discussed earlier with TODO comment. |
Contributor
|
Integration test failure? https://github.com/dart-lang/native/actions/runs/22561339035/job/65351318524?pr=3158 |
Contributor
Author
@liamappelbe I think it's related to this bug? |
Contributor
Oh right, sorry. We can't land this with failing tests, so comment out the part of the test that is failing, and leave another TODO to uncomment it when that bug is fixed. |
Contributor
Author
|
@liamappelbe Done! |
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.
This PR cleans up the commit history of the support-swift-tuples branch by removing merge commits from syncing with main.
Closes: #3098
Fix: #1783