compnerd wrote: > > > This is missing test coverage for the interesting cases. > > > I'm a bit worried about how easy it will be to apply this attribute in > > > unexpected places. e.g., it will apply to member functions as well as > > > free functions, will anyone expect that though? > > > > > > This is explicitly documented, so I'd say yes. This is how the pragma works > > for better or worse. > > I think you're right, but is that actually helpful in this case? (I'm not > super experienced with the visibility attributes, coming from a Windows > background -- does it make sense to have "hidden" member functions on a > class? If so, then I think the attribute makes sense to support. If not, > maybe we want to consider different diagnostics to help users figure out when > they've made a potential mistake?) > > CC @compnerd who maybe can help me with my education. :-D
It is possible to apply the hidden visibility to member functions on classes. However, it does tend to complicate your ability to reason about the code IMO (although the same argument holds for `__declspec(dllexport)` on member functions. The attribute simply would prevent the member function from participating in dynamic linking - so any other module would need to define their own copy. https://github.com/llvm/llvm-project/pull/145653 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
