Getting started on getting started

Hey all,

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.

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
start? Would anyone familiar with the code recommend something
different? 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?

Thanks in advance for any guidance.

Regards,

- --Benjamin Schulz

Not to step on Benjamin's toes, but I'm also looking to contribute to Clang, so I'd definitely appreciate a few project ideas that would be good starts for newbies. I've been walking through the code/documentation for the past few days, roughly trying to follow process order, but since that's probably not necessarily the best way to do things, I'd wouldn't mind a shove in the right direction.

Matthew Abbott

Hello,

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
start?

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 :slight_smile:

Would anyone familiar with the code recommend something
different?

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
as examples.

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.

Thanks,
- David

Not to step on Benjamin's toes, but I'm also looking to contribute to Clang, so I'd definitely appreciate a few project ideas that would be good starts for newbies. I've been walking through the code/documentation for the past few days, roughly trying to follow process order, but since that's probably not necessarily the best way to do things, I'd wouldn't mind a shove in the right direction.

I generally suggest that you take a look at quality-of-implementation bugs in Bugzilla (http://llvm.org/bugs/), because you can often learn a lot and make a difference just by improving diagnostics or error recovery (e.g., for common mistakes).

  - Doug