v0.4: Compilation error for GAP 4.13 & clang++ 15: value of type 'void' is not contextually convertible to 'bool'

[kiryph]

I have updated my GAP installation from 4.12.2 to 4.13.0 and was trying to recompile the debugger package:

❯ cd ~/Library/Preferences/GAP/pkg/debugger-0.4
❯ ./configure /usr/local/opt/gap/libexec
❯ make V=1
"/usr/local/Cellar/gap/4.13.0/libexec/gac" -d -p "-MQ "gen/src/debugger.o" -MMD -MP -MF gen/src/debugger.d" -p " " -c src/debugger.cc -o gen/src/debugger.o
clang++ -std=gnu++11 -pthread -g -O2 -fno-common -MQ gen/src/debugger.o -MMD -MP -MF gen/src/debugger.d -o gen/src/debugger.o -I/usr/local/Cellar/gap/4.13.0/libexec/build -I/usr/local/Cellar/gap/4.13.0/libexec/src -I/usr/local/Cellar/gap/4.13.0/libexec -DUSE_GASMAN=1 -c src/debugger.cc
src/debugger.cc:294:12: error: value of type 'void' is not contextually convertible to 'bool'
    return ActivateHooks(&debugHooks) ? True : False;
           ^~~~~~~~~~~~~~~~~~~~~~~~~~
src/debugger.cc:299:12: error: value of type 'void' is not contextually convertible to 'bool'
    return DeactivateHooks(&debugHooks) ? True : False;
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.
make: *** [gen/src/debugger.o] Error 1

My environment:

macOS: 13.6.1 (22G313)
arch: intel
❯ clang++ --version
Apple clang version 15.0.0 (clang-1500.1.0.2.5)
Target: x86_64-apple-darwin22.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

❯ gap
 ┌───────┐   GAP 4.13.0 of 2024-03-15
 │  GAP  │   https://www.gap-system.org
 └───────┘   Architecture: x86_64-apple-darwin22-default64-kv9
 Configuration:  gmp 6.3.0, GASMAN, readline
 Loading the library and packages ...
Syntax warning: Unbound global variable in /Users/kiryph/Library/Preferences/GAP/pkg/debugger-0.4/gap/debugger.gi:3\
9
			ADD_BREAKPOINT(i, line, function()
			^^^^^^^^^^^^^^
Syntax warning: Unbound global variable in /Users/kiryph/Library/Preferences/GAP/pkg/debugger-0.4/gap/debugger.gi:4\
3
			ADD_BREAKPOINT(i, line, func);
			^^^^^^^^^^^^^^
Syntax warning: Unbound global variable in /Users/kiryph/Library/Preferences/GAP/pkg/debugger-0.4/gap/debugger.gi:6\
4
		if CLEAR_BREAKPOINT(i, line) then
		   ^^^^^^^^^^^^^^^^
Error, Variable: 'CLEAR_ALL_BREAKPOINTS' must have a value
not in any function at /Users/kiryph/Library/Preferences/GAP/pkg/debugger-0.4/gap/debugger.gi:71
Error, was not in any namespace at /usr/local/Cellar/gap/4.13.0/libexec/lib/variable.g:269 called from
LEAVE_NAMESPACE(  ); at /usr/local/Cellar/gap/4.13.0/libexec/lib/package.gi:1349 called from
<function "ReadPackage">( <arguments> )
 called from read-eval loop at /Users/kiryph/Library/Preferences/GAP/pkg/debugger-0.4/read.g:6
you can 'quit;' to quit to outer loop, or
you can 'return;' to continue
brk>

I am not sure if I have updated the compiler since I installed the GAP debugger package. The error seems like an issue with a newer compiler which is more strict than the older ones.

[fingolfin]

No, the issue is a genuine error -- the debugger package is undeposited, unofficial and essentially unmaintained (but @ChrisJefferson feel free to contradict me). It access deep internals of the GAP kernel, and as such needs to be adjusted for new GAP versions. That hasn't happened so far.

[ChrisJefferson]

Yes, I developed this package to deal with a particularly horrible series of issues I was having (and also partially to see if I could do it!), but it was never polished, and isn't maintained.

If anyone actually wanted to use it, I wouldn't mind trying to update it, my assumption was no-one was really interested, so I didn't bother since I've haven't recently needed it's functionality.

[ChrisJefferson]

I should however probably make a firm decision, either fix it, or make it clearer that it is broken

[fingolfin]

To be clear, the breakage was introduced by gap-system/gap#5302 where I removed the unused return values for ActivateHooks and DeactivateHooks because I could not see anything using them. I have no problem if someone wants to add them back. But on the long run, the only protection against such things is to have this package deposited, so that we run tests against it and notice regressions quickly.