similar to: Is it time to allow StringRef to be constructed from nullptr?

> On Sep 25, 2016, at 1:49 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Sep 25, 2016, at 9:10 AM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> While porting LLDB over to StringRef, I am continuously running into difficulties caused by the fact that

The pointer could only be null if the length is zero. If the length is zero, you shouldn't be loading it. Defaulting to null instead of "" is also a microoptimization. -Chris > On Sep 25, 2016, at 10:49 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > >> On Sep 25, 2016, at 9:10 AM, Zachary Turner via llvm-dev <llvm-dev at

Hi all, There is a desire to be able to create constexpr StringRefs to avoid static initializers for global tables of/containing StringRefs. Creating constexpr StringRefs isn't trivial as strlen isn't portably constexpr and std::char_traits<char>::length is only constexpr in C++17. Alp Toker tried to create constexpr StringRefs for strings literals by subclassing StringRef:

On 28 November 2016 at 20:51, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > The basic idea here is that you introduce a StringLiteral class and anywhere > you want to use a global constructor, you make sure to declare a constexpr > array instead of a normal array, and you make it of type StringLiteral. I prefer constexpr llvm_strlen() over StringLiteral because

On 29 November 2016 at 16:18, Zachary Turner <zturner at google.com> wrote: > I don't like the llvm_strlen approach as it is incompatible with > std::string_view which we may eventually move to. In what way is it incompatible? constexpr StringRef(const char* s) : Data(s), Length(llvm_strlen(s)) {} is equivalent to constexpr string_view(const char* s) : Data(s),

On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper <peter_cooper at apple.com> wrote: > Hi all > > (No idea if I have the correct audience. Please CC more people as needed). > > I have an UBSan failure in BumpPtrAllocatorImpl.Allocate. > > The problem is that lld requests that we StringRef::copy an empty string. > This passes a length of 0 to a BumpPtrAllocator. The

Hi all (No idea if I have the correct audience. Please CC more people as needed). I have an UBSan failure in BumpPtrAllocatorImpl.Allocate. The problem is that lld requests that we StringRef::copy an empty string. This passes a length of 0 to a BumpPtrAllocator. The BumpPtrAllocator happened to not have anything allocated yet so the CurPtr is nullptr, but given that we need 0 space we think

Yes, that proposal makes sense to me: the split would be between things that *are* known to be subsumed into later versions of C++, and therefore are a compatibility library. What do you think about this as an implementation approach: - Rewrite StringRef (et al) to use the exact same APIs as std::string_view. Keep the StringRef name for now. - When cmake detects that C++’17 mode is supported,

> On Mar 22, 2016, at 5:35 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote: > Hi all > > (No idea if I have the correct audience. Please CC more people as needed). > > I have an UBSan failure in

On Wed, Jul 5, 2017 at 8:14 PM Zachary Turner <zturner at google.com> wrote: > Is there actually a valid use case for using the entire Support library > though? > > One thing that splitting solves is that I can have StringRef and ArrayRef > split up and committed by tomorrow. The same can't be said for the entire > Support library :) > Huh? I'm asking what is

Sure, I guess that splitting the arrayref/stringref headers out is a fine first step. -Chris > On Jul 5, 2017, at 5:07 PM, Zachary Turner <zturner at google.com> wrote: > > Re-writing StringRef / ArrayRef etc to use the exact same API is a good idea long term, but there's a lot of ugly messy details that need to be dealt with. There's thousands of uses of take_front /

On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi all > > (No idea if I have the correct audience. Please CC more people as needed). > > I have an UBSan failure in BumpPtrAllocatorImpl.Allocate. > > The problem is that lld requests that we StringRef::copy an empty string. > This passes a length of 0 to a

To context was , Basic requirement was to append extra string to the decl name and update all his references to the updated name. , So we are constructing the DeclarationName instance as stated below code snap. and from DeclarationName instance ,we are constructing the DeclarationNameInfo and same info used to create decl spec with FunctionDecl::Create () . Question is , How do ,someone

> On Mar 22, 2016, at 5:39 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Mar 22, 2016, at 5:35 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> >> >> On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at

On 12/21/2016 5:01 AM, Umesh Kalappa via llvm-dev wrote: > To context was , > > Basic requirement was to append extra string to the decl name and > update all his references to the updated name. , > > So we are constructing the DeclarationName instance as stated below > code snap. > and from DeclarationName instance ,we are constructing the > DeclarationNameInfo

Having watched a similar library go through this exact evolution, I really doubt we want to make any split around "things known to be in C++ in the future"... It turns out that this is nearly impossible to predict and precludes a tremendous amount of useful utilities. For example, there is no indication that the range helpers LLVM provides will ever end up in C++'s standard library,

FWIW, I agree with Mehdi that we should just assert that our types don't get called with size zero. That said, I don't think we can be terribly cavalier with what we expect from standard allocator types, operator new, or malloc. And so I would expect LLVM_ATTRIBUTE_RETURNS_NOALIAS to not imply NONNULL, and while it seems reasonable to put NONNULL on *our* allocate function because of the

On Wed, Jul 5, 2017 at 7:14 PM Sean Silva <chisophugis at gmail.com> wrote: > On Wed, Jul 5, 2017 at 6:46 PM, Chandler Carruth via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Having watched a similar library go through this exact evolution, I >> really doubt we want to make any split around "things known to be in C++ in >> the future"...

> On Mar 28, 2016, at 3:12 PM, Chandler Carruth <chandlerc at google.com> wrote: > > FWIW, I agree with Mehdi that we should just assert that our types don't get called with size zero. Yeah, I agree. I’ve tried running the tests with the assert in place and there’s about 1000 failures across llvm/clang. I’ll see what I can fix as I would like to get these to behave. There

The fact that the templatized constructor falls down because of the possibility of initializing StringRef with a stack-allocated char array kills that idea in my mind. I feel like the only two reasonable solutions are 1) allow UDL for this case, document that this is an exception and that UDLs are still not permitted anywhere else, and require (by policy, since I don't know of a way to have