Open Laeeth opened 6 years ago
The macros are doing what they're supposed to - unfortunately (or not) the comma operator is deprecated in D. I'll have to think of what to do with that, it's not obvious.
The real issue here is the casts aren't caught by the heuristic that translates macros.
According to the dlang site section on deprecations the solution is to use a lambda, i.e.
// instead of `auto result = foo(), bar();`
auto result = () { foo(); return bar(); }();
Figuring out how to recognise that in a macro is going to be challenging.
Yes - I understand the macros are just doing what poor macros do, but for purpose at hand obviously to be useful one might want to find a way to do something so it just works. And agree that the casts are a second problem but distinct (they both matter).
Presumably you have from clang the mini-AST of the post-preprocessor expression the macro evaluates to? And comma operator is a kind of node there? I could be completely off the mark as I got a bit lost in clang docs.
Presumably you have from clang the mini-AST of the post-preprocessor expression the macro evaluates to?
Very unfortunately, no. Macros aren't C code, they're text substitutions. I have the text of the macro, which is its own separate minilanguage that, in normal C code, will eventually get parsed by the compiler if it's expanded anywhere. Until it's expanded, it's not code, and hence doesn't have an AST.
I considered forcing the expansion of the macro to then parse it, but then what do you expand function-like macros with? A string? An integer literal? And that's just one parameter, if it's three and the second one is a string but not the others, how is the translator generically to know?
A horrible answer that would work I think. The comma operator is still in D syntax right now, but is just banned. So one could find in D code - using libdparse- where the comma operator is introduced as a result of an expanded macro and fix it up as per the extract from the guide you posted. The problem is that it may disappear from grammar at some stage if it ends up being used for tuples etc and then it won't even be recognised but banned.
Anyway it's not worth the trouble for now. Probably mostly the user should just either manually redefine the comma-ridden macro with a different name in an extra include file or translate it to D. Could sometimes be difficult to do so I suppose but such is life.
I'd rather use dmd as a library (now that's a thing) than libdparse. It's good but it's not a proper frontend. That would massively complicate things though. I'm not sure what the best solution is.
➜ examples d++ foo.dpp
Note also H5S_ALL and H5P_DEFAULT have cast and if possible D-style explicit cast should be added. For comma operator would opening new scope and turning it into ; work?
In this case it isn't that bad - easy to remedy with minor work.