It seems that using enum is not understood by MinGW and the baremetal job:

build/include/botan/tls_alert.h:75:13: error: expected nested-name-specifier before ‘enum’
   75 |       using enum AlertType;
      |             ^~~~

Why not stay with the current construction of having a plain enum nested inside class Alert? Isn't that the same "smart-enum" idiom we used in other places?

Also, my gut feeling is that this is why GCC is ICE-ing. Which it still does, by the way.

For instance in the GCC sanitizer job:

/home/runner/work/botan/botan/build/build/include/botan/asio_stream.h:628:47: internal compiler error: in tsubst_copy, at cp/pt.c:16822
  628 |                if(alert.type() == TLS::Alert::CloseNotify)
      |                                   ~~~~~~~~~~~~^~~~~~~~~~~
[...]

Why not stay with the current construction of having a plain enum nested inside class Alert? Isn't that the same "smart-enum" idiom we used in other places?

It is, but that's only because I just found out about using enum in C++20. If it works I plan to modify at least some of the other enumerations similarly. Having the enumeration being an enum class prevents certain errors, for example adding two enumerations is valid for plain enum but invalid for enum class.

It seems that using enum is not understood by MinGW and the baremetal job:

It appears both of these are actually GCC 10!

Which it still does, by the way.

I missed the case in asio that triggers the ICE