Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Treatment of #define #47

Closed
russel opened this issue Jan 19, 2016 · 7 comments
Closed

Treatment of #define #47

russel opened this issue Jan 19, 2016 · 7 comments

Comments

@russel
Copy link
Contributor

russel commented Jan 19, 2016

From what I can see #define is removed but the values of them are used. So the C code:

define LENGTH 4

char a[LENGTH];

becomes the D code:

char[4] a;

Might it be better to be more careful with these values and create an immutable variable to replace the #define value as would be done in C++.

immutable LENGTH = 4;
char[LENGTH] a;

@jacob-carlborg
Copy link
Owner

DStep doesn't currently handle anything from the preprocessor at all.

@russel
Copy link
Contributor Author

russel commented Jan 20, 2016

So how does dstep get the 4 for the "char[4] a" if it hasn't at least remembered the value of LENGTH in some way?

@UplinkCoder
Copy link

dstep does not.
clang does run the preprocessor.

I do not think it is a good idea to handle preprocessor stuff in step...
it is best left to clang

@jacob-carlborg
Copy link
Owner

So how does dstep get the 4 for the "char[4] a" if it hasn't at least remembered the value of LENGTH in some way?

It just calls the libclang function clang_getArraySize.

@mihails-strasuns
Copy link
Contributor

@russel it is important to remember that in C pre-processing and compiling are done in two completely separate steps. By the time source code gets to compiler (and thus to dstep which is built on top of libclang) it already looks like char[4] a with all macros expanded.

To do what you want one needs to either plug into preprocessor and pass some state to compiler parser from it or write your own C pre-processor which replaces numeric defines with enum instead of doing actual text substitution. Or something similar.

@russel
Copy link
Contributor Author

russel commented Jan 22, 2016

@Dicebot Ah, OK, crucial bit of information: DStep is working on the abstract syntax tree form of the code not the source itself. Sounds like a pre-pre-processor which converted #defines into either inline functions or constexpr values would be needed to solve the problem I have here.

@jacob-carlborg
Copy link
Owner

@Dicebot Clang retains the full source information, that's the whole point of Clang. They tried create tools based GCC but it was difficult/impossible because it did not retain the complete source information. For example, the parser did some forms of const folding. Something like const int a = 3 + 1; looked like const int a = 4; in the AST.

The necessary information should be available in Clang. When I started with DStep libclang did not have an API to interact with the preprocessor. It still doesn't, but I recently noticed that they provide a translation unit flag CXTranslationUnit_DetailedPreprocessingRecord that seems to be interesting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants