clean up Zicntr

[leekillough]

Clean up Zicntr to use [[noreturn]], declare destructor, and simplify if-code.

[kpgriesser]

I checked that Output::fatal calls std::exit so is std::terminate() there to satisfy the compiler? If we did a PR to change void Output::fatal to use [[noreturn]] would this eliminate the need for std::terminate(). I'm thinking that since this is used frequently in SST code it might be worth it to open an SST PR.

[leekillough]

I already fixed SST to use [[noreturn]] on Output::fatal(), but older versions of SST do not have that attribute, so std::terminate() is called afterwards to prevent compiler warnings about a [[noreturn]]-declared function (our fatal()function) possibly returning anyway because in previous versions of SST it doesn't know that Output::fatal() never returns, so we just add std::terminate() to tell the compiler that regardless of whether Output::fatal() returns, our fatal() function never returns and thus it abides by the [[noreturn]] attribute we declared it with. Otherwise we might get the warning Warning: Function declared [[noreturn]] reaches end of function or the like.

[kpgriesser]

just the 1 comment regarding if we should consider an sst pr

[leekillough]

just the 1 comment regarding if we should consider an sst pr

It was already filed and fixed months ago. See here and here.

But because we are ultra-strict about compiler warnings as errors, we must guard against the compiler thinking that our [[noreturn]] function may, in fact, return.

[leekillough]

void might_return();

[[noreturn]] void may_return() {
  might_return();
}

g++ -c may_return.cpp -Werror

$g++ -c may_return.cpp -Werror
may_return.cpp: In function ‘void may_return()’:
may_return.cpp:5:1: error: ‘noreturn’ function does return [-Werror]
    5 | }
      | ^
cc1plus: all warnings being treated as errors

With std::terminate():

#include <exception>

void might_return();

[[noreturn]] void may_return() {
  might_return();
  std::terminate();
}

g++ -c may_return.cpp -Werror

(no error)