C# Parser Fails (Root ERROR Node) with Nested Preprocessor Directives Conditionally Defining Method Parameters

[pavlo-shchelkun]

The tree-sitter-csharp parser fails and produces a root ERROR node when encountering nested C# preprocessor directives (#if ... #else ... #endif) that conditionally alter a method's signature, specifically its parameter list.

Environment:

• py-tree-sitter version: 0.24.0
• tree-sitter-language-pack version: 0.7.3
• tree-sitter-csharp grammar version: 0.23.1
• tree-sitter-embedded-template grammar version: 0.23.2
• Operating System: macOS Sonoma 14.5

Minimal Reproducible Example:

// test_conditional_signature.cs
namespace TestNs
{
    public class TestClass
    {
#if OUTER_CONDITION // Outer preprocessor block
    #if INNER_CONDITION // Inner preprocessor block
        static void MyMethod() // Signature 1: no parameters
    #else
        static void MyMethod(int param) // Signature 2: with parameters
    #endif
        {
            // Common method body
        }
#endif
    }
}

Observed Behavior:
When parsing the above code, tree.root_node.type is ERROR and tree.root_node.has_error is True.

Expected Behavior:
The parser should correctly parse this valid C# construct, recognizing the method declaration with its conditionally defined parameter list. The root node should be compilation_unit and has_error should be False. Tree-sitter should parse the structure including both potential branches of the inner #if/#else.

Note:
If the method signature is not fragmented by inner preprocessor directives, it parses correctly. For example, if only one signature is used within the outer conditional block:

// This parses correctly:
namespace TestNs
{
    public class TestClass
    {
#if OUTER_CONDITION
        static void MyMethod(int param) 
        {
            // Common method body
        }
#endif
    }
}

This suggests an issue with the grammar's ability to handle preprocessor directives appearing within the syntactic structure of a method's parameter list definition. While preprocessor directives are often in extras, their interaction with the rules for parameter_list or method_declaration seems problematic in this nested scenario.

[damieng]

We've looked at this before in #189 and the reality is there is no comprehensive way to parse this as you would need to parse the csproj to see what is defined (tree-sitter only parses one file at a time so can't do that) or you would need to explore every single possible combination (exponentially dangerous and last time we looked at this tree-sitter did not support that either).

If you have found another language using tree-sitter is doing a good job with this let us know so we can investigate.

[Tuupertunut]

Although back in the day of #189 the rewrite of #333 hadn't happened yet so the reason this fails is different, as far as I've understood. Before #333 all #if #else macros were in extras and they were parsed with the code sections concatenated as if the macros didn't exist, but now there are specific #if macro block rules (preproc_if) that include both branches and they just aren't allowed in all contexts. Correct me if I'm wrong.

[Tuupertunut]

I just got an idea: What if the #if macro would be in extras but #else would be a block statement containing the code in the #else section? The current special rules for where #if macros are allowed would then only apply to the #else branches. #if #else would work the same as now but plain #if would work everywhere, no matter what it wraps. The only downside is that the #if and #else branches would look different in the parse tree.

Or an even more advanced idea. Make #else both a simple extras rule and an #else block statement. I'm not sure if you could use GLR parsing in this way but if parsing as an extras rule fails, the parser would try again and parse the #else section as a block statement and only then would you need special rules for what it may contain. If this works it would be pure improvement over any previous ways of treating #if macros.