This is a follow-up to https://reviews.llvm.org/D103935
A Twine's internal layout should not depend on which version of the
C++ standard is in use. Dynamically linking binaries compiled with two
different layouts (eg, --std=c++14 vs --std=c++17) ends up
problematic.
This change avoids that issue by immediately converting a
string_view to a StringRef at the cost of an extra eight-bytes
in Twine, and certain copies and dereferences to StringRefs that
hadn't happened prior to this change.
I do believe the optimizer can elide almost all the extra nominal
work via inlining and the like.
I think from a standards-conformance perspective this may need to be decomposed into a raw struct of const char*+length - otherwise, since StringRef isn't trivially constructible (guess that's why you had to add the Child ctor?) it won't be validly constructed and deconstructed as required by C++ for non-trivial types like this.
At least that's my vague/general understanding. There could be some nuance that makes this valid.
(as a follow-up, it'd be good to collapse all the other cases that can be represented by StringRef into this case to reduce the complexity of this code, I think)