Invalid conditional evaluates true

[white-haired-uncle]

Game and System Information

• Version:

spartan$ /opt/wesnoth-1.19-git/bin/wesnoth --version
Battle for Wesnoth v1.19.0-dev (ebe84ce-Modified)
Started on Fri Apr 19 00:17:09 2024

Battle for Wesnoth 1.19.0-dev

Library versions:
Boost: 1.74
Lua: 5.4.6
OpenSSL/libcrypto: 3.0.0b-dev (runtime 3.0.0b-dev)
libcurl: 7.81.0 (runtime 7.81.0)
Cairo: 1.16.0 (runtime 1.16.0)
Pango: 1.50.6 (runtime 1.50.6)
SDL: 2.0.20 (runtime 2.0.20)
SDL_image: 2.0.5 (runtime 2.0.5)
SDL_mixer: 2.0.4 (runtime 2.0.4)

Optional features:
Lua console completion: yes
D-Bus notifications back end: yes

• OS:
  spartan$ uname -a
  Linux spartan 5.15.0-97-generic #107-Ubuntu SMP Wed Feb 7 13:26:48 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Description of the bug

It appears that at least some conditionals will always evaluate as true when constructed using invalid arguments, such as using "equal=" instead of "equals=" in [if] or [show_if].

Steps to reproduce the behavior

In the attached scenario, move your unit to the tree and observe the dialog.

GUI_Tutorial.tar.gz

Expected behavior

Ideally, invalid input would produce an error.

Additional context

I probably would have marked this as an enhancement if it had evaluated as false, because how can an invalid can't be true, so false is at least partially right. But it returns true, which IMO is a bug.

It would be great if every possible error condition could be planned for ahead of time, but since that's probably not going to happen I would suggest that in addition to catching as many mistakes as possible the default for a conditional be false.

[soliton-]

[variable] actually has some checks built in already but you didn't even write the tag though.

Looks like there is a central function for condition evaluation that could warn about unknown attributes and maybe default to false.

[CelticMinstrel]

Looks like you forgot to link to the forum thread.

[white-haired-uncle]

[variable] actually has some checks built in already but you didn't even write the tag though.

Wow. I meant to screw those up, but not that badly.

With [variable] all tests still evaluate true, but one gives:
20240419 14:34:46 error wml: [variable] with missing name=

https://github.com/wesnoth/wesnoth/files/15044456/01_One.cfg.gz

If I'm going to continue to dig out stuff like this by making silly mistakes I should probably learn how to write a proper test case. One more thing on the list I suppose.