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

Understand preprocessor conditionals #47

Open
AbigailBuccaneer opened this issue Apr 29, 2015 · 3 comments
Open

Understand preprocessor conditionals #47

AbigailBuccaneer opened this issue Apr 29, 2015 · 3 comments

Comments

@AbigailBuccaneer
Copy link
Collaborator

Currently preprocessor conditionals are just ignored - everything in them is parsed as usual regardless of whether the condition is true. This would lead to parser errors in a bunch of different ways.

@Darkyenus
Copy link
Owner

Do you have any idea how to fix this? Seems very complicated, considering how much corner cases this could have.

@AbigailBuccaneer
Copy link
Collaborator Author

This is only really feasible once constant expression analysis is implemented - I think it should work out okay to use the same analysis for other expressions as with preprocessor conditions. Even if we can't get the conditions right, it's still better to parse it either one way or the other than it is to assume both an #if and #else block are true.

@AbigailBuccaneer
Copy link
Collaborator Author

CLion's approach to this is to generate OCDirective elements for the #ifdef/#else/#endif as usual, but to replace the element types of whichever branch is inactive with a special comment token type, so all the non-compiled PsiElements end up as PsiComment(CONDITIONALLY_NON_COMPILED_COMMENT).

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

2 participants