[clang] [clang][Modules] Complete the implementation of P2615: Meaningful exports (PR #194201)

[Yihan Wang via cfe-commits]

================
@@ -3,9 +3,135 @@
 
 
 // RUN: %clang_cc1 -std=c++20 -verify -fsyntax-only %t/A.cpp
+// RUN: %clang_cc1 -std=c++20 -verify -fsyntax-only %t/B.cpp
+// RUN: not %clang_cc1 -std=c++20 -fsyntax-only -fdiagnostics-parseable-fixits %t/B.cpp 2>&1 | FileCheck %t/B.cpp
+// RUN: %clang_cc1 -std=c++20 -verify -fsyntax-only %t/msvc-stl-exception-1.cpp
----------------
yronglin wrote:

> That's factually true, but I don't see how it leads to the conclusion that we should check `-fms-extensions` in addition to `_MSVC_STL_UPDATE`. Checking for `-fms-extensions` is strictly more complexity, so something must justify adding that complexity. But I don't see what justifies it. Does checking `_MSVC_STL_UPDATE` but not `-fms-extensions` do the wrong thing under some circumstances?

Hmm, looking up a macro in the preprocessor's macro table on every check isn't free — it's noticeably more expensive than a single bit test. Doing it unconditionally means libc++ and libstdc++ users pay that cost on every relevant code path, even though the check is only meaningful for the MSVC STL.

IIUC, gating on `LangOpts.MicrosoftExt` instead doesn't add any real complexity here — it's literally a flag bit on `LangOpts` that's already populated and used in plenty of similar places. So we get the same behavior for the cases we care about without imposing overhead on the majority of users who aren't on MSVC.

https://github.com/llvm/llvm-project/pull/194201