Interest in StringRef'ize APIs Open Project

Hi all!

I’m just now trying to start working on clang and was wondering if there still is interest in the open project: “StringRef’ize APIs: A thankless but incredibly useful project is StringRef’izing (converting to use llvm::StringRef instead of const char * or std::string) various clang interfaces. This generally simplifies the code and makes it more efficient.” I figured I’d update a few files at a time, ensure tests pass, and submit this as little patches over a long time until I got done.

Cheers,
Paul

Hi Paul,

Simpler, faster and leaner is always better. :slight_smile:

Your approach looks good, one small patch at a time, until you tire or
we run out of StringRef's to do.

cheers,
--renato

In article <CAHbe_AdpFmjYUfdcwwL08ftWKVTbhgUGaaxZHO_bcOM9gdG+ig@mail.gmail.com>,
    Paul Jarrett <jarrett.paul.young@gmail.com> writes:

I'm just now trying to start working on clang and was wondering if there
still is interest in the open project: "*StringRef'ize APIs*: A thankless
but incredibly useful project is StringRef'izing (converting to use
llvm::StringRef instead of const char * or std::string) various clang
interfaces. This generally simplifies the code and makes it more
efficient." I figured I'd update a few files at a time, ensure tests pass,
and submit this as little patches over a long time until I got done.

To me this sounds highly mechanical and repetitive (which is why noone
has taken on this thankless task).

"highly mechanical and repetitive" screams out refactoring tool to me,
but maybe that's just because I think refactoring tools are so cool.

Hi Richard,

This is not just a renaming refactoring. The trade off between
std::string, char *, StringRef, Twine and SmallString are not trivial,
and teaching any refactoring tool about those will take longer (and be
more mechanical) than the refactoring itself.

It is mechanical, yes, but it's not entirely tedious, and is a good
way to get acquainted with the rest of the code in a non-destructive
way. Discussions about life time of variables and how to optimise that
can be quite entertaining.

cheers,
--renato

Going from std::string to StringRef involves going from an explicit copy to something with nontrivial ownership semantics. The converse transform would be trivial (it’s always safe to use a std::string instead of a StringRef, you’re just going to end up with lots of redundant copies), but going in this direction requires reasoning about the surrounding code.

David

The idea is to go from std::string to StringRef/Twine, not the other
way around, so the problems are usually non-trivial.

cheers,
--renato

I think that’s what I said?

David

It is... sorry.

> Going from std::string to StringRef involves going from an explicit copy
to something with nontrivial ownership semantics. The converse transform
would be trivial (it’s always safe to use a std::string instead of a
StringRef, you’re just going to end up with lots of redundant copies), but
going in this direction requires reasoning about the surrounding code.

The idea is to go from std::string to StringRef/Twine, not the other
way around, so the problems are usually non-trivial.

A related problem is foo(...,T* Elems, int NElem,...) ->
foo(...,ArrayRef<T> Arr,...)

I think we've been pretty good about this lately, but that transformation
is highly mechanical and there are probably a fair number of cases
remaining.

-- Sean Silva