New to clang

Clang Frontend
1

Hi,

Sorry for another “newbie” message. I’d read about clang, and am quite excited about what it could offer (I’m a game developer, so better C++ tools and compilers could help quite a bit).

My own experience with language development/implementation has been limited to relatively simple languages (shading languages and the like). However, I’d like to help out any way I can, even if it’s simple tasks/fixes. Being new to OSS development, I’m not sure what the process is. Do I send my candidate change, as a patch, to the commits mailing list?

Thanks,

– Anis Ahmad

2

Sorry for another "newbie" message. I'd read about clang, and am quite excited about what it could offer (I'm a game developer, so better C++ tools and compilers could help quite a bit).

Welcome!

My own experience with language development/implementation has been limited to relatively simple languages (shading languages and the like). However, I'd like to help out any way I can, even if it's simple tasks/fixes. Being new to OSS development, I'm not sure what the process is. Do I send my candidate change, as a patch, to the commits mailing list?

You can send your patch to either this list or to the cfe-commits mailing list, and someone will review it. Every small feature or bug fix helps!

  - Doug

3

Hi,

Sorry for another "newbie" message. I'd read about clang, and am quite
excited about what it could offer (I'm a game developer, so better C++
tools
and compilers could help quite a bit).

No need to say sorry. We love getting new people here.

My own experience with language development/implementation has been

limited

to relatively simple languages (shading languages and the like).

However,

I'd like to help out any way I can, even if it's simple tasks/fixes.

Being

new to OSS development, I'm not sure what the process is. Do I send my
candidate change, as a patch, to the commits mailing list?

Yes, that's how it works. But if you haven't started on your patch yet, you
might want to tell this list what you're going to do first. We've had
conflicts before, where two people implemented the same thing.

Sebastian

4

Hi Sebastian,

5

There's the open projects page:

http://clang.llvm.org/OpenProjects.html

It's not very well updated though, for example -ftrapv was implemented a while ago but is still there. Using declarations is top of the C++ list, but I've seen a lot of patches related to that hitting the list recently, so it's not a good idea for someone to start working on independently. It also tells you to use the old ccc driver instead of clang for testing...

David

6

(note change of subject)

I would be interested in any work on using declarations, as I have been
scoping that out for my next project after the Unicode work.

Again, I was looking for a simple idea (C++0x type alias - should be able to
hook directly into typedef code) and discovered a much deeper hole. So my
concern is that any work here looks ahead to all the possible directions
that C++0x will go.

In short, if we see the keyword 'using' we may be about to parse:

i/ a using directive for namespaces
ii/ a C++98 using declaration
iii/ a C++0x inheriting constructor declaration -> declares *a set* of
constructors
iv/ a C++0x alias declaration => this declares a C++98 typedef name
v/ a C++0x template alias, if using preceded by a template declaration
vi/ a number of concept-related variants that I don't quite grok yet.

The current code is only annotated with the grammar for (i) and (ii)

Personally, I would rather see a broad set of test-cases before starting an
implementation, as there are some nasty cases to catch such as different
rules for duplicate identifiers at namespace or class scope etc.

[Note I have only been looking at problems and scratching my head on where
to start, no real thoughts on implementation yet!]

AlisdairM

7

There's the open projects page:

http://clang.llvm.org/OpenProjects.html

It's not very well updated though, for example -ftrapv was implemented
a while ago but is still there. Using declarations is top of the C++
list, but I've seen a lot of patches related to that hitting the list
recently, so it's not a good idea for someone to start working on
independently.

I've pruned everything that has already been implemented or that I know someone is already working on.

It also tells you to use the old ccc driver instead of
clang for testing...

Oops. Fixed.

- Doug

8

I would be interested in any work on using declarations, as I have been
scoping that out for my next project after the Unicode work.

Again, I was looking for a simple idea (C++0x type alias - should be able to
hook directly into typedef code) and discovered a much deeper hole. So my
concern is that any work here looks ahead to all the possible directions
that C++0x will go.

"using" got a lot more complicated in C++0x. Heck, it has more new meanings than "auto"!

Still, I don't think it's all that hard to deal with these variants.

In short, if we see the keyword 'using' we may be about to parse:

i/ a using directive for namespaces

We have the "namespace" keyword, so this is easy to cope with.

ii/ a C++98 using declaration

Since we turn nested-name-specifiers into a single token, this is pretty easy to cope with. Although semantic analysis will have to distinguish it from...

iii/ a C++0x inheriting constructor declaration -> declares *a set* of
constructors

... this one.

iv/ a C++0x alias declaration => this declares a C++98 typedef name

This is easy to distinguish with two-token lookahead, although it'd be better if we didn't need it.

v/ a C++0x template alias, if using preceded by a template declaration

Same as above; we just have to cope with a template header.

vi/ a number of concept-related variants that I don't quite grok yet.

These are for scoped concept maps.

The current code is only annotated with the grammar for (i) and (ii)

Our general philosophy is: make C++98/03 work first, but design in support for C++0x so that it's easy to implement later. Of course, we love patches for C++0x features, too!

Personally, I would rather see a broad set of test-cases before starting an
implementation, as there are some nasty cases to catch such as different
rules for duplicate identifiers at namespace or class scope etc.

So long as we have a decent test case with the implementation, I'm happy. That said, Alisdair implies another important point: coming up with test cases is very helpful for the development process, even when we don't yet have an implementation!

  - Doug