-
Notifications
You must be signed in to change notification settings - Fork 10.5k
SR-2405 Print IB_DESIGNABLE and IBInspectable in the generated ObjC header #5252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good, a few comments on the tests. Were you able to test this in Xcode as well for both frameworks and apps, or would you like me to try that?
test/PrintAsObjC/classes.swift
Outdated
@@ -318,6 +318,13 @@ typealias AliasForNSRect = NSRect | |||
func testBridgingOptionality(_ a: UnsafePointer<Int>?, b: UnsafeMutablePointer<Int>!, c: AutoreleasingUnsafeMutablePointer<Methods?>?) {} | |||
} | |||
|
|||
// CHECK-LABEL: IB_DESIGNABLE | |||
// CHECK-LABEL: @interface MyDesignableObject : NSObject |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here CHECK-LABEL
is a sort of "start over" annotation. I think it makes more sense to check that the IB_DESIGNABLE
is actually attached to MyDesignableObject using CHECK-NEXT, even though it means we need to match the next line as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(CHECK-NEXT does handle partial matches, so you don't actually have to include the mangled name.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure of that? I'm using CHECK LABEL
because using CHECK NEXT
was failing on the mangled name. Or at least is what I've understood from the test report.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, the case I'm concerned about looks like this:
IB_DESIGNABLE // first CHECK-LABEL matches here
SWIFT_RUNTIME_NAME("...")
@interface SomeUnrelatedObject
@end
SWIFT_RUNTIME_NAME("...")
@interface MyDesignableObject : NSObject // next CHECK-LABEL matches here
The only way to tell that the two have anything to do with each other is to use CHECK-NEXT so that we know what's exactly in between. I think this would be sufficient:
// CHECK-LABEL: IB_DESIGNABLE
// CHECK-NEXT: SWIFT_RUNTIME_NAME(
// CHECK-NEXT: @interface MyDesignableObject : NSObject
I don't think I'm understanding what you ask... Edit: removing the double negation :), sorry I have to stop trying to write in English at 2 am... |
Welcome to the project! |
Thank you @lattner :) |
Normally running build-script -t would be sufficient, but like I said in the bug I'm worried about IB's detection of IBDesignable/IBInspectable getting confused. The way to test this would be to build a toolchain and try using it with Xcode in various scenarios. That's definitely a little more involved than we'd usually ask from a first-time contributor, though, so I'll see if I can find time to test it for you. Thanks again for taking this! |
I've change the test to use CHECK-NEXT instead of the double CHECK-LABEL |
@swift-ci please smoke test. |
Sorry, this is still waiting on me testing it in an Xcode! I'll file a bug against myself so I don't let it keep slipping. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(marking as blocked so it doesn't get drive-by merged)
We lost the testing logs for this a long time ago. @swift-ci please smoke test |
The failure can be caused by being behind master of like a 10000 commit? I can push a rebase if it can help. Edit: 10.000 commits, not 1.000 😅 |
@swift-ci please smoke test |
@jrose-apple there are any news on this PR? |
Still haven't tested it. :-( |
I've rebased the branch to see if everything is ok, and merged the two commit into for a cleaner history |
Holy crap, why did this kick off CI? // @shahmishal |
@JGiola If you want to try to build your own toolchain and plug it into Xcode yourself, this script should get you most of the way there. |
Ok, I will try this week when I find a moment and report back the results (only doubt is if I can test Xcode on all the intended scenarios). |
1d9fcc7
to
ad553f6
Compare
I can't make a running toolchain. I'm building from zero with |
@JGiola I spent some time updating the script and pushed a new version of the gist. Unfortunately, I'm seeing some MMX include oddities but that could be due to my box still being on 10.12.6. You may need to edit some headers to get things to build, but it should work for macOS projects at least. |
@swift-ci please smoke test |
Sorry for being missing from here, I haven’t received the notification for your message in October. |
40658f3
to
d2213bb
Compare
8106463
to
93e466a
Compare
e4a61e3
to
81af97e
Compare
Is this ready for a re-review or CI testing? There have been lots of force pushes since over a year and no one has re-reviewed it. (I’m happy to test the toolchain in Xcode - anything important that I should look for?). |
I'm trying to keep it on par with master, but it seems I'm incapable to build a toolchain on my machine (the build-toolchain script always exit with an error and I can't find a solution). The gist of testing on Xcode is to observe if the generated Obj-C headers with the IBDesignable and/or IBInspectable annotation can confuse it. |
What's the error that you get? |
Maybe I was doing something wrong at the time but after some trouble I have a seemingly functional toolchain, but the generated Obj-C headers don’t contain my changes so 🤷♂ |
Add support for @IBDesignable and @IBInspectable attribute to the generated ObjC headers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I owe you a huge apology for just letting this sit for literally three years. And possibly a cupcake or something if we ever meet in person.
I finally tested this in Xcode and it looks good—no duplicate fields showing up in IB or anything. Xcode does get a little confused and thinks that there might be a designable class named "MyDesignableObject" as well as "MyModule.MyDesignableObject", but that's not really different from any other case where Xcode gets confused about ObjC names being different from Swift names. (A custom @objc
on a property won't be respected by IB, for example.) So let's take it, and I'll let you know if it has problems inside of Apple.
@swift-ci Please smoke test |
@swift-ci Please test source compatibility |
@swift-ci Please smoke test Linux |
I can not refuse a free cupcake 😄, but seriously no problem. It was fun to keep in sync with master every once in a while. |
Add support for @IBDesignable and @IBInspectable attribute to the
generated ObjC headers.
It’s my first try to commit to a project like this, and I’m not so sure if I get how the tests works.
I’m doing it right? I have to add some more?