[PATCH] StringRef-izing some of clang-check

Christopher Jones chrisjones.lambda at gmail.com
Sun Apr 21 22:36:14 PDT 2013


Thanks for the comments.  I think I understand more the utility of the
project and why my first attempt is no good.  How about this patch?

I'll try to keep an eye out for Arrayrefizations.  Could you point me to an
example where this was recently done as you said?  (I'm still new to git
and just did my first rebase.)

Thanks for helping the noob,
Chris


On Sun, Apr 21, 2013 at 11:35 PM, David Blaikie <dblaikie at gmail.com> wrote:

> On Sun, Apr 21, 2013 at 8:16 PM, Christopher Jones
> <chrisjones.lambda at gmail.com> wrote:
> > Hi all,
> >
> > This patch is pretty small and probably doesn't have much impact, but
> it's
> > my first one and I mainly want to make sure I have the workflow down.
>  I'd
> > appreciate any criticism.
> >
> > This is a first attempt at the StringRef-ization open project.  If anyone
> > has any recommendations on which parts of the interface would be most
> useful
> > to start on, I'd appreciate it.
>
> There's probably more value in changing parameter types rather than
> return types.
>
> (& I'd say there's probably more immediate value in ArrayRef-ization
> than StringRef-ization, maybe - especially in call sites that are
> passing magic constant "array size" parameters (some of these were
> just recently fixed in LLVM, for example), but for StringRefization,
> the value is in updating API/usage that may currently accept a "const
> std::string&" but never actually needs a string object (because both
> the caller passes in non-std::strings (string literals, for example)
> and the implementation doesn't use complex std::string operations))
>
> > Otherwise, I'll do something of a random
> > walk through the code.
>
> Some of the code you've updated will leade to dangling StringRefs -
> several of the RewriteFilename functions return local variables - they
> will go out of scope at the end of the function & the caller will be
> left with a dangling StringRef. That's no good.
>
> >
> > Thanks,
> > Chris
> >
> > _______________________________________________
> > cfe-commits mailing list
> > cfe-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130422/b49b1573/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-First-attempt-at-a-patch-along-with-some-StringRefiz.patch
Type: application/octet-stream
Size: 4273 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130422/b49b1573/attachment.obj>


More information about the cfe-commits mailing list