[usr-generation][print-as-objc] Namespace @objc (clang-style) USRs with the swift module name #8117
Conversation
…th the swift module name This is to avoid USR collisions between symbols from different Swift frameworks with the same name. Also update PrintAsObjC to add the new clang external_source_symbol attribute with the module name on the printed decls so the objective C USR generation can do the same.
|
@swift-ci please smoke test |
| OS << "@E@" << ObjCName; // FIXME: expose clang API to handle enum names | ||
| // FIXME: expose clang API to handle enum names | ||
| OS << "@M@" << ModuleName; | ||
| OS << "@E@" << ObjCName; | ||
| } else if (isa<EnumElementDecl>(D)) { | ||
| OS << "@" << ObjCName; |
There was a problem hiding this comment.
Don't these need to be namespaced with the module name too? And methods, and properties?
There was a problem hiding this comment.
They all get namespaced with their type context's USR fragment, so they'll pick up their context's module namespacing (test/IDE/print_usrs.swift has examples). Are there any cases where that won't be enough?
There was a problem hiding this comment.
Ah, I didn't realize that circled back through this code; I thought the "@M" would just be omitted.
It may not be sufficient for extension methods, though, which can be added in a different module than the type being extended.
lib/PrintAsObjC/PrintAsObjC.cpp
Outdated
| @@ -204,7 +205,9 @@ class ObjCPrinter : private DeclVisitor<ObjCPrinter>, | |||
| maybePrintObjCGenericParameters(baseClass); | |||
| os << " (SWIFT_EXTENSION(" << origDC->getParentModule()->getName() | |||
| << "))\n"; | |||
| insideCategory = true; | |||
There was a problem hiding this comment.
Nitpick: mind using llvm::SaveAndRestore here? It may seem like overkill for straight-line code, but it's more future-proof.
There was a problem hiding this comment.
Wasn't aware of it, actually – thanks!
|
@swift-ci please smoke test |
|
@swift-ci please smoke test |
|
This is overridden by #8972 |
This patch prefixes the clang-style USRs of
@objcsymbols with the swift module name to avoid USR collisions between symbols from different Swift frameworks with the same name. It also updates PrintAsObjC to add the new clangexternal_source_symbolattribute (with the swift module name) on the generated ObjC decls so that clang's USR generation can add the prefix too.At the moment this is done by:
SWIFT_CLASS,SWIFT_PROTOCOL, andSWIFT_ENUMmacros already on top-level declsSWIFT_MODULE(_module)macro that expands to the attribute on top-level function declsSWIFT_GENERATEDobject-like macro to the members of categories, which don't support attributes themselves. The module name isn't needed in this case as the USRs of these members are based on the original interface, which should have the attribute.The plan is to move to using the new pragma under review at https://reviews.llvm.org/D30009 when it lands, so there isn't as much noise in the header (especially for categories), but this lets us progress for now.
Resolves rdar://problem/30645863.