RFC: [llvm] specialize cl::opt_storage for std::string

[andrurogerz]

Purpose

Specialize llvm::cl::opt_storage for data type std::string so that it no longer inherits from std::string. With this patch in place, explicitly instantiated cl::opt<std::string> can be safely exported from an LLVM Windows DLL.

Overview

• Add fully-specified implementation of cl::opt_storage for data type std::string. It does NOT inherit from std::string as it did previously when data type std::string matched the partially specified template cl::opt_storage<DataType, false, true>
• Implement implicit conversions to std::string, llvm::StringRef, and llvm::Twine so that instances can be used in many places where std::string is used.
• Implement a number of std::string methods so that instances of the class are mostly interoperable with std::string.
• Add a new explicit constructor to Triple so it properly constructs from cl::opt_storage<std::string>. This change avoids having to modify clients that construct Triples from cl::opt<std::string> instances.

Background

This patch is in support of annotating LLVM's public symbols for Windows DLL export., tracked in #109483. Additional context is provided in this discourse.

This change is needed because, without it, we cannot export opt<std::string> from an LLVM Windows DLL. This is because MSVC exports all ancestor classes when exporting an instantiated template class. Since one of opt's ancestor classes is its type argument (via opt_storage), it is an ancestor of std::string. Therefore, if we export opt<std::string> from the LLVM DLL, MSVC forces std::basic_string to also be exported. This leads to duplicate symbol errors and generally seems like a bad idea. Compiling with clang-cl does not exhibit this behavior.

Validation

• Built llvm-project on Windows with MSVC cl and clang-cl.
• Built llvm-project on Fedora with clang and gcc.

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.