determine if decl comes from ObjC header


(Jon Rafkind) #1

How can I determine if a swift declaration comes from a header file, such as UITextInputTraits from iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/System/Library/Frameworks/UIKit.framework/Headers/UITextInputTraits.h?

I tried this

swift::ProtocolDecl * protocol;
if (protocol->getModuleContext() == context->getClangModuleLoader()->getImportedHeaderModule()){
...
}

but the two modules are not equal. protocol->getModuleContext()->isSystemLibrary() is true, but I'm not sure thats enough information to distinguish protocols defined in header files versus ones that come from core swift libraries.

The reason I am asking about this is that properties are treated differently in swift code versus objective-c code.

protocol Test{
  var number:Int { get }
}

This protocol will have 3 members, a PatternBindingDecl, a VarDecl, and a FuncDecl that is a getter. The pattern binding and getter seem to be autogenerated by the parser/typechecker.

For a protocol defined in a header file such as

@protocol UITextInputTraits <NSObject>
@property(nonatomic) UITextAutocorrectionType autocorrectionType;
@end

will only have one member, the VarDecl for autocorrectionType.

I would like to deal with the VarDecl only in the case that it is declared inside a header file.

···

--


(Joe Groff) #2

That seems like an inconsistency we should fix, instead of trying to work around.

-Joe

···

On Feb 19, 2016, at 2:25 PM, Rafkind, Jon via swift-dev <swift-dev@swift.org> wrote:

How can I determine if a swift declaration comes from a header file, such as UITextInputTraits from iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/System/Library/Frameworks/UIKit.framework/Headers/UITextInputTraits.h?

I tried this

swift::ProtocolDecl * protocol;
if (protocol->getModuleContext() == context->getClangModuleLoader()->getImportedHeaderModule()){
...
}

but the two modules are not equal. protocol->getModuleContext()->isSystemLibrary() is true, but I'm not sure thats enough information to distinguish protocols defined in header files versus ones that come from core swift libraries.

The reason I am asking about this is that properties are treated differently in swift code versus objective-c code.

protocol Test{
var number:Int { get }
}

This protocol will have 3 members, a PatternBindingDecl, a VarDecl, and a FuncDecl that is a getter. The pattern binding and getter seem to be autogenerated by the parser/typechecker.

For a protocol defined in a header file such as

@protocol UITextInputTraits <NSObject>
@property(nonatomic) UITextAutocorrectionType autocorrectionType;
@end

will only have one member, the VarDecl for autocorrectionType.

I would like to deal with the VarDecl only in the case that it is declared inside a header file.


(Jon Rafkind) #3

How can I determine if a swift declaration comes from a header file, such as UITextInputTraits from iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/System/Library/Frameworks/UIKit.framework/Headers/UITextInputTraits.h?

I tried this

swift::ProtocolDecl * protocol;
if (protocol->getModuleContext() == context->getClangModuleLoader()->getImportedHeaderModule()){
...
}

but the two modules are not equal. protocol->getModuleContext()->isSystemLibrary() is true, but I'm not sure thats enough information to distinguish protocols defined in header files versus ones that come from core swift libraries.

The reason I am asking about this is that properties are treated differently in swift code versus objective-c code.

protocol Test{
var number:Int { get }
}

This protocol will have 3 members, a PatternBindingDecl, a VarDecl, and a FuncDecl that is a getter. The pattern binding and getter seem to be autogenerated by the parser/typechecker.

For a protocol defined in a header file such as

@protocol UITextInputTraits <NSObject>
@property(nonatomic) UITextAutocorrectionType autocorrectionType;
@end

will only have one member, the VarDecl for autocorrectionType.

I would like to deal with the VarDecl only in the case that it is declared inside a header file.

That seems like an inconsistency we should fix, instead of trying to work around.

-Joe

I agree :slight_smile:

···

On 02/19/2016 02:47 PM, Joe Groff wrote:

On Feb 19, 2016, at 2:25 PM, Rafkind, Jon via swift-dev <swift-dev@swift.org><mailto:swift-dev@swift.org> wrote:

--