You can work around this problem with the following patch:

diff --git a/src/emu/emucore.h b/src/emu/emucore.h
index d87ea5ca3af..54660e54776 100644
--- a/src/emu/emucore.h
+++ b/src/emu/emucore.h
@@ -232,12 +232,12 @@ public:
        emu_fatalerror(int _exitcode, util::format_argument_pack<char> const &args);

        template <typename Format, typename... Params>
-       emu_fatalerror(Format &&fmt, Params &&... args)
+       explicit emu_fatalerror(Format &&fmt, Params &&... args)
                : emu_fatalerror(static_cast<util::format_argument_pack<char> const &>(util::make_format_argument_pack(std::forward<Format>(fmt), std::forward<Params>(args)...)))
        {
        }
        template <typename Format, typename... Params>
-       emu_fatalerror(int _exitcode, Format &&fmt, Params &&... args)
+       explicit emu_fatalerror(int _exitcode, Format &&fmt, Params &&... args)
                : emu_fatalerror(_exitcode, static_cast<util::format_argument_pack<char> const &>(util::make_format_argument_pack(std::forward<Format>(fmt), std::forward<Params>(args)...)))
        {
        }

I think this issue is caused by the different/non-standard Microsoft std::exception class, and the change should be harmless for non-MSVC builds, but I have not proposed upstreaming it yet.

The C++ compiler included with Visual Studio 2022 has serious regressions in overload resolution.

In this case, it is incorrectly selecting the template constructor rather than the implicitly-declared copy constructor. For better or worse, implicitly declared copy constructors are a fundamental feature of C++, and failure to support them correctly is a serious compiler bug.

Attempting a complete MAME build with Visual Studio 2022 results in numerous errors due to bugs in the C++ compiler’s overload resolution logic. See issue #10488 for more examples. This is a serious enough compiler regression that it simply isn’t worthwhile to attempt to support building MAME with Visual Studio 2022. Microsoft needs to fix their compiler, or give up and switch to using clang exclusively.

The C++ compiler included with Visual Studio 2022 has serious regressions in overload resolution.

In this case, it is incorrectly selecting the template constructor rather than the implicitly-declared copy constructor. For better or worse, implicitly declared copy constructors are a fundamental feature of C++, and failure to support them correctly is a serious compiler bug.

Attempting a complete MAME build with Visual Studio 2022 results in numerous errors due to bugs in the C++ compiler’s overload resolution logic. See issue #10488 for more examples. This is a serious enough compiler regression that it simply isn’t worthwhile to attempt to support building MAME with Visual Studio 2022. Microsoft needs to fix their compiler, or give up and switch to using clang exclusively.

Thanks for your reply. I submitted a bug to MSVC to confirm.

You can work around this problem with the following patch:

diff --git a/src/emu/emucore.h b/src/emu/emucore.h
index d87ea5ca3af..54660e54776 100644
--- a/src/emu/emucore.h
+++ b/src/emu/emucore.h
@@ -232,12 +232,12 @@ public:
        emu_fatalerror(int _exitcode, util::format_argument_pack<char> const &args);

        template <typename Format, typename... Params>
-       emu_fatalerror(Format &&fmt, Params &&... args)
+       explicit emu_fatalerror(Format &&fmt, Params &&... args)
                : emu_fatalerror(static_cast<util::format_argument_pack<char> const &>(util::make_format_argument_pack(std::forward<Format>(fmt), std::forward<Params>(args)...)))
        {
        }
        template <typename Format, typename... Params>
-       emu_fatalerror(int _exitcode, Format &&fmt, Params &&... args)
+       explicit emu_fatalerror(int _exitcode, Format &&fmt, Params &&... args)
                : emu_fatalerror(_exitcode, static_cast<util::format_argument_pack<char> const &>(util::make_format_argument_pack(std::forward<Format>(fmt), std::forward<Params>(args)...)))
        {
        }

I think this issue is caused by the different/non-standard Microsoft std::exception class, and the change should be harmless for non-MSVC builds, but I have not proposed upstreaming it yet.

Thanks for your quickly reply, I tried your patch, it worked, thank you~

Thanks for your reply. I submitted a bug to MSVC to confirm.

Can you share the link to the bug report, for future reference ?

Thanks for your reply. I submitted a bug to MSVC to confirm.

Can you share the link to the bug report, for future reference ?

What a pity, it is an internal bug item, can't be accessed with external website. I will synchronize progress in time.

Hi, sorry for the long turnaround but I am a MSVC dev and investigated this issue. This is not an overload resolution bug, in fact all compilers will choose the templated constructor when copying an instance of this type (e.g. when throwing) as it is a better candidate than the usual copy constructor. All compilers will also elide that copy whenever possible, though, so it usually is not visible. You can provoke the same error from gcc or clang to see the same overload resolution result by forcing a copy, e.g. by catching an instance of this type by value or actually copying an instance in a way that can't be elided. The templated function could be constrained to avoid this situation if you expect the type to be copyable (and non-copyable types cannot conformingly be thrown).

The reason for the error with MSVC is because it uses a different exception handling implementation strategy from gcc/clang. MSVC requires the function to be used to copy an exception to be available at runtime and so will instantiate it always as the exception handling runtime may need to call the function to make a copy lazily; gcc and clang will always use a heap allocation at the throw site instead of a potential runtime copy and only instantiate the copy function if it is known to be needed at compile time.

Hi, when I compile by vs2019-clang , the same errors reported..
and I can't fix it by " explicit emu_fatalerror(Format &&fmt, Params &&... args)".
who know how to fix finally

That's irrelevant to what's being discussed here, @backrock. This is about using the actual MSVC compiler.