Fix system_code default argument in error_from_exception

[BillyONeal]

This cast is necessary to build on Visual Studio 2026 18.6.0 / MSVC 19.51 when llfio[status-code] is turned on

C:\Dev\vcpkg2\buildtrees\llfio\src\20260506-b0cb791d93.clean\include\llfio\v2.0\status_code.hpp(401,79): error C2440: 'default argument': cannot convert from 'system_error2::errc' to 'system_error2::system_code'
                     SYSTEM_ERROR2_NAMESPACE::system_code not_matched = errc::resource_unavailable_try_again) noexcept
                                                                              ^
C:\Dev\vcpkg2\buildtrees\llfio\src\20260506-b0cb791d93.clean\include\llfio\v2.0\status_code.hpp(401,79): note: No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called

I'm not sure exactly why the implicit conversion isn't working on the default argument here :/

[ned14]

Y'know, if it's only MSVC barfing here, and MSVC until just now was happy, chances are this is a regression in latest MSVC right?

[BillyONeal]

I don't know enough about changes in the spec, changes to MSVC, whether this code was exposed to MSVC before at all, etc. I'm just trying to update vcpkg's build lab without breaking our ability to test this port. ( microsoft/vcpkg#51854 )

If you believe the change isn't incorrect but believe that it is a compiler regression, would you view rejecting it here but accepting the patch in vcpkg as a workaround for that compiler acceptable?

[BillyONeal]

FWIW part of the reason I tried this is that it seems like it would be strange for errc::anything to be directly convertible to a system_code. Which constructor are you expecting to get selected?

[ned14]

The MSVC CI is at https://github.com/ned14/llfio/actions/runs/25467721710/job/74724624804. As you can see, vs2022 is happy. Status code has been working on MSVC since its very beginning eight years too.

FWIW part of the reason I tried this is that it seems like it would be strange for errc::anything to be directly convertible to a system_code. Which constructor are you expecting to get selected?

Not at all, status code was intended by WG21 to be a complete superset replacement for error_code. So errc (and note, that's a library local errc not std::errc) absolutely implicitly converts into a system code. It'll take the constructor enabled by the ADL customisation point make_status_code() for errc.

I don't know enough about changes in the spec, changes to MSVC, whether this code was exposed to MSVC before at all, etc. I'm just trying to update vcpkg's build lab without breaking our ability to test this port. ( microsoft/vcpkg#51854 )

If you believe the change isn't incorrect but believe that it is a compiler regression, would you view rejecting it here but accepting the patch in vcpkg as a workaround for that compiler acceptable?

I'd like to be conclusively convinced what's going on here first. I say this due to an abundance of caution: WG21 changed C++ 23 in a way which broke this existing mature codebase on a recent update to clang, see #172. So it's entirely possible that WG21 is at fault here, and MSVC isn't at fault here. I'd like to know which first.

Also, there were some recent changes to how the ADL customisation point there was looked up. See ned14/status-code@b337c22 for a workaround to fix AppleClang being broken for recursive ADL lookup, for example.

What I can tell you Billy is that everything works on VS2022 and probably as far back as VS2019. Can you confirm it's working for you for VS2022 first, if it is but VS2026 isn't that would be a useful data point.

It's nearly 3am for me here - advantage of long term unemployment is I can stay up late when I want now - but I am also going to bed now. Good to hear from you again though Billy.

[BillyONeal]

What I can tell you Billy is that everything works on VS2022 and probably as far back as VS2019. Can you confirm it's working for you for VS2022 first, if it is but VS2026 isn't that would be a useful data point.

I believe it does work in 2022 based on https://dev.azure.com/vcpkg/public/_build/results?buildId=131921

Installing 1645/2746 llfio[core,run-tests,status-code]:x64-windows@2026-05-06...
llfio[core,run-tests,status-code]:x64-windows@2026-05-06 package ABI: e78a6e36fb31d98d653928aa617da6b46b60edcdd11ea0aff56904e5f19ae941
Building llfio[core,run-tests,status-code]:x64-windows@2026-05-06...
Trying to download ned14-llfio-20260506.tar.gz using asset cache https://vcpkgassetcachewus.blob.core.windows.net/cache/d565298a7709a34482977406a7290cf109d44a428eb96c1ab788ceb8529ee4aa5736a8db9f51b0aeedb90c54bea00615038d24d0b26336aa6959fc11b8835ff6?*** SECRET ***
Download successful! Asset cache hit, did not try authoritative source https://github.com/ned14/llfio/archive/20260506.tar.gz
-- Extracting source D:/downloads/ned14-llfio-20260506.tar.gz
-- Using source at D:/b/llfio/src/20260506-b0cb791d93.clean
Trying to download ned14-ntkernel-error-category-5e50ff9af36a029c8ead9e0a833aa78304e95f28.tar.gz using asset cache https://vcpkgassetcachewus.blob.core.windows.net/cache/a3b8bfba8b22c79913ced23358c4a5ec56d2f2f8ca8da3ebd2e7cfaa783363d92d9de1b49766756c7b008114eee31c1509195232adcc364446eae724489be930?*** SECRET ***
Download successful! Asset cache hit, did not try authoritative source https://github.com/ned14/ntkernel-error-category/archive/5e50ff9af36a029c8ead9e0a833aa78304e95f28.tar.gz
-- Extracting source D:/downloads/ned14-ntkernel-error-category-5e50ff9af36a029c8ead9e0a833aa78304e95f28.tar.gz
-- Using source at D:/b/llfio/src/8304e95f28-00db124661.clean
Trying to download ned14-wg14_signals-36d3cdb66993078c8fecba93e2a5f2c549572d64.tar.gz using asset cache https://vcpkgassetcachewus.blob.core.windows.net/cache/096d8a539fc09635ca4ea11907244eef06d856719dd5fb4a1f07264c1b1896e6bfe6754af164435adbb57462c03779b90fdb12e284c9855a1d22274d53345fee?*** SECRET ***
Download successful! Asset cache hit, did not try authoritative source https://github.com/ned14/wg14_signals/archive/36d3cdb66993078c8fecba93e2a5f2c549572d64.tar.gz
-- Extracting source D:/downloads/ned14-wg14_signals-36d3cdb66993078c8fecba93e2a5f2c549572d64.tar.gz
-- Using source at D:/b/llfio/src/c549572d64-434848070e.clean
-- Configuring x64-windows
-- Building x64-windows-dbg
-- Building x64-windows-rel
-- Building x64-windows-dbg
-- Building x64-windows-rel
-- Installing: D:/p/llfio_x64-windows/share/llfio/usage
-- Installing: D:/p/llfio_x64-windows/share/llfio/copyright
-- Performing post-build validation
Starting submission of llfio[core,run-tests,status-code]:x64-windows@2026-05-06 to 1 binary cache(s) in the background
Elapsed time to handle llfio:x64-windows: 2.7 min

It's nearly 3am for me here - advantage of long term unemployment is I can stay up late when I want now - but I am also going to bed now. Good to hear from you again though Billy.

Ooof I'm sorry to hear about that :( . Don't feel like you have to stay up late on my account! Good to hear from you again too.

[ned14]

What I can tell you Billy is that everything works on VS2022 and probably as far back as VS2019. Can you confirm it's working for you for VS2022 first, if it is but VS2026 isn't that would be a useful data point.

I believe it does work in 2022 based on https://dev.azure.com/vcpkg/public/_build/results?buildId=131921

I went ahead and added vs2026 to LLFIO CI, and I have reproed your issue. The identical commit works just fine in vs2022. See https://github.com/ned14/llfio/actions/runs/26345005922.

If it works in vs2022, but not in vs2026, the most likely cause is that there is a regression in vs2026 in the area of concept enabled constructors by recursive ADL lookup. Here is what should happen:

1. This constructor in system_code should be invoked: https://github.com/ned14/status-code/blob/master/include/status-code/status_code.hpp#L742
2. It is enabled by looking up the ADL customisation point make_status_code(errc) which if available AND returns a status code AND status_code is constructible with the tag _nonerased_to_erased_tag and the result type of the ADL customisation point.

I would suggest your next step is try compiling everything using SYSTEM_ERROR2_DISABLE_CONCEPTS_SUPPORT=1 and see if the MSVC regression is within its concepts implementation or within its ADL lookup machinery.

If it works using SFINAE and not with Concepts, my proposed fix is that status_code stops using Concepts if on VS2026 or later and reverts to SFINAE. That work for you?

It's nearly 3am for me here - advantage of long term unemployment is I can stay up late when I want now - but I am also going to bed now. Good to hear from you again though Billy.

Ooof I'm sorry to hear about that :( . Don't feel like you have to stay up late on my account! Good to hear from you again too.

Yeah, thanks. Lots of people we know have been unemployed for similar periods of time to me. I guess we're getting aged out of the industry. A shame.

Niall

[ned14]

Billy did you see the same link problem reported above by the other bit of Microsoft? Apparently status code fails to link on arm64ec on MSVC?

[ned14]

@BillyONeal I just built LLFIO in VS2026 18.6.2 and it builds just fine.

You were 18.6.0 right?

Edit: There are lots of these warnings produced:

2>C:\Users\ned\Documents\boostish\outcome\include\outcome\experimental\status-code\include\status-code\errored_status_code.hpp(182,1): warning C4717: 'system_error2::errored_status_code<system_error2::detail::erased<llfio_v2_8b098e91::detail::file_io_error_value_type<__int64> > >::errored_status_code<system_error2::detail::erased<llfio_v2_8b098e91::detail::file_io_error_value_type<__int64> > ><system_error2::status_code<llfio_v2_8b098e91::file_io_error_domain<system_error2::_win32_code_domain> >,system_error2::errored_status_code<system_error2::detail::erased<__int64> > >': recursive on all control paths, function will cause runtime stack overflow

If you look at that code, there is absolutely no way that code recurses. And, it doesn't on all the other compilers, including VS2022.

It would appear that VS2026 goes ahead and emits runtime to recurse calling that function infinitely, thus generating the stack overflow it warned about.

I'd say your compiler team has some work to do there.

[PhoebeHui]

C:\Dev\vcpkg2\buildtrees\llfio\src\20260506-b0cb791d93.clean\include\llfio\v2.0\status_code.hpp(401,79): error C2440: 'default argument': cannot convert from 'system_error2::errc' to 'system_error2::system_code'
SYSTEM_ERROR2_NAMESPACE::system_code not_matched = errc::resource_unavailable_try_again) noexcept
^
C:\Dev\vcpkg2\buildtrees\llfio\src\20260506-b0cb791d93.clean\include\llfio\v2.0\status_code.hpp(401,79): note: No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called

Hi @ned14, I can reproduce above error, I reported a bug to msvc dev team as well, I will let you about the status.

This is a different repo with outcome, right? the related issue looks link error LNK2019 from outcome repo, it only occurs on arm64ec platform, and it's clean on x64/x86 platform.