Skip to content

[libc++] Fix C++23 standard modules when using with clang-cl on Windows #148992

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 0 additions & 4 deletions libcxx/include/__new/new_handler.h
Original file line number Diff line number Diff line change
Expand Up @@ -15,14 +15,10 @@
# pragma GCC system_header
#endif

#if defined(_LIBCPP_ABI_VCRUNTIME)
# include <new.h>
#else
Comment on lines -18 to -20
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we split this into a separate patch? This doesn't seem to be directly related to modules.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is, because <new> does not define get_new_handler() and that stops standard modules from building, the change was requested by @frederick-vs-ja to simplify the previous solution.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also fixes other tests IIUC, so this isn't specific to modules. It just happens to surface with modules as well.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also fixes other tests IIUC, so this isn't specific to modules. It just happens to surface with modules as well.

Without some fixes, this PR will not solve the actual problem even if it gets merged it will be broken, spliting them into different PRs would just complicate the problem even more and kick the can down the road in my opinion.

If you can list what should be broken apart from this PR I will look into it.

The only test that is currently fixed is this bf7ca14 because it is failing early on the basis of "Doesn't work on Windows" and that is no longer needed, and that seems to be on a par with what this PR tries to fix.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyway, can we create another PR for get_new_handler and then proceed in this PR?

Copy link
Author

@siradam7th siradam7th Jul 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyway, can we create another PR for get_new_handler and then proceed in this PR?

Sure, I'll open a new PR that has the changes of the last two commits that fix get_new_handler and reference this PR.
#150182

_LIBCPP_BEGIN_UNVERSIONED_NAMESPACE_STD
typedef void (*new_handler)();
_LIBCPP_EXPORTED_FROM_ABI new_handler set_new_handler(new_handler) _NOEXCEPT;
_LIBCPP_EXPORTED_FROM_ABI new_handler get_new_handler() _NOEXCEPT;
_LIBCPP_END_UNVERSIONED_NAMESPACE_STD
#endif // _LIBCPP_ABI_VCRUNTIME

#endif // _LIBCPP___NEW_NEW_HANDLER_H
46 changes: 44 additions & 2 deletions libcxx/modules/std.compat/ctime.inc
Original file line number Diff line number Diff line change
Expand Up @@ -14,15 +14,57 @@ export {

using ::timespec _LIBCPP_USING_IF_EXISTS;
using ::tm _LIBCPP_USING_IF_EXISTS;

using ::asctime _LIBCPP_USING_IF_EXISTS;
using ::clock _LIBCPP_USING_IF_EXISTS;
using ::strftime _LIBCPP_USING_IF_EXISTS;

#ifndef _LIBCPP_ABI_VCRUNTIME
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you simply leaving these functions missing when using UCRT?

Also, it seem that we should modify this line libcxx/utils/libcxx/test/features.py to enable the tests:

or ("_WIN32" in compilerMacros(cfg) and not _mingwSupportsModules(cfg))

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm looking into it, however it seems that moving the definition '_BUILD_STD_MODULE' triggered some other weird errors, I'll do more testing tomorrow and see...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha, these lines should be removed. Now get_new_handler.pass.cpp should always pass.

// FIXME: When libc++ is linked against vcruntime (i.e. the default config in
// MSVC mode), the declarations of std::set_new_handler and std::get_new_handler
// are provided by vcruntime/UCRT's new.h. However, that header actually only
// declares set_new_handler - it's missing a declaration of get_new_handler.
// XFAIL: msvc && stdlib=libc++

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like just defining the macro is not enough, I have resorted to defining the actual functions as inline, I'll push the changes once I made sure that everything works with both std and std.compact.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The _LIBCPP_USING_IF_EXISTS attribute is intended to make things work when the declarations are not available, and avoid precisely these #ifdef blocks. What's the issue here?

Copy link
Contributor

@frederick-vs-ja frederick-vs-ja Jul 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue on these <ctime> functions is that UCRT incorrectly adds static to them, so we can't directly export them. At this time we might simply skip export for them to make the standard modules buildable. MSVC STL chooses to reimplement them in the std namespace as a workaround.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, it seem that we should modify this line libcxx/utils/libcxx/test/features.py to enable the tests:

or ("_WIN32" in compilerMacros(cfg) and not _mingwSupportsModules(cfg))

Is just removing that line enough?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we can try this:

or ("_WIN32" in compilerMacros(cfg) and "__MINGW32__" in compilerMacros(cfg) and not _mingwSupportsModules(cfg))

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not familiar with how the tests are run/generated yet, I'll see...

using ::ctime _LIBCPP_USING_IF_EXISTS;
using ::difftime _LIBCPP_USING_IF_EXISTS;
using ::gmtime _LIBCPP_USING_IF_EXISTS;
using ::localtime _LIBCPP_USING_IF_EXISTS;
using ::mktime _LIBCPP_USING_IF_EXISTS;
using ::strftime _LIBCPP_USING_IF_EXISTS;
using ::time _LIBCPP_USING_IF_EXISTS;
using ::timespec_get _LIBCPP_USING_IF_EXISTS;
#endif

// A workaround for UCRT because it defines these functions
// as static and that causes the error "internal linkage cannot be exported"
#ifdef _LIBCPP_ABI_VCRUNTIME

template <int = 0>
inline char* __CRTDECL ctime(_In_ time_t const* const _Time) noexcept {
return _ctime64(_Time);
}

template <int = 0>
inline double __CRTDECL difftime(_In_ time_t const _Time1, _In_ time_t const _Time2) noexcept {
return _difftime64(_Time1, _Time2);
}

template <int = 0>
inline tm* __CRTDECL gmtime(_In_ time_t const* const _Time) noexcept {
return _gmtime64(_Time);
}

template <int = 0>
inline tm* __CRTDECL localtime(_In_ time_t const* const _Time) noexcept {
return _localtime64(_Time);
}

template <int = 0>
inline time_t __CRTDECL mktime(_Inout_ tm* const _Tm) noexcept {
return _mktime64(_Tm);
}

template <int = 0>
inline time_t __CRTDECL time(_Out_opt_ time_t* const _Time) noexcept {
return _time64(_Time);
}

template <int = 0>
inline int __CRTDECL timespec_get(_Out_ timespec* const _Ts, _In_ int const _Base) noexcept {
return _timespec64_get(reinterpret_cast<_timespec64*>(_Ts), _Base);
}
#endif
Comment on lines +31 to +69
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really don't like this. It makes us clearly non-conforming and working around an issue that is trivial to fix.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see how it is trivial? even MSVC's STL has the same workaround because there has been no changes in UCRT in the past years, because of those few functions modules cannot be compiled.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see how it is trivial?

The fix in UCRT would be very trivial. UCRT team can just remove static on these functions in less than one minute, as UCRT expects the __inline extension to behave same as inline in C++.

The crux is that nobody in the UCRT team seems to be able to work on this, and contribution from open source community is still impossible.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The crux is that nobody in the UCRT team seems to be able to work on this, and contribution from open source community is still impossible.

This is one of the main reasons for the existance of this PR, if they would've done it, they at least would have done it for MSVC's sake, but here we are...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is not a good reason to add a comparatively complex and fragile workaround, but a reason to complain to them to get their asses moving. I don't know what Microsoft's reasons are, but so far this is a very clear "we don't care" and not "we can't" to me. I have no interest in supporting anybodys "we don't care".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, but IMO we should at least to skip export of these functions to build standard modules.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is definitely more palatable. I'm not sure I'd approve it; I'll have to think about that a bit more I think.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, but IMO we should at least to skip export of these functions to build standard modules.

I don't think that is a good idea, since users are discoraged from defining functions in the std namespace, and not having those function would mean missing base functionality that is expected (for libraries too), we are not talking about missing new C++ features, its libc functionality.

It's not a perfect solution, but it is what MSVC has been doing from the start, and if the change is made in UCRT (which hasn't happened for quite some time now, since ~2023), it could all be removed at that time, but that does not mean we have to wait a couple years or never to start using C++ standard modules on Windows.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that is a good idea, since users are discoraged from defining functions in the std namespace, and not having those function would mean missing base functionality that is expected (for libraries too), we are not talking about missing new C++ features, its libc functionality.

You can still #include the corresponding header as a workaround. It's not like you have to not use modules because of this.

It's not a perfect solution, but it is what MSVC has been doing from the start, and if the change is made in UCRT (which hasn't happened for quite some time now, since ~2023), it could all be removed at that time, but that does not mean we have to wait a couple years or never to start using C++ standard modules on Windows.

I don't think "look, Microsoft works around their own bugs as well" is a particularly good argument. They really can't refuse to work around trivial to fix bugs.

} // export
45 changes: 44 additions & 1 deletion libcxx/modules/std/ctime.inc
Original file line number Diff line number Diff line change
Expand Up @@ -17,12 +17,55 @@ export namespace std {

using std::asctime _LIBCPP_USING_IF_EXISTS;
using std::clock _LIBCPP_USING_IF_EXISTS;
using std::strftime _LIBCPP_USING_IF_EXISTS;

#ifndef _LIBCPP_ABI_VCRUNTIME
using std::ctime _LIBCPP_USING_IF_EXISTS;
using std::difftime _LIBCPP_USING_IF_EXISTS;
using std::gmtime _LIBCPP_USING_IF_EXISTS;
using std::localtime _LIBCPP_USING_IF_EXISTS;
using std::mktime _LIBCPP_USING_IF_EXISTS;
using std::strftime _LIBCPP_USING_IF_EXISTS;
using std::time _LIBCPP_USING_IF_EXISTS;
using std::timespec_get _LIBCPP_USING_IF_EXISTS;
#endif

// A workaround for UCRT because it defines these functions
// as static and that causes the error "internal linkage cannot be exported"
#ifdef _LIBCPP_ABI_VCRUNTIME

template <int = 0>
inline char* __CRTDECL ctime(_In_ time_t const* const _Time) noexcept {
return _ctime64(_Time);
}

template <int = 0>
inline double __CRTDECL difftime(_In_ time_t const _Time1, _In_ time_t const _Time2) noexcept {
return _difftime64(_Time1, _Time2);
}

template <int = 0>
inline tm* __CRTDECL gmtime(_In_ time_t const* const _Time) noexcept {
return _gmtime64(_Time);
}

template <int = 0>
inline tm* __CRTDECL localtime(_In_ time_t const* const _Time) noexcept {
return _localtime64(_Time);
}

template <int = 0>
inline time_t __CRTDECL mktime(_Inout_ tm* const _Tm) noexcept {
return _mktime64(_Tm);
}

template <int = 0>
inline time_t __CRTDECL time(_Out_opt_ time_t* const _Time) noexcept {
return _time64(_Time);
}

template <int = 0>
inline int __CRTDECL timespec_get(_Out_ timespec* const _Ts, _In_ int const _Base) noexcept {
return _timespec64_get(reinterpret_cast<_timespec64*>(_Ts), _Base);
}
#endif
} // namespace std
4 changes: 1 addition & 3 deletions libcxx/src/new_handler.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -11,9 +11,7 @@
#include "include/atomic_support.h"

#if defined(_LIBCPP_ABI_MICROSOFT)
# if !defined(_LIBCPP_ABI_VCRUNTIME)
# define _LIBPCPP_DEFINE_NEW_HANDLER
# endif
# define _LIBPCPP_DEFINE_NEW_HANDLER
#elif defined(LIBCXX_BUILDING_LIBCXXABI)
// nothing to do, we use the one from libc++abi
#elif defined(LIBCXXRT)
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -8,12 +8,6 @@

// test get_new_handler

// FIXME: When libc++ is linked against vcruntime (i.e. the default config in
// MSVC mode), the declarations of std::set_new_handler and std::get_new_handler
// are provided by vcruntime/UCRT's new.h. However, that header actually only
// declares set_new_handler - it's missing a declaration of get_new_handler.

// XFAIL: msvc && stdlib=libc++

#include <new>
#include <cassert>
Expand Down
13 changes: 11 additions & 2 deletions libcxx/utils/generate_libcxx_cppm_in.py
Original file line number Diff line number Diff line change
Expand Up @@ -9,11 +9,19 @@
import os.path
import sys

from libcxx.header_information import module_c_headers, module_headers, header_restrictions, headers_not_available, libcxx_root
from libcxx.header_information import (
module_c_headers,
module_headers,
header_restrictions,
headers_not_available,
libcxx_root,
)


def write_file(module):
with open(libcxx_root / "modules" / f"{module}.cppm.in", "w") as module_cpp_in:
with open(
libcxx_root / "modules" / f"{module}.cppm.in", "w", encoding="utf-8"
) as module_cpp_in:
module_cpp_in.write(
"""\
// -*- C++ -*-
Expand All @@ -25,6 +33,7 @@ def write_file(module):
//
//===----------------------------------------------------------------------===//


// WARNING, this entire header is generated by
// utils/generate_libcxx_cppm_in.py
// DO NOT MODIFY!
Expand Down
Loading