Posted 7 years ago by Tobias Lingemann - Software Devolpment Engineer, Vector Informatik GmbH
Avatar
Hey there and happy new year,

would it be possible to get support for the pre-processor directive #if?
Meaning that if the expression is always equal to 'false' the region is marked as disabled (gray text) and can be collapsed.


Best regards, Tobias Lingemann.

Comments (6)

Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Hi Tobias,

Thanks for the suggestion. It's a fairly tricky thing to implement that since it would involve creation of a preprocessor, a way to maintain the defined variables, and an expression evaluator. We'll mark it on the TODO list though for future possible implementation.


Actipro Software Support

Posted 3 years ago by Tobias Lingemann - Software Devolpment Engineer, Vector Informatik GmbH
Avatar

Are there any updates on that topic? Our customers start complaining since this causes problems in our product. The C# compiler doesn't report any errors, but our tool thinks the method isn't unique since we rely on your AST.

  public static void test() {}

#if false
  public static void test() {}
#endif

We don't really care about the presentation, but we need a way to check if the method is available in the compiled code.


Best regards, Tobias Lingemann.

Posted 3 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Tobias,

We don't have anything new in this area.  How would you like it to work in terms of API?  Per above, we'd need some way to track which preprocessor variables are defined at a project level, have an expression evaluator that can use those variables and determine boolean results for #ifs, #elifs, and #else, handle additional #defines and #undefs, and not feed tokens to the parser when in a section that ends up being excluded.


Actipro Software Support

Posted 3 years ago by Tobias Lingemann - Software Devolpment Engineer, Vector Informatik GmbH
Avatar

Hi,

We currently don't have preprocessor variables on a project level, so that would not be an issue for us. My first idea would be, that those AST nodes would still be visible. They just have a property or a method to check if they are active or not. Each AST node might have a method where you can pass a preprocessor evaluator and return true or false, whether the node is visible or not. That could also be a part of the ProjectResolver. With this preprocesor evalutaor the client could set variables like in Visual Studio with the project configuration (though we don't need it, other folks might appreciate it). The #define and #undef commands in code should automatically be evaluated.

Basically the preprocessor evaluator only needs to figure out which regions are active, like offset x to y. And the MethodDeclaration node just looks if its header is inside of an active region.


Best regards, Tobias Lingemann.

Posted 3 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Tobias,

From an implementation standpoint, I don't think that is really feasible.  Mainly because you can choose to #if partial statements like the beginning of an 'if' statement or the beginning of method declarations.  ASTs could be completely different based on what is conditionally active at the time.  It seems like if this will be supported at all, we would need some project level list of declared preprocessor variables.  Then when reading tokens, we'd have to start with that and when encountering an #if, we'd need to execute expression evaluation logic on it and compare to the defined preprocessor variables.  If a block isn't valid, we'd not want to pass it to the core parser at all.  #define/#undef would alter the known proprocessor variables.  The parser would only effectively see what is "valid" code at the time and no AST info would be generated for invalid blocks.  We could possibly include a list of text ranges for invalid blocks on the root CompilationUnit though.  Thoughts?


Actipro Software Support

Posted 3 years ago by Tobias Lingemann - Software Devolpment Engineer, Vector Informatik GmbH
Avatar

That would work for us too. Our main problem is that we can't distinguish the two methods. If we don't know the second one, our problem is gone too. I just thought it would be nice to still see the inactive parts, but you are right. That could be problematic.


Best regards, Tobias Lingemann.

The latest build of this product (v2018.1 build 0341) was released 3 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.