similar to: [LLVMdev] GSOC - Use more StringRef in clang.

> And for arguments, generally always use Twine as the default, it allows construction of complex things, and is still efficient when passed the equiv of a StringRef (with the toStringRef method).  The only annoying thing about it is that the API to do this requires a temporary SmallVector to scribble in, which makes it more difficult to use. > > It seems that there should be a good way

On 24 November 2016 at 15:04, Hal Finkel <hfinkel at anl.gov> wrote: >> Creating constexpr StringRefs isn't trivial as strlen isn't portably >> constexpr and std::char_traits<char>::length is only constexpr in >> C++17. > > Why don't we just create our own traits class that has a constexpr length, and then we can switch over to the standard one when

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:

> The dangerous part of this is that characters are integers, so "foo" + 'x' is very likely to cause serious problems. std::string already provides such overloads though, doesn't it? So the code isn't any safer from accidental "foo" + 'x' expressions that don't include Twine/StringRef/std::string than it was before. But if the argument is that

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

On Jul 21, 2011, at 12:00 AM, David Blaikie wrote: >> And for arguments, generally always use Twine as the default, it allows construction of complex things, and is still efficient when passed the equiv of a StringRef (with the toStringRef method). The only annoying thing about it is that the API to do this requires a temporary SmallVector to scribble in, which makes it more difficult to

On Mon, Nov 28, 2016 at 11:01 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > On Nov 28, 2016, at 9:47 AM, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > OK - good to know. (not sure we're talking about pessimizing it - just not > adding a new/possible optimization, to be clear) > > > This does not seem that clear to me. The

On Jul 21, 2011, at 12:30 AM, David Blaikie wrote: >> [diff attached] > > Updated diff with test fix. (since this broke a test (printing chars > as numerical values, rather than characters) it's possible this change > is a bad idea & it could break the product code itself. Though > strangely I wasn't able to do character concatenation without my > change, so I

On Fri, Nov 25, 2016 at 6:10 AM Mueller-Roemer, Johannes Sebastian via llvm-dev <llvm-dev at lists.llvm.org> wrote: > What about going for > > template<unsigned N> > constexpr StringRef(const char (&Str)[N]) > > and avoiding strlen entirely for string literals? > You'd at least want an assert in there (that N - 1 == strlen(Str)) in case a StringRef is

OK - good to know. (not sure we're talking about pessimizing it - just not adding a new/possible optimization, to be clear) Just out of curiosity - are there particular reasons you prefer or need to ship an MSVC built version, rather than a bootstrapped Clang? On Mon, Nov 28, 2016 at 9:24 AM Robinson, Paul <paul.robinson at sony.com> wrote: > So I wouldn't personally worry too

On Jul 18, 2011, at 12:38 PM, David Blaikie wrote: > I'm attempting to do some amount of mass migration from const std::string& (& const char*) to StringRef. Great! > In doing so I stumbled across the fact that while StringRef has no op+ to speak of (well, it has += and I added a manual StringRef+std::string and std::string+StringRef for now - though I'm thinking perhaps

I'm attempting to do some amount of mass migration from const std::string& (& const char*) to StringRef. In doing so I stumbled across the fact that while StringRef has no op+ to speak of (well, it has += and I added a manual StringRef+std::string and std::string+StringRef for now - though I'm thinking perhaps they can be skipped in favor of Twine operations), Twine does provide a

On 28 November 2016 at 19:30, Mehdi Amini <mehdi.amini at apple.com> wrote: > This thread started with: "There is a desire to be able to create constexpr > StringRefs to avoid static initializers for global tables of/containing > StringRefs.” > > I don’t have more information, but maybe Malcolm can elaborate? I was restating your motivation from

On Jul 24, 2011, at 12:09 AM, David Blaikie wrote: >> Yes, exactly. I'm just saying that I think the additional clarity of: >> "foo" + Twine('x') >> >> is worth the inconvenience. > > Ok, attached a modified version of my patch with an Twine(char), > Twine(unsigned char), and Twine(signed char). All three are explicit & > have

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

> Right, but that requires VS #ifdefs.  You can also use enum bitfields, but VS has different promotion rules from them than other compilers. Ah, I'd thought that feature (specifying the backing type with "enum name : integral_type") was standard, but I see it's a C++0x thing. My mistake. >> 1) the easy solution: create a StringRef subclass (or new type with a >>

llvm::sys::fs::make_absolute converts its first parameter (const Twine &current_directory) to StringRef p(path.data(), path.size()), and then passes that StringRef to several functions (path::has_root_directory, path::has_root_name, and path::append) that accept Twines as parameters. Since llvm::StringRef can implicitly convert to an llvm::Twine, p converts to a bunch of Twine temporaries. In

I am wriitng an LLVM pass to insert instrumentation at certain points of the program. I want to pass the `StringRef` obtained from `getName()` as a parameter to a function `func(char* s)`. I can allocate some space on stack using `AllocaInst` to generate an `alloca` instruction. But, how can I copy the `StringRef` to the stack space? -- Thanks & Regards, Dipanjan -------------- next part

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