This is an archive of the discontinued LLVM Phabricator instance.

[libcxx] Reorganize _LIBCPP_LOCALE__L_EXTENSIONS
ClosedPublic

Authored by bcraig on Feb 19 2016, 10:14 AM.

Details

Summary

This is one part of many of a locale refactor. See http://reviews.llvm.org/D17146 for an idea of where this is going.

Instead of checking _LIBCPP_LOCALE_L_EXTENSIONS all over, instead check it once, and define the various *_l symbols once. The private redirector symbol names are all prefixed with _libcpp_* so that they won't conflict with user symbols, and so they won't conflict with future C library symbols. In particular, glibc likes providing private symbols such as __locale_t, so we should follow a different naming pattern (like _libcpp_*) to avoid problems on that front.

Tested on Linux with glibc. Hoping for the best on OSX and the various BSDs.

Diff Detail

Event Timeline

bcraig updated this revision to Diff 48509.Feb 19 2016, 10:14 AM
bcraig retitled this revision from to [libcxx] Reorganize _LIBCPP_LOCALE__L_EXTENSIONS.
bcraig updated this object.
bcraig added a subscriber: cfe-commits.
bcraig updated this object.Feb 19 2016, 10:14 AM
jroelofs edited edge metadata.Feb 19 2016, 10:17 AM
jroelofs added a subscriber: EricWF.

The private redirector symbol names are all prefixed with _CXX_* so that they won't conflict with user symbols,

This is more @mclow.lists/@EricWF's domain, but I think __libcxx_ prefixes would be safer (so that there's no chance of clashing with libstdc++, if they decide to do something similar, or already have).

The private redirector symbol names are all prefixed with _CXX_* so that they won't conflict with user symbols,

This is more @mclow.lists/@EricWF's domain, but I think __libcxx_ prefixes would be safer (so that there's no chance of clashing with libstdc++, if they decide to do something similar, or already have).

Do we need our headers to coexist with the headers from other C++ implementations? That seems fraught with peril. I've tried to do something like that in the past with STLPort in combination with various compilers' STLs, and ADL basically made the results unusable.

The private redirector symbol names are all prefixed with _CXX_* so that they won't conflict with user symbols,

This is more @mclow.lists/@EricWF's domain, but I think __libcxx_ prefixes would be safer (so that there's no chance of clashing with libstdc++, if they decide to do something similar, or already have).

Do we need our headers to coexist with the headers from other C++ implementations? That seems fraught with peril. I've tried to do something like that in the past with STLPort in combination with various compilers' STLs, and ADL basically made the results unusable.

I think the headers are a lost cause. It's the symbols I'm actually worried about. There are people who link against both standard libraries (and that's a valid, supported use case).

scshunt edited edge metadata.Feb 19 2016, 10:47 AM

Oh man, what did I do to get included on this one? ;)

I haven't worked on LLVM for years, though, so please proceed without me. :)

Sean

bcraig updated this revision to Diff 48520.Feb 19 2016, 10:59 AM
bcraig updated this object.
bcraig removed a reviewer: scshunt.

Switched from _CXX_* prefix to _libcxx_* prefix to avoid link time conflicts with other C++ library implementations.

Removed Sean Hunt from the reviewers list.

mclow.lists edited edge metadata.Feb 22 2016, 7:53 AM

Actually, the prefix we use in the rest of libc++ for private functions is __libcpp_ Take a look in type_traits for a bunch of examples.

In general, I'm liking the way this is going. I suspect I will have more comments later today.

bcraig updated this revision to Diff 48687.Feb 22 2016, 8:17 AM
bcraig updated this object.
bcraig added a reviewer: joerg.

Changed libcxx prefix to libcpp.
Changed BSD forwarding macros to macro functions.

bcraig accepted this revision.Mar 9 2016, 7:45 AM
bcraig added a reviewer: bcraig.

Committed

This revision is now accepted and ready to land.Mar 9 2016, 7:45 AM
bcraig closed this revision.Mar 9 2016, 7:45 AM