NonTerminalNode.findChildNode() including start offset when finding child nodes

[IMS94]

In the current NonTerminalNode.findChildNode() implementation, the start offset of a text range is excluded purposefully.

            if (textRange.startOffset() > offset && textRange.endOffset() <= offsetWithMinutiae) {
                // Populate the external node.
                return Optional.ofNullable(this.childInBucket(bucket));
            }

Based on a discussion had with @nadeeshaan and @rasika it was made clear that this was to support the left to right writing pattern. However, this causes an issue when working with VSCode client.

That is, consider the create function code action. Suppose we have the following ballerina code:

public function main() {
    string a = let string val = get<cursor>Str() in val.concat(" ", "1");
}

When the user has the cursor on getStr() method, the VSCode client sends the cursor position as <cursor>getStr() which is the start position of the diagnostic location. Therefore, when we search for the node at the cursor, what we always get is the LetVariableDeclarationNode instead of the FunctionCallExpression.

Due to this limitation, we have to identify the function call expressions based on the node type returned. For example, this is what we use currently to get the function call expression out of different node types.

    public static Optional<FunctionCallExpressionNode> getFunctionCallExpressionNodeAtCursor(NonTerminalNode cursorNode) {
        Optional<FunctionCallExpressionNode> fnCallExprNode = checkAndGetFunctionCallExpressionNode(cursorNode);
        if (fnCallExprNode.isEmpty()) {
            switch (cursorNode.kind()) {
                case LOCAL_VAR_DECL:
                    VariableDeclarationNode varNode = (VariableDeclarationNode) cursorNode;
                    Optional<ExpressionNode> initializer = varNode.initializer();
                    if (initializer.isPresent()) {
                        fnCallExprNode = checkAndGetFunctionCallExpressionNode(initializer.get());
                    }
                    break;
                case ASSIGNMENT_STATEMENT:
                    AssignmentStatementNode assignmentNode = (AssignmentStatementNode) cursorNode;
                    fnCallExprNode = checkAndGetFunctionCallExpressionNode(assignmentNode.expression());
                    break;
                case SIMPLE_NAME_REFERENCE:
                    fnCallExprNode = checkAndGetFunctionCallExpressionNode(cursorNode.parent());
                    break;
                case SPECIFIC_FIELD:
                    SpecificFieldNode fieldNode = (SpecificFieldNode) cursorNode;
                    if (fieldNode.valueExpr().isPresent()) {
                        fnCallExprNode = checkAndGetFunctionCallExpressionNode(fieldNode.valueExpr().get());
                    }
                    break;
                case LET_VAR_DECL:
                    LetVariableDeclarationNode letVariableDeclarationNode = (LetVariableDeclarationNode) cursorNode;
                   ???
                    break;
            }
        }

        return fnCallExprNode;
    }

    public static Optional<FunctionCallExpressionNode> checkAndGetFunctionCallExpressionNode(NonTerminalNode node) {
        FunctionCallExpressionNode functionCallExpressionNode = null;
        if (node.kind() == SyntaxKind.FUNCTION_CALL) {
            functionCallExpressionNode = (FunctionCallExpressionNode) node;
        }

        return Optional.ofNullable(functionCallExpressionNode);
    }

This approach is ok for simple scenarios as above. But,

1. For let expressions, we have to manually check again if the function call is in the first part or the 2nd part of the let expression.
2. For other node types which are not present here, we will have to do the same checks.
3. This was in the Create Function Code Action implementation, but we will face the same issue for other code actions as well.

All the above issues could be solved, if we can add a new API to NonTerminalNode to search for child nodes while including the starting offset. @nadeeshaan @rasika WDYT?

[nadeeshaan]

I think introducing the new API would be the ideal solution in this case, since the existing API's usage is intended to honour the left to write writing pattern. If we are to use the same API with modifications for the position inputs we might need to calculate the positions and ranges which will not suit all the cases and the changes will scatter. Therefore I think API addition would be a better option here

[IMS94]

I overloaded the NonTerminalNode.findNode() method with the option to include start offset when searching for a node. Only 3 unit tests were affected by the change. Will be sending a PR in a moment.

Now the NonTerminalNode has public NonTerminalNode findNode(TextRange textRange, boolean includeStartOffset) which can be used to search for a node including the start offset of the line range.. Updated the CommonUtil.findNode() to include the start offset by default.

[IMS94]

PR: #28936