Chromium currently overrides this even though it isn't a customization point. Remove the option again once Chromium fixes the bugs this option circumvents.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Is there anything in the release notes that it's the intention to remove this?
We know it broke Chromium, but we don't know how many other might be broken.
Instead I would suggest to follow our normal removal route once Chromium is fixed:
- Remove it, but add an opt out
- Add information in the release notes, requesting people to reach out when they use it
- Remove the opt out in a later release
Is there anything in the release notes that it's the intention to remove this?
No, there isn't. Normally we don't release-note refactoring internal code.
We know it broke Chromium, but we don't know how many other might be broken.
I suspect there aren't a lot of people who do this. You have to link libc++ statically, define _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS, use -fvisibility=hidden and want a custom operator new/operator delete that is in a (different) dylib.
Instead I would suggest to follow our normal removal route once Chromium is fixed:
- Remove it, but add an opt out
- Add information in the release notes, requesting people to reach out when they use it
- Remove the opt out in a later release
Do you have a suggestion of how that opt-out should look like?
"... once Chromium fixes the bugs this option circumvents"
When this issue is ultimately resolved, I think it will require a libc++ customization point. I don't see a good way to use fvisibility=hidden, hide libc++ symbols, but override operator new & delete with default visibility symbols, without an ifdef here. Certainly, we can come up with a better customization point than this ifdef. I just mean that it's highly unlikely that this patch should land as is. Instead there will be other libc++ changes.