jinja: support none|string

[pwilkin]

Would partially fix #18974

[CISC]

You should always test with test-jinja -py. :)

[CISC]

One could argue that value_none_t should have as_string too, and I think there are some other places that don't treat this correctly.

[ngxson]

One could argue that value_none_t should have as_string too, and I think there are some other places that don't treat this correctly.

I think as_string is currently never used in none, so no strong opinion if it should be added. In most places, we have logic to check if input is null, and if yes, we just either skip it or throw an exception.

[CISC]

One could argue that value_none_t should have as_string too, and I think there are some other places that don't treat this correctly.

I think as_string is currently never used in none, so no strong opinion if it should be added. In most places, we have logic to check if input is null, and if yes, we just either skip it or throw an exception.

Here's the one I was thinking of:

llama.cpp/common/jinja/runtime.h

Lines 574 to 575 in 0be21c4

	static void gather_string_parts_recursive(const value & val, value_string & parts) {
	// TODO: probably allow print value_none as "None" string? currently this breaks some templates

[ngxson]

not quite remember why it doesn't work, but IIRC because some statements are treated as functions that returns None, so sometimes None appears out of nowhere in the rendered content. but yeah, currently I think this simple case: {{ None }} won't match what jinja2 would render

[CISC]

not quite remember why it doesn't work, but IIRC because some statements are treated as functions that returns None, so sometimes None appears out of nowhere in the rendered content. but yeah, currently I think this simple case: {{ None }} won't match what jinja2 would render

Ah, worth looking into at some point, would have been useful to know which template. :)