[LLVMdev] GSOC - Use more StringRef in clang.

[David Blaikie]

On Mon, Mar 17, 2014 at 6:16 AM, Kevin Cox <kevincox at kevincox.ca> wrote:
> Hello,
>
> I was looking to tackle the "StringRef'ize APIs" suggestion from the
> clang project page and just wanted to post a couple of thoughts and ask
> a couple of questions.

Hi - welcome to the project!

> First of all I am going to talk about how I see the goals of the
> project.  Basically, as far as I understand it I will be converting
> existing functions that take std::string or char*'s to use
> llvm::StringRef where applicable.  Then I will be changing a number of
> call sites to use this new function.
>
> One major question I have is should the old version be removed?

The intention is to change APIs directly rather than introducing a new
API alongside the old one. (so, yes, the old one should be removed/not
exist)

>  It
> would be very possible to convert the old version as a stub and it may
> make it easier for others when they have a string rather than a
> StringRef (although conversion is simple anyways).

This change should generally be API compatible (implicit conversions
to StringRef should fire in most/common cases) and fixing up a few
callers for which the extra user defined conversion is not accessible
shouldn't be too painful.

>   Also there may be
> API and ABI implications if a function from the public API is converted.
>  What do you think the best approach for this is?

The LLVM C++ API has no ABI guarantee/stability, we break it
continuously and intend to keep doing so - you're welcome to do the
same in this effort.

> Another question I have is how would you define focus.  A large part of
> the project is hunting through the source to find and change these
> functions so how would "progress" be defined.  GSOC requires a solid
> requirement for mid-term and final requirements.  Should I choose a
> number of functions that I expect to have converted in this time or is
> there a better criteria that you can think of.

I don't know much about GSOC to know whether this would be a good
project or not, nor how it might be evaluated.

I had a few deeper issues when I started on the project & was working
on StringRef upgrades - I started looking at Twine and trying to
figure out whether Twine could be used more pervasively, but never
came to any good conclusions about that. I eventually just decided to
do ArrayRef work which was more unambiguous.

You could search the codebase for particular idioms (I found ArrayRef
opportunities by searching for "\.data().*\.length()" I think - or
idioms like that (you could search for "const std::string&"
parameters, for example, if you wanted to do StringRef upgrades)) and
see if the number of instances is high enough for a reasonable sized
project, then use that metric to track your progress - run the same
search each day/week/whatever and demonstrate that you're approaching
zero.

- David

>
> cheers,
> Kevin
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>