Making a C parser.

Clang Frontend
1

Hi everyone,
my objective is making a C parser in order to obtain a abstract syntax tree.

So I was wondering:
- is the interface of clang (lib) stable enough that I can work without
thinking that in few days all my code is good for only for trash?
- it is a good idea taking the clang (driver) code as base for making a
smaller, C only, parser that outputs the tree I need and uses clang (lib)?
Or it is maybe better adapt clang (driver) itself?

_Any_ feedback is welcome.
pb

2

- it is a good idea taking the clang (driver) code as base for making a
smaller, C only, parser that outputs the tree I need and uses clang (lib)? Or it is maybe better adapt clang (driver) itself?

you can already do this with the current clang drivers, no? with -ast-print/-ast-dump and -std=c89 or any others (there is should also be a serialize ast option but it is still broken I think)

You can write your own driver using the clang libs easily enough if it don't fit your need (especially since libdriver has been extracted from clang driver code).

but I am not sure I understand what you want to do?

Cédric

3

- is the interface of clang (lib) stable enough that I can work without
thinking that in few days all my code is good for only for trash?

Yes, it is cheaper to use clang to parse and build ASTs than to write your own. If you don't update clang or llvm, the interface will be stable forever. You can weigh the benefit brought by merging against the cost of merging at any time. My hope is that this will always remain compelling, though, clang is still undergoing reworking to handle more of C, more Objective-C and more C++. This alone means that the interfaces will change and few of them are set in stone. The bitcode files and the intermediate forms I think are more stable than the apis.

- it is a good idea taking the clang (driver) code as base for making a
smaller, C only, parser that outputs the tree I need and uses clang (lib)?
Or it is maybe better adapt clang (driver) itself?

It depends upon what you want. If you go with the driver, you face a smaller api hit to using it, however you might not get the resolution or control that you need. My recommendation would be to do with the driver, unless you needs require finer grained control.