Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I realize that this is not a full fix for the general problem involving -lto-whole-program-visibility, but I believe if you ignore -lto-whole-program-visibility (which Chrome doesn't use) then this fix makes sense.
This diverges from the documented behavior of -lto-whole-program-visibility. The flag is meant to give all classes hidden LTO visibility, but now it only does that to some of them.
perhaps I'm misunderstanding, but even with -lto-whole-program-visibility classes explicitly marked with public LTO visibility still shouldn't participate in WPD?
We documented the feature in D75655 and there it says "all classes" (and still does).
We documented the feature in D75655 and there it says "all classes" (and still does).
I've updated the documentation. It was already slightly inaccurate in that we weren't emitting type test/assumes for std/stdext namespace classes when -flto-visibility-public-std, this now corrects that part and generalizes that part of the documentation.
I prefer the way proposed here, which was what I initially intended to do in fact. @pcc, I recall from our early internal conversations about my proposal that you felt the new mechanism should apply to all classes, so that's why the final design did that. I do tend to think that if the source code has specifically annotated the classes with public LTO visibility it is better to enforce that always. I think revisiting this decision is worthwhile.
Okay, it seems reasonable enough to have the [[clang::lto_visibility_public]] attribute override the --lto-whole-program-visibility flag.
What I'm not sure about though is whether __declspec(uuid) and std/stdext in /MT//MTd should also override it.
Fortunately we don't need to solve that now because those are Windows-specific attributes/features and we don't support passing --lto-whole-program-visibility to Windows linkers.
So LGTM if you only mention [[clang::lto_visibility_public]] in your change to the documentation.