erichkeane 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.
That DOES sound error prone. I wonder if there is use to have this diagnose via a warning that explains this, particularly now that we are allowing this to be more easily added to members. 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
