[cfe-dev] Contributing to clang

[David Blaikie]

The way I started in clang was to look for easy diagnostic bugs (false
positives, false negatives, perhaps miswordings, etc) - I could just
do a side-by-side debugging session with a true positive and a false
negative and see where the two steps diverged - where did we make the
wrong choice/do something different, and go from there.

Chances are patches like that will go through some iteration as you
won't necessarily know the /right/ place to make the fix, just /a/
place that seems to fix the bug, but it's something to start.

Cleanup patches are also a pretty good place to start - I've been
doing lots of std::unique_ptr migration (from raw owning pointers to
std::unique_ptr/llvm::make_unique, etc) when I get bored & am happy to
review similar changes. Some of the memory ownership semantics are
weird/difficult - feel free to steer clear of those and try to find
some low hanging fruit. In many cases I've found APIs that just go
into the raw pointer domain to bridge a function call (caller uses
unique_ptr and calls release() to pass to the callee, that immediately
rebinds to a unique_ptr) - changing the parameter type to unique_ptr
so it's explicit in the API is great low-friction improvement.

- David

On Sat, Aug 16, 2014 at 11:38 AM, Anthony Canino
<anthony.canino1 at gmail.com> wrote:
> Hi all,
>
> I've been looking to get involved with clang for a while now. I've started
> looking at the open projects page and was looking for some advice.
>
> Clang is something I am really interested in but realize there is a lot of
> getting up to speed, can anyone recommend an area where help is needed that
> might help me get my feet wet. I would really like to get involved, even if
> it takes me a long time to produce anything valuable.
>
> Thanks,
> --
> Anthony
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>