What is the state of the Clang project StringRef'ize APIs?

Hi everybody,

the LLVM and the Clang project is very interesting for me and I would
like to join it.

When I look at the page of open project I see the topic "StringRef'ize
APIs" which I think would give me a good starting point to get
familiar with the code base. I don't mind if this is a "thankless"
project.

One of my favorite task was and is Clean Code and code optimization in
general. And if this simplifies the code and makes it more efficient
then I would like to joining that project.

Is this still an open topic or is there already someone working on it?

Since this is a task of changing APIs on which the work of many others
contributors relies on, I think a special procedure might be necessary
to make the changes less painful as possible. One way could be, to do
the changes on a special branch, but I am not a friend of branching,
but I would prefer an iterative approach with small changes on the
trunk. What is the policy here?

As well, what projects would I have to look at, to keep them
computable? The LLVM core and Clang of course. What else? Are there
more tests than the included unit test that I should perform?

Thanks and regards,
Felix Petriconi

Hi everybody,

the LLVM and the Clang project is very interesting for me and I would
like to join it.

When I look at the page of open project I see the topic "StringRef'ize
APIs" which I think would give me a good starting point to get
familiar with the code base. I don't mind if this is a "thankless"
project.

One of my favorite task was and is Clean Code and code optimization in
general. And if this simplifies the code and makes it more efficient
then I would like to joining that project.

Is this still an open topic or is there already someone working on it?

People do bits & pieces from time to time (I did some when I started
contributing) but no one's currently making any broad plans to change
the world or anything.

(related to StringRef-izing is also ArrayRef-izing. In my opinion the
latter (ArrayRef) is more obvious. The former can be complicated by
the existence/use of Twine & its applicability in certain calls - but
maybe that was just me overcomplicating the problem)

Since this is a task of changing APIs on which the work of many others
contributors relies on, I think a special procedure might be necessary
to make the changes less painful as possible. One way could be, to do
the changes on a special branch, but I am not a friend of branching,
but I would prefer an iterative approach with small changes on the
trunk. What is the policy here?

The general policy of development is small iterative changes on trunk.
Very rarely is there justification/need to branch.

As well, what projects would I have to look at, to keep them
computable? The LLVM core and Clang of course. What else? Are there
more tests than the included unit test that I should perform?

For something like StringRef-izing a simple "make check-all" (actually
the check-all target is from the CMake build, not sure what the
autoconf+make targets are, it might be the same in this instance)
should suffice. But if you're curious there's also the test suite
(details of the various testing layers can be found here
http://llvm.org/docs/TestingGuide.html )

- David