[IRGen] Do not write out ObjC property ivar field for static properties

[fay59]

This PR ensures that Swift does not fill the ivar attribute of Objective-C property metadata for class properties, since class properties are never backed by an ivar.

Resolves SR-9541.

I expect that my computer will be building Swift for a good amount of time, so I'll change the tests and run them when I'm back from work, or some time later depending on my availability. Just leaving this out there since it's a super simple change and I assigned the bug to myself.

rdar://problem/46830117

[jrose-apple]

Thanks, Félix!

[slavapestov]

@zneak Generally a change like this needs a test case. A good place to add one might be test/IRGen/objc_properties.swift. You can find a brief introduction to FileCheck in docs/Testing.md -- let us know if you need help. That document also tells you how to run the entire test suite or individual tests.

[fay59]

@slavapestov, thanks for the help! objc_properties (and its _ios sibling) is the file that I identified this morning before work. My Swift build was still in progress and I didn't want to commit tests before getting a chance to run them. I'm flying tomorrow and I have to pack, but hopefully I'll have something shortly.

[fay59]

Test has been updated, I think that this is ready for review.

[jrose-apple]

I spotted another bug in this implementation, which is that I'm not sure it's correct to print the ivar name if the storage doesn't match the property (for example, NSString vs. Swift.String). But that's a separate issue.

@swift-ci Please test

[fay59]

You’re right, this is also an issue. Is there a bug for it?

[jrose-apple]

I don't think I've seen one.

[jrose-apple]

Unrelated LLDB failures. Let's try again.

@swift-ci Please test

[jrose-apple]

Thanks, Félix! I'll cherry-pick this to the 5.0 branch for you too.

[fay59]

Great! For your trouble, I'll file a bug for this other related issue.

[fay59]

I filed it as SR-9557. I'm not sure that I'll pick it up, though.