[PATCH] D53879: Make libc++'s versioning namespace customizable

[Eric Fiselier via Phabricator]

EricWF added a comment.

In https://reviews.llvm.org/D53879#1281139, @EricWF wrote:

> In https://reviews.llvm.org/D53879#1280924, @kristina wrote:
>
> > LG, one suggestion, would it be possible to request the `std::` namespace (disable inline namespaces altogether) by supplying a blank string?
> >
> > Being able to avoid versioning is useful on embedded systems or any other systems that have a more controlled environment where only one libc++ is pretty much guaranteed? (this allows for compact mangling of certain types like std::string, which in turn saves a very significant amount of space as the full mangled name for it otherwise is fairly long and it appears in symbol tables and debug data for many kinds of template instantiations). Same applies to streams and some other types that have shorthand reserved mangled forms, at least with IA64 ABI.
> >
> > If I understand correctly currently a blank string is simply ignored and `__N` form is used.
>
>
> Yeah, that seems reasonable to me. I'll make the change.


Actually, I'll make the change as a follow up patch.



================
Comment at: CMakeLists.txt:685
+if (NOT LIBCXX_ABI_NAMESPACE STREQUAL "")
+  if (NOT LIBCXX_ABI_NAMESPACE MATCHES "__.*")
+    message(FATAL_ERROR "LIBCXX_ABI_NAMESPACE must be a reserved identifier.")
----------------
smeenai wrote:
> ldionne wrote:
> > EricWF wrote:
> > > ldionne wrote:
> > > > `__.+`? Or do we want to allow `__`?
> > > In addition do we want `_Foo`. My thinking is we should probably allow users to foot-gun themselves as much as they want. 
> > > 
> > > We should probably document that we make no promises that we don't introduce names which conflict with their custom namespace name.
> > Actually, that's interesting. Another possibility would be to only allow users to use names that we can promise we won't reuse. For example we could say `__x.+` is reserved for users, or something like that.
> > 
> > What we should really avoid is for someone to start using something like `__3`, which would conflict with something we want to use in the future. Even though it would be their problem in theory, in practice it might put pressure on us not to reuse the name (if it were an important vendor or something). Constraining what names they can use would clear this possibility out completely.
> I would strongly prefer the allowed names to not be that restricted, since existing custom inline namespaces might not confirm to it (our doesn't). Allowing `__` followed by anything would work for us.
I've added a warning in the documentation that it's the responsibility of the user to choose a name that won't cause conflict, and that we make no promises. I think that's sufficient. 

I've also weakened the error to a warning. 




https://reviews.llvm.org/D53879