Fix multiline function signature parsing

[KristofferC]

👨 @fredrikekre had an issue where the following parse was weird

julia> using JuliaSyntax

shell> cat bug.jl
function (
        ::A
        )()
end

julia> node = JuliaSyntax.parseall(JuliaSyntax.GreenNode, read("bug.jl", String))
     1:39     │[toplevel]
     1:38     │  [function]
     1:8      │    function
     9:9      │    Whitespace
    10:32     │    [tuple]
    10:10     │      (
    11:19     │      NewlineWs
    20:22     │      [::]
    20:21     │        ::
    22:22     │        Identifier       ✔
    23:31     │      NewlineWs
    32:32     │      )
    33:35     │    [block]
    33:34     │      [tuple]
    33:33     │        (
    34:34     │        )
    35:35     │      NewlineWs
    36:38     │    end
    39:39     │  NewlineWs

I let Claude lose on it and occording to it the issue was that with newlines the peek(ps, 2) check didn't function properly.

This is a bit AI slop so it might not make sense to merge but it might point to where the issue is at least.

---

🤖

Multiline function signatures with type annotations were incorrectly
parsed as tuples instead of calls when newlines appeared between
parentheses. For example:

function (
    ::A
)()
end

was parsed as (function (tuple ...) (block)) instead of the correct
(function (call (parens ...)) (block)), inconsistent with the
single-line version function (::A)() end.

The issue was in parse_function_signature where peek(ps, 2) was used
to detect if a call pattern follows the closing parenthesis, but this
didn't skip newlines.

🤖 Generated with Claude Code

Co-Authored-By: Claude [email protected]

[KristofferC]

I'll be honest in that I don't really know what is going on here...

[Keno]

This is the same condition as the maybe_grouping_parens below - should be refactored if that's intended.

[Keno]

So the odd thing about this is that it needs to ignore whitespace before the first peek token, but not the second one. I don't know that these conditions here make any sense. We don't have a peek api like that, but I think that's what's needed.

[Keno]

I think the correct solution is to move the _needs_parse_call outside the do block - it seems weird that it would affect needs_parameters, because if there are parameters, the peek will never actually see the parenthesis.

[KristofferC]

Armed with stronger neural nets, I gave this another try 😆