Support #if false

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.

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.

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.

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?

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.