plotfi added a comment. @lanza I did it as a CodeGen option for now because we don't want anything like this to be the default until the ABI is fleshed out. I think one danger in altering the name of the function to some extent is you dont want to clash potentially with user defined C functions.
In D86049#2226507 <https://reviews.llvm.org/D86049#2226507>, @lanza wrote: >> 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
