chat: only treat [tool_name( as tool-call start in LFM2.5 parser

[Dev-iL]

Overview

LFM2.5 has no tool-call wrapper token, so its PEG parser stopped content at any bare [ and forced what followed into the tool-call branch. Ordinary content containing a [ (a list, an index, items = [...]) failed the parse, and the server surfaced the throw as an HTTP 500.

Per review feedback, the fix is limited to the LFM2.5 parser: content now stops only at [{tool_name}( for the defined tools (plus <|tool_call_start|>), matching the grammar triggers. A bare [ that doesn't start a defined tool call is consumed as content and the parse succeeds. This also fixes streaming, where the failed branch retracted already-streamed content.

Tests: two regression cases for bracketed content with tools defined, plus one partial-parse case asserting streamed content stays monotonic across a bare [.

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES: AI was used to pinpoint the problem and write the new tests' description.

[ggml-gh-bot]

Hi @Dev-iL, thanks for your contribution!

Per our contribution guidelines, the automated PR checker found the following issue(s) that need your attention:

• Multiple open PRs from a new contributor: We limit new contributors (those without a previously merged PR) to 1 open PR at a time. You currently have 2 open PRs.

---

Please note that maintainers reserve the right to make final decisions on PRs. If you believe there is a mistake, please comment below.

[aldehir]

The issue is here:
https://github.com/ggml-org/llama.cpp/blob/master/common/chat.cpp#L1765

If the model can produce tool calls without special token, then it should consume content until [{tool_name} for any tool instead of a single [. This will align it with the grammar triggers and constrain it to produce parseable output.

I don't know of any other parser that behaves this way, so the fix should be limited to the LFM2.5 parser.

[Dev-iL]

Thanks for the pointer!

• The modifications to the shared failure path were reverted in favor of tightening the LPM-specific logic.
• Another test case was added for streaming (partial-parse).

[tdakhran]

Discussed this internally with the team at Liquid AI, any valid tool call shall be wrapped by <|tool_call_start|> / <|tool_call_end|> tokens, existing logic in upstream is incorrect.

#24178 addresses the issue. There is a markdown test there that is treated as a tool call in upstream.

[Dev-iL]

Discussed this internally with the team at Liquid AI, any valid tool call shall be wrapped by <|tool_call_start|> / <|tool_call_end|> tokens, existing logic in upstream is incorrect.

#24178 addresses the issue. There is a markdown test there that is treated as a tool call in upstream.

Is there anything in this PR worth keeping?

[tdakhran]

Discussed this internally with the team at Liquid AI, any valid tool call shall be wrapped by <|tool_call_start|> / <|tool_call_end|> tokens, existing logic in upstream is incorrect.
#24178 addresses the issue. There is a markdown test there that is treated as a tool call in upstream.

Is there anything in this PR worth keeping?

I suggest superseding it with #24178, it fixes more cases. Your fix for [ was on point and passes markdown test! Thanks for your contribution, @Dev-iL!

[Dev-iL]

Is there anything in this PR worth keeping?

I suggest superseding it with #24178, it fixes more cases.

What about the new unit tests? Any point to keep them? If yes - perhaps include them in your PR?

[tdakhran]

Is there anything in this PR worth keeping?

I suggest superseding it with #24178, it fixes more cases.

What about the new unit tests? Any point to keep them? If yes - perhaps include them in your PR?

My PR adds new unit tests, including this one for markdown links.