dpp
dpp copied to clipboard
atilaneves
Clang sometimes returns a negative number for size of a type
Which entertainingly originally told opaque to make a blob of near ulong.max!
It happens for array where the size of type depends on a template parameter for the enclosing struct. Still by the time it is instantiated you must know what the size of the type is. It doesn't happen often in relevant code. Does show that you will need some kind of post dpp pre dmd macro if you are to use dpp to compile.
For arrays and any other common offenders we can of course special case.
This is important since it's impossible to know the size of a template type a priori, which is needed to represent untranslatable types as blobs.
However suppose you were to tell dpp ahead of time which versions of the CPP templated things you wished to instantiate. Say by for example including a header file that instantiated them. Dpp could just pass on the impossible templates (only a subset) and then obediently wrap the instantiated types you asked it to. There won't be that many of them mostly and a bit of thought and effort will take care of what can't be automated.
Hmm... I'll have to see how these instantiated types work in practice. Sounds interesting.
I'm not convinced that clang won't tell you the size of the field once type is instantiated. If clang won't tell you probably libtooling would.
But suppose no library will do that.
It's still possible. Just generate a C++ program and use runtime to print compile time offset of and size of.
One more thing. Clang compiler dump records does dump sizes I think. It's just not so pleasant to parse the output.
libclang is returning negative even for fully instantiated templates, which is more than a little bit annoying.
libtooling is C++ and would require extensive manual wrapping before it could be used by dpp. In any case, any other source of information that isn't libclang would require extensive refactoring of the entire dpp codebase.
Of course one can always find out the size from C++ and manually declare a blob. I don't understand why the offset is needed - it's implicit in the size of everything that came before.
Offset isn't needed in the end once it works but until then if trying to figure out what's going on it's nice to have.
I was suggesting one could do it via C++ but not manually.