mvandervoord
commented
6 years ago Excellent Question.
We've considered using a real parser many times. There are even a couple branches that have this partially implemented. In the end, the problem has always been the same: We're trying to parse a superset of any particular compiler... meaning CMock, for the most part, parses code intended for many compilers, including a number of them with non-standard extensions (like attribute(()) in gcc or @0x5200 in XC8). When we switch to a "real" parser, we're then stuck with whatever features that parser has.
The counter argument (and the one that has motivated me to work on this in the past) is that while we are able to support more targets doing it the way we are presently, we are supporting all the targets LESS completely.
Replacing the C parser is actually on our schedule. CMock 3 is going to use a real parser. The plan is to use a clang-based parser to give us standard C plus all the gcc extensions... and then to have a custom preprocessor which looks for things like XC8's @address and replace them with the gcc equivalent before preprocessing... so a pre-preprocessor?
In any case, this is a major chunk of work, which has made it get pushed off a few times now. (shameless plug: if any business would like to sponsor CMock 3, let me know. I'd love to be able to throw all my attention at it!)
Letme
Hello, I was wondering wether you're aware of the clang-based C/C++ source parsers like CastXML that emit function information? I feel a bit uneasy when keeping in mind that CMock uses custom code and regular expressions to parse header information. Or maybe I'm just totally misguided...