product of preprocessor macro expansion must be translated to D

[Laeeth]

-> to . for pointers.
cast
possibly other things too.

[atilaneves]

I guess by "cast" you mean C-style casts.

[atilaneves]

If you have an example of the offending code it would be much appreciated.

[Laeeth]

Same story as before. But see libetpan example under kaleidic associate's repo

[Laeeth]

Yes C style casts

[atilaneves]

Blocked on #24

[atilaneves]

There's still a failing test so I reopened this.

[Laeeth]

This is a sledgehammer to crack a nut. But there's a project called rust2c and it translates the C AST from libclang to Rust. We can use their front end,which produces a cbor (like msgpack) output of the ast. We could consume that in D and have a C to D translator. I want that anyway someday but will try to make it a SAoC project or something. That might be the only way to be sure to handle macros perfectly.

The other possibility is to create a Cpp file that instantiates macro from a templated wrapper function.

It's not the end of the world if there aren't too many macros.

[atilaneves]

We can't handle macros perfectly because they're not C. We can't instantiate function-like macros in the generic case because there isn't one.

The preprocessor is completely separate from C-the-language. If I have a MACRO(x) what do I instantiate MACRO with? An int? A string with quotes? Without quotes? If there are curly braces in it, is it supposed to generate a function? Initialise a struct?

We don't need a C to D translator - libclang has the whole C AST, it's C++ where it's lacking. Even if we did, using dpp to do it would be a better option.

[Laeeth]

Re even if we did need a translator,using dpp to do it would be a better option - no, because a project can't in the end go against the vision of the maintainer.

We are talking instantiated macros. Feynman once caused a scandal by asking as a professor in the university library for a map of the cat because he didn't know what it was called. I didn't know till you mentioned your colleague what the term translation unit meant because I never heard of it on CP/M, but I know roughly how the preprocessor works !

I agree there is no way to solve the problem perfectly given assumptions. The problem though I think is less with pseudo functions and more with macros that only have a meaning within a particular scope. Like postgresql logging macros.

In theory you could transform the surrounding statements or functions from D back to C so macro had a context where it fitted and then turn expanded back to D. However the difference between theory and practice is bigger in practice than in theory...

I think the best solution really is to accept that it's not going to work in some cases. Some might give up on the dpp concept there but I don't agree -the basic concept is right because it has to mostly work so it will.

So the answer is just to be able to blacklist certain macros (like foreach macro in postgres!) and allow manipulation too like regex substitution for expanded macro globally or for a particular one.

Or the last resort:a plugin/callback so you can control behaviour directly. That way you get a header that just works and a good chance still works after the next release, presuming the C ABI is the same.

[atilaneves]

Given the complexity of the issue and how macros can do anything they want and can't be analysed with a parser, I think trying to automatically translate as much as possible and leaving it to the user to hand translate whatever doesn't work is the best way forward.

We don't even need to blacklist any macros - if they're not used they might as well not exist.