clang-cl no longer able to interpret (slightly outdated) microsoft headers

[memory-thrasher]

#include <filesystem>

int main(int argc, char** argv) {
  return argc;
}

$ clang-cl -DWIN32 --target=x86_64-pc-windows-msvc -fuse-ld=lld /winsdkdir /home/sid/clones/xwin/splat/sdk /vctoolsdir /home/sid/clones/xwin/splat/crt -I/home/sid/clones/xwin/external/include /MT /O2 /std:c++20 -Diswindows -c selfdep.cpp -o selfdep.o -fms-compatibility
In file included from selfdep.cpp:1:
In file included from /home/sid/clones/xwin/splat/crt/include/filesystem:15:
/home/sid/clones/xwin/splat/crt/include/chrono(1998,18): error: satisfaction of constraint 'three_way_comparable_with<sys_seconds, sys_time<_Duration> >' depends on itself
 1998 |         requires three_way_comparable_with<sys_seconds, sys_time<_Duration>>
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/sid/clones/xwin/splat/crt/include/chrono(1998,18): note: while substituting template arguments into constraint expression here
 1998 |         requires three_way_comparable_with<sys_seconds, sys_time<_Duration>>
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/sid/clones/xwin/splat/crt/include/concepts(223,11): note: while checking constraint satisfaction for template 'operator<=><std::chrono::duration<long long>>' required here
  223 |     { __t <  __u } -> _Boolean_testable;
      |           ^
/home/sid/clones/xwin/splat/crt/include/concepts(223,11): note: while substituting deduced template arguments into function template 'operator<=>' [with _Duration = std::chrono::duration<long long>]
/home/sid/clones/xwin/splat/crt/include/concepts(223,7): note: in instantiation of requirement here
  223 |     { __t <  __u } -> _Boolean_testable;
      |       ^~~~~~~~~~
/home/sid/clones/xwin/splat/crt/include/concepts(222,25): note: while substituting template arguments into constraint expression here
  222 | concept _Half_ordered = requires(const remove_reference_t<_Ty1>& __t, const remove_reference_t<_Ty2>& __u) {
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  223 |     { __t <  __u } -> _Boolean_testable;
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  224 |     { __t >  __u } -> _Boolean_testable;
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  225 |     { __t <= __u } -> _Boolean_testable;
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  226 |     { __t >= __u } -> _Boolean_testable;
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  227 | };
      | ~
/home/sid/clones/xwin/splat/crt/include/compare(298,71): note: (skipping 3 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all)
  298 | concept three_way_comparable = _Half_equality_comparable<_Ty, _Ty> && _Half_ordered<_Ty, _Ty>
      |                                                                       ^
/home/sid/clones/xwin/splat/crt/include/compare(305,5): note: while substituting template arguments into constraint expression here
  305 |     three_way_comparable<_Ty1, _Cat> && three_way_comparable<_Ty2, _Cat>
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/sid/clones/xwin/splat/crt/include/chrono(1998,18): note: while checking the satisfaction of concept 'three_way_comparable_with<std::chrono::time_point<std::chrono::system_clock, std::chrono::duration<long long>>, std::chrono::time_point<std::chrono::system_clock, std::chrono::duration<long long>>, std::partial_ordering>' requested here
 1998 |         requires three_way_comparable_with<sys_seconds, sys_time<_Duration>>
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/sid/clones/xwin/splat/crt/include/chrono(1998,18): note: while substituting template arguments into constraint expression here
 1998 |         requires three_way_comparable_with<sys_seconds, sys_time<_Duration>>
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/sid/clones/xwin/splat/crt/include/chrono(2004,29): note: while checking constraint satisfaction for template 'operator<=><std::chrono::duration<long long>>' required here
 2004 |         return _Left.date() <=> _Right.date();
      |                             ^~~
/home/sid/clones/xwin/splat/crt/include/chrono(2004,29): note: while substituting deduced template arguments into function template 'operator<=>' [with _Duration = std::chrono::duration<long long>]
[trimmed, only showing first error but there are plenty more like that one]

Cross-compiling from linux x64 to windows x64 using xwin splat.
Compiled locally from main, commit a8f3eba (current). Works when using commit 74fcb6a (July 2024). I'm running a bisect but that will take a while (compiling llvm takes 1+ hours on my box).

[frederick-vs-ja]

I possibly have fixed this in microsoft/STL#4902. See also #102857 and #104713. Could you update MSVC STL headers to see whether this bug still exists?

[memory-thrasher]

Could you update MSVC STL headers to see whether this bug still exists?

I'm not using STL (afaik), I'm using xwin to automagically download the windows sdk, extract the headers, and fix casing therein. I just refreshed that process, and the test case did succeed.

However, I hesitate to call this "problem solved". IMHO, newer compilers should support old source files. Backwards compatibility is one of the main reasons I prefer C++. Granted, the MS headers have never been valid C/C++. Still, when targeting windows, there is potential that someone would want to use an older windows sdk (I know people still using 2008 server, and many more using win 10 desktop), and I would not want to require them to use an older version of the compiler.

I suggest enhancing the -fms-compatibility flag to disable this new check to support these (currently only slightly) outdated MS headers.

e: for clarity

[jyknight]

See also discussion on #54440. I don't think we'd add such behavior only in -fms-compatibility, but potentially it's possible to fix this in general.

[memory-thrasher]

I can't say I fully understand the issue here, especially how the self-dependent concept could ever have been compiled, conformance aside. That said, given that such an implementation obviously exists in multiple compilers, I am all in favor of allowing it, only if that can be accomplished in conformance. I hesitate to advocate for allowing non-conformant code to pass by default, without some kind of invocation flag giving the compiler permission to deviate. That is the trail head of the path that ruined the likes of JavaScript. If there are cases other than MS headers that bring up this issue, I might suggest reducing that error to a warning. Then those of us running -Wall -Werror have the option to either silence it with an explicit -Wno-cyclic-concept or similar, or to update the problematic concept code.

[zyn0217]

@cor3ntin What are we going to do for the cyclic dependency issue facilitated by dr2369? Should we demote errors to warnings for system headers? Or we just give users an option to opt out?

[memory-thrasher]

It is not up to me; this post is my opinion. That said, I don't like the idea of handling "system headers" differently from other headers. My use case is cross compiling, which makes the windows "system headers" look a lot like third-party headers. Someone who understands the standard better than I will have to rule on whether the cyclic concept is conformant. If it is, then obviously there should be no warning at all. If it is not conformant, I advocate for keeping it as an error, but allowing it to be disabled with a (new or existing) feature (-fxxx) or other cli flag, so users are informed and advised to, but not forced to, take action to fix the code, or update the headers to a fixed version. It seems to me that every case where this happens in system headers (msvc, glibc, libc++) has been fixed in newer version of the headers themselves. However, it seems likely to me that updating the headers might cause compatibility issues with a user's target platform. I do not think that targeting an outdated OS should require using an outdated compiler. To be clear, I do not want users who update their compiler to be forced to update their headers (which might cascade into updating other aspects of their toolchain or project), but I do want them to be aware of the nonconformance of their code, and to explicitly give the compiler permission to use the nonconformant code, because I strongly believe that nonconformant code should not compile successfully and quietly by default.

TL;DR I want it to be an error but I want a cli flag to turn it off.

[zyn0217]

I reapplied the implementation yesterday and I think this should have been worked around. Feel free to reopen the issue if the problem persists.