Skip to content

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

Merged
merged 1 commit into from
Oct 21, 2019

Conversation

JGiola
Copy link
Contributor

@JGiola JGiola commented Oct 12, 2016

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?

Copy link
Contributor

@jrose-apple jrose-apple left a 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?

@@ -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
Copy link
Contributor

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.

Copy link
Contributor

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.)

Copy link
Contributor Author

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.

Copy link
Contributor

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

@JGiola
Copy link
Contributor Author

JGiola commented Oct 13, 2016

I don't think I'm understanding what you ask...
I have run the tests with through the utils/build-script -t, what I have to do to do the additional tests you asks?

Edit: removing the double negation :), sorry I have to stop trying to write in English at 2 am...

@lattner
Copy link
Contributor

lattner commented Oct 13, 2016

Welcome to the project!

@JGiola
Copy link
Contributor Author

JGiola commented Oct 13, 2016

Thank you @lattner :)
And thanks to the Hacktoberfest initiative to finally made me try to contribute!

@jrose-apple
Copy link
Contributor

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!

@JGiola
Copy link
Contributor Author

JGiola commented Oct 14, 2016

I've change the test to use CHECK-NEXT instead of the double CHECK-LABEL

@jrose-apple jrose-apple self-assigned this Oct 14, 2016
@CodaFi
Copy link
Contributor

CodaFi commented Jan 13, 2017

@swift-ci please smoke test.

@jrose-apple
Copy link
Contributor

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.

Copy link
Contributor

@jrose-apple jrose-apple left a 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)

@CodaFi
Copy link
Contributor

CodaFi commented Jun 4, 2017

We lost the testing logs for this a long time ago.

@swift-ci please smoke test

@JGiola
Copy link
Contributor Author

JGiola commented Jun 5, 2017

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 😅

@CodaFi
Copy link
Contributor

CodaFi commented Jun 9, 2017

@swift-ci please smoke test

@JGiola
Copy link
Contributor Author

JGiola commented Jul 18, 2017

@jrose-apple there are any news on this PR?

@jrose-apple
Copy link
Contributor

Still haven't tested it. :-(

@JGiola
Copy link
Contributor Author

JGiola commented Sep 21, 2017

I've rebased the branch to see if everything is ok, and merged the two commit into for a cleaner history

@CodaFi
Copy link
Contributor

CodaFi commented Sep 21, 2017

Holy crap, why did this kick off CI? // @shahmishal

@CodaFi
Copy link
Contributor

CodaFi commented Sep 22, 2017

@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.

@JGiola
Copy link
Contributor Author

JGiola commented Sep 24, 2017

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).

@JGiola JGiola force-pushed the SR-2405 branch 3 times, most recently from 1d9fcc7 to ad553f6 Compare October 2, 2017 19:56
@JGiola
Copy link
Contributor Author

JGiola commented Oct 2, 2017

I can't make a running toolchain. I'm building from zero with swift/utils/build-script -R --llbuild --swiftpm and then run the script, but when I start the basic single view project in Xcode and open one of the swift file the source editor doesn't highlight or do anything at all asking me to report the bug...
I'm missing some steps to produce a functioning toolchain?

@CodaFi
Copy link
Contributor

CodaFi commented Oct 3, 2017

@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.

@CodaFi
Copy link
Contributor

CodaFi commented Dec 9, 2017

@swift-ci please smoke test

@JGiola
Copy link
Contributor Author

JGiola commented Dec 10, 2017

Sorry for being missing from here, I haven’t received the notification for your message in October.
Today I’ve tried to build the toolchain with your updated script but when I fire up Xcode the source editor will crash every time :/
I don’t know what I’m doing wrong...

@shahmishal
Copy link
Member

@theblixguy
Copy link
Collaborator

theblixguy commented Oct 7, 2019

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?).

@JGiola
Copy link
Contributor Author

JGiola commented Oct 8, 2019

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.

@theblixguy
Copy link
Collaborator

What's the error that you get?

@JGiola
Copy link
Contributor Author

JGiola commented Oct 15, 2019

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 🤷‍♂
And to add the worst, every toolchain build on my mbp took like 4/5 hours every time (with a full deletion of everything because I will run low on disk space)

Add support for @IBDesignable and @IBInspectable attribute to the
generated ObjC headers
Copy link
Contributor

@jrose-apple jrose-apple left a 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.

@jrose-apple
Copy link
Contributor

@swift-ci Please smoke test

@jrose-apple
Copy link
Contributor

@swift-ci Please test source compatibility

@jrose-apple
Copy link
Contributor

@swift-ci Please smoke test Linux

@JGiola
Copy link
Contributor Author

JGiola commented Oct 19, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants