Quick question on is_disabler()

[Peter Hull]

Hi,

In several of the test cases (1 trivial/meson.build is one example) there is code that looks like this:

has_not_changed = false
if is_disabler(exe)
    has_not_changed = true
else
    has_not_changed = true
endif
assert(has_not_changed, 'Executable has changed.')

(see https://github.com/mesonbuild/meson/commit/b21fd95f737ab96f57c45e15a1d89d5c483daec8 for others)

What is the purpose of this code (I'm just curious)

Peter

[Eli Schwartz]

In the review comments for that commit:
https://github.com/mesonbuild/meson/pull/5725#discussion_r308775732

The basic idea here seems to be that we want to test that the
is_disabler() function doesn't *leak* a disabler object. Running this
function should never be optimized away like regular use of an assert
would do -- thus, the test actually asserts that the has_not_changed
variable *has* changed, heh.

One of the tests does actually test disabler objects themselves. I don't
think we strictly need to add tests of the is_disabler() function to so
many places, but on the other hand it's pretty fast to do pure
configure-time asserts.


--
Eli Schwartz

[Peter Hull]

On Sunday, 23 April 2023 at 06:40:15 UTC+1 eschw...gmail.com wrote:

The basic idea here seems to be that we want to test that the
is_disabler() function doesn't *leak* a disabler object.

Got it, I think! The first thing someone might try is 'assert(not is_disabler(exe), ...)' but if is_disabler() returned a disabler rather than a bool, 'not disabler()' is also a disabler, and the assert would itself be disabled. 

It was having an 'if' with two identical arms plus the slightly obscure (?) assert message that threw me. Also the code suggested by jpakkane is the opposite way around to the code actually committed, that's just messing with my mind!!

Thanks for the swift reply,

Peter