rnk added a comment. In D61646#1495778 <https://reviews.llvm.org/D61646#1495778>, @phosek wrote:
> This change broke our build which is using Clang and the > `x86_64-windows-msvc` target to cross-compile our EFI bootloader. Now the > compilation fails > <https://logs.chromium.org/logs/fuchsia/buildbucket/cr-buildbucket.appspot.com/8913996720033157664/+/steps/build/0/steps/build_fuchsia/0/steps/ninja/0/steps/zircon/0/stdout> > because it cannot find Windows headers (as expected). We're probably going > to work around the issue by setting `-U_MSC_VER`, but I'm going to start a > discussion whether we should maybe define a new target for EFI. We could fix forward by conditionalizing this under __has_include or something like that, but I think there's enough reasons to say that perhaps we don't want to do this after all. I'll go ahead and revert this and we can discuss it more. In D61646#1495597 <https://reviews.llvm.org/D61646#1495597>, @mikerice wrote: > For the most part, these headers are going to be included in almost every > compilation unit anyway since they will come in through other C/C++ library > headers. So this would presumably affect only a small numbers of compilation > units that only include stddef.h and none of the others. This is true, and it's part of why I figured we should approve this. However, the fact that users actually encounter these issues suggests that there are actually files in the wild that only use stddef.h, so avoiding including sal.h for them might be worthwhile. > It’s been our experience that if a user has code that compiles fine with > their current compiler, and it doesn’t compile with the new compiler, they > just won’t use the new compiler. Many don’t really care that it would work > fine if they added #includes where needed. So changes like this can really > improve compiler uptake. I guess it is a trade-off between helping users > easily moving their code to clang or a possible small compile time > improvement. That's certainly the case, but even considering clang's approach to GCC compatibility, we've always drawn the line somewhere around "system headers". We're willing to make changes to clang to accommodate code that the user cannot change: code from OS SDKs, glibc, Windows SDK, STL, etc, but we usually assume that the user is willing to put in some effort to make their code clang-compatible. Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61646/new/ https://reviews.llvm.org/D61646 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
