lanza added a comment. > This change provides a codegen options flag to clang > -fobjc-export-direct-method-wrappers to generate the wrapper functions that > begin with the prefix objc_direct_wrapper and are marked as > attribute__((alwaysinline)). This way within a link unit the wrapper > functions should be inlined away at their call sites, but across a dylib > boundary the wrapper call is used.
I think this needing a flag is a bit magical for what seems like such a simple concept for the ObjC language. There shouldn't need to be a flag to make it work properly. We have defined more-or-less non-`virtual` methods for ObjC with `objc_direct`. The symbol visibility should behave as a reasonable developer should expect and the front end should communicate it. Requiring a flag is the compiler requiring the developer to understand compiler implementation details for his iOS app to work properly. Currently, clang decides the visibility is hidden but can't communicate this across library boundaries and you end up with confusing link errors for the developer. There's two routes that make sense in my opinion: library private and class private OR library public and class public. As per the ABI, I don't know of any reasons why `objc_direct` methods require the standard ObjC `-[class method]` signature since they won't be participating in any part of the ObjectiveC runtime. If that's the case, a proper underscored symbol name seems like the cleaning and most reasonable fix. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86049/new/ https://reviews.llvm.org/D86049 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
