Eval bug: minja does not support numeric dotted attribute access (x.0), making jinja caps return all-false #28786

Name and Version

b10236

Operating systems

Linux

Which llama.cpp modules do you know to be affected?

libllama (jinja caps), llama-server

Problem description & steps to reproduce

minja doesn't support numeric dotted attribute access (x.0); Jinja2 treats it as x[0]. A template using it makes the caps probe throw, and caps_get then returns all capabilities false rather than keeping what the successful probes found.

GLM-5.3-Flash's template uses x.0 in 4 places, which gives two symptoms with one cause: /props shows supports_tools: false (also reported in #27754, no reply), and any request with tools returns Unable to generate parser for this template.

Repro, no weights:

cmake -B build -DGGML_CUDA=OFF -DLLAMA_BUILD_SERVER=OFF -DLLAMA_CURL=OFF
cmake --build build --target llama-template-analysis -j
./build/bin/llama-template-analysis --template-file GLM-5.3-Flash.jinja

supports_tools, supports_tool_calls, supports_parallel_tool_calls and supports_string_content all come back false. Changing only .0. → [0]. (4 occurrences) flips all four to true. GLM-4.7-Flash.jinja is in-tree, has no x.0, and passes.

Once supports_object_arguments is false, func_args_not_string() never runs in chat.cpp, so tool arguments stay a JSON string and the autoparser dies calling .items() on it — that's the line in the error, but it isn't the cause. supports_string_content: false is the giveaway that this isn't tools-specific.

No template in models/templates/ uses ident.0., so this looks untested. Fix is either parsing x.0 as x[0], or not discarding inferred caps when one probe throws.

First Bad Commit

Not bisected; GLM-5.3-Flash support is itself unmerged (#27754).

Relevant log output

Unable to generate parser for this template. Automatic parser generation failed:
While executing CallExpression at line 163, column 57 in source:
...c.arguments %}{% for k, v in _args.items() %}<arg_key>{{ k }}</arg_key>...