feat: added folding range support for imports

[benodiwal]

Closes #2103

• Only create folding range for 2+ consecutive imports
• Handle multiple import groups separated by non-import declarations
• Use .inclusive range to include semicolons
• Added some tests as well

A simple demo to see this feature in action:

[benodiwal]

Hey @Techatrix, can u please review this PR. Thanks.

[benodiwal]

Hey @Techatrix, is this issue #2103 planned for the next release ?

[benodiwal]

ig the checks are failing due to rebase

[Techatrix]

This recursively drills down field accesses to find the base.

This doc comment doesn't match the implementation. It's not recursive and doesn't look drill down a sequence of field accesses.

Field accesses should recursively check the left side of the expression. We can also assume that identifiers refer to aliases which should lead to better results than assuming the opposite. In the future, this logic should ideally be shared with code actions.

Here is how this could be implemented (without actual recursion)

fn isImportOrAlias(tree: *const Ast, init_node: Ast.Node.Index) bool {
    var node = init_node;
    while (true) {
        node = switch (tree.nodeTag(node)) {
            .builtin_call_two, .builtin_call_two_comma => {
                // just like before
            },
            .field_access => tree.nodeData(node).node_and_token[0],
            .identifier => return true,
            else => return false,
        };
    }
}

[Techatrix]

Suggested change

// Check if this is an @import() call or a field access/identifier based on an import

This comment is almost the same as the doc comment of isImportOrAlias so it doesn't carry any additional information.

[benodiwal]

Hey @Techatrix, thanks for the feedback on the PR. Got your point, the earlier implementation seems to be half baked from my side. You're absolutely right that the doc comment didn't match the implementation.

I implemented your suggestion, and it works much better. However, I'm seeing a case where it might create false positives. For example:

  const FoldingRange = struct { ... };  // Local struct
  const std = @import("std");
  const loc = FoldingRange.loc;  // ← Gets included in fold range

Since we assume all identifiers are aliases, FoldingRange.loc gets included even though FoldingRange is a local struct, not an import. Is this trade-off acceptable for the folding range use case, or should we add additional heuristics to filter these out?

[Techatrix]

I find this trade off acceptable. A future improvement can reuse the logic that is used for code actions.