I'm looking to get involved contributing to Clang. As a starting point,
I was hoping to find a relatively small and simple project that would
give me the opportunity to get familiar with the code.
I started down a similar track earlier this year.
Under these constraints, one possibility that popped out at me from the
documents online was the need to change some of the interfaces to use
llvm::StringRef instead of plain strings. Would this be a good place to
I also started here, though I perhaps made it a bit more of an issue
than it necessarily has to be. There are a few different ways of
handling strings in LLVM (primarily StringRef and Twine, though
there's also raw character pointers, etc) & I was trying to resolve
those to come up with an appropriate design/convention that could be
used universally (mostly to resolve the distinction between StringRef
and Twine and possibly standardize on using Twine for all parameters
that didn't need to be indexed back into the argument (eg. something
like 'split' that takes a StringRef and returns two StringRefs that
refer into the original would have to continue to take a StringRef,
not a Twine)). Those issues were never really resolved & my attempts
to do so are still, notionally, out for review on llvm-commits.
Maybe one day
Would anyone familiar with the code recommend something
Personally, I found an easier/less ambiguous place to work was with
ArrayRef-izing APIs. These are fairly easy to find but probably far
less numerous than string argument fixes (you could, potentially fix
all easily discovered ArrayRef-able cases in a few weeks I'd imagine
(not that I'm suggesting you should (& you should certainly send it
out for CR in smaller increments) just that it's a relatively small
set). I found cases for this by greping the source for
"\.data().*\.length()", though you could be a bit more precise in the
grep if you get a lot of false positives that way.
If you look back through my commits you should find a handful of
ArrayRef-ication checkins (r140268, r140288, r140290, r140293) to use
Other than what's in the documents up on the official site,
are there any other considerations I should be aware of as I try to get
up to speed?
I'd make sure you're on llvm-dev, llvm-commits, cfe-dev and
cfe-commits (the latter two if you have any interest in Clang). But
basically docs on the website (especially getting started, developer
guidelines, etc) are a good place to start, as well as the bug
database (llvm.org/bugs) and the email lists.