[dsvr]

No, Vely does not understand C. Yes, gcc produces error messages when it comes to C code itself. However, the line number where the issue is located is exactly matched to the Vely source code using #line directive, so I would say 90+% of the time you don't have to look at the generated code. If that is not enough, you can use --c-lines to get the error reported from generated code, which is the exact error, and in that case, yes like you said you need to look at the generated code. Most of the time, however, just looking at the exact embedded statement is enough to figure out what the problem is.

I mentioned in another post that a C program could be parsed to the extent to allow better checking. Not to the point where you'd build a gcc-look-alike, but just enough for instance to know the type of the expression, and if the expression used in Vely statement is correct, and such. Perhaps that's something to consider. I thought about it here and there, but found it to be more useful to check for logical conflicts, such as not providing required arguments, balancing beginning and end of multi-part statement, incorrect usage and such. Typically, using the wrong type accounts for most of the issues, and gcc produces very good messages. Again those messages get matched to the source Vely file exact line number, and I found that correcting an issue isn't difficult.

Your tool sounds great, and if it works what you need it do, awesome! I do things like that all the time, and find that often times using tools is an overkill, and just skip it. There's time and place for everything.

[lelanthran]

TBH, I wasn't concerned at all about matching errors to line numbers (I didn't mention matching up the line numbers because I assumed it would anyway); I've done this sort of thing before and never had a problem setting the correct line numbers in the outputted C sources.

The problem I usually have is matching C-compiler error messages to $NEWLANG errors.

Like I said, as long as the programmer is aware that it's a preprocessor for the language and not an AST-based code generator, then there usually isn't a problem. I used ecl (or gcl, not sure now) that went the AST code-generation path and it worked much better than any preprocessor-based method in terms of compilation errors and diagnostics.

PS. In case you (or anyone else) is wondering about my mentioned HTML preprocessor, I put it into a gist: https://gist.github.com/lelanthran/603a24c56bc3afc1370a007a0...