2 ms·
It would be great to be able to integrate this into the Clang pipeline so that Clang based auto completion and error detection would not trip over it but correc
by terhechte 13y ago
It would be great to be able to integrate this into the Clang pipeline so that Clang based auto completion and error detection would not trip over it but correctly evaluate the resulting source and use that. Then, it would be easy to integrate this into an existing project workflow. Otherwise it would limit usability due to a lack in tooling support, I'd guess.
Clang already does that for the C preprocessor, although that is probably much easier to do since it is not Turing complete [1]
[1] By definition. Though some people throw crazy things at it: http://stackoverflow.com/questions/3136686/is-the-c99-preprocessor-turing-complete http://stackoverflow.com/questions/3136686/is-the-c99-prepro...
- eudox 13y agoI actually started out trying different parsers (Clang, pycparser), but they validate too much. cmacro uses a home-spun parser because it's meant to let you write things like: route "/user/edit" POST => lambda(Req* request) -> Resp* { ... } Which isn't even close to valid C. As for integration: It's pretty simple to operate from the command line, which is good enough for integration with eg. a Makefile-built project.
- ghkbrew 13y agoYeah, I'm guessing the parsing would be a problem for integrating with other actual c-language parsers. It looks like the the parsing is completely open ended. I.E. there is no way to tell if you've completely parsed the macro without knowing the macro definition. Maybe taking a page out of rust's handbook and adding slightly more syntax to the macro would help. If the parser knows that a macro is any identifier followed by a ! and then enclosed in braces, it could simply ignore the contents and continue parsing.
- _pmf_ 13y agoDo you have an example or description of what the "toplevel" directive does? Is it for start-of-block declarations?