Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

@llvm/pr-subscribers-clang

Author: Matt (matts1)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 372a95c80717c..bcd5df2f2edc0 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -295,6 +295,7 @@ Bug Fixes to C++ Support
 - Clang no longer crashes when a coroutine is declared ``[[noreturn]]``. (#GH127327)
 - Clang now uses the parameter location for abbreviated function templates in ``extern "C"``. (#GH46386)
 - Clang now correctly parses ``if constexpr`` expressions in immediate function context. (#GH123524)
+- Clang modules now allow a module and its user to have a larger variety of configurations.
 
 Improvements to C++ diagnostics
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/clang/include/clang/Basic/LangOptions.def b/clang/include/clang/Basic/LangOptions.def
index 383440ddbc0ea..beefc944959a1 100644
--- a/clang/include/clang/Basic/LangOptions.def
+++ b/clang/include/clang/Basic/LangOptions.def
@@ -139,9 +139,9 @@ ENUM_LANGOPT(AltivecSrcCompat, AltivecSrcCompatKind, 2,
 LANGOPT(ConvergentFunctions, 1, 1, "Assume convergent functions")
 LANGOPT(AltiVec           , 1, 0, "AltiVec-style vector initializers")
 LANGOPT(ZVector           , 1, 0, "System z vector extensions")
-LANGOPT(Exceptions        , 1, 0, "exception handling")
-LANGOPT(ObjCExceptions    , 1, 0, "Objective-C exceptions")
-LANGOPT(CXXExceptions     , 1, 0, "C++ exceptions")
+COMPATIBLE_LANGOPT(Exceptions        , 1, 0, "exception handling")
+COMPATIBLE_LANGOPT(ObjCExceptions    , 1, 0, "Objective-C exceptions")
+COMPATIBLE_LANGOPT(CXXExceptions     , 1, 0, "C++ exceptions")
 LANGOPT(EHAsynch          , 1, 0, "C/C++ EH Asynch exceptions")
 ENUM_LANGOPT(ExceptionHandling, ExceptionHandlingKind, 3,
              ExceptionHandlingKind::None, "exception handling")
@@ -149,8 +149,8 @@ LANGOPT(IgnoreExceptions  , 1, 0, "ignore exceptions")
 LANGOPT(ExternCNoUnwind   , 1, 0, "Assume extern C functions don't unwind")
 LANGOPT(AssumeNothrowExceptionDtor , 1, 0, "Assume exception object's destructor is nothrow")
 LANGOPT(TraditionalCPP    , 1, 0, "traditional CPP emulation")
-LANGOPT(RTTI              , 1, 1, "run-time type information")
-LANGOPT(RTTIData          , 1, 1, "emit run-time type information data")
+BENIGN_LANGOPT(RTTI              , 1, 1, "run-time type information")
+BENIGN_LANGOPT(RTTIData          , 1, 1, "emit run-time type information data")
 LANGOPT(MSBitfields       , 1, 0, "Microsoft-compatible structure layout")
 LANGOPT(MSVolatile        , 1, 0, "Microsoft-compatible volatile loads and stores")
 LANGOPT(Freestanding, 1, 0, "freestanding implementation")
@@ -397,13 +397,13 @@ BENIGN_ENUM_LANGOPT(ExternDeclNoDLLStorageClassVisibility, VisibilityFromDLLStor
 BENIGN_LANGOPT(SemanticInterposition        , 1, 0, "semantic interposition")
 BENIGN_LANGOPT(HalfNoSemanticInterposition, 1, 0,
                "Like -fno-semantic-interposition but don't use local aliases")
-ENUM_LANGOPT(StackProtector, StackProtectorMode, 2, SSPOff,
+BENIGN_ENUM_LANGOPT(StackProtector, StackProtectorMode, 2, SSPOff,
              "stack protector mode")
-ENUM_LANGOPT(TrivialAutoVarInit, TrivialAutoVarInitKind, 2, TrivialAutoVarInitKind::Uninitialized,
+BENIGN_ENUM_LANGOPT(TrivialAutoVarInit, TrivialAutoVarInitKind, 2, TrivialAutoVarInitKind::Uninitialized,
              "trivial automatic variable initialization")
-VALUE_LANGOPT(TrivialAutoVarInitStopAfter, 32, 0,
+BENIGN_VALUE_LANGOPT(TrivialAutoVarInitStopAfter, 32, 0,
              "stop trivial automatic variable initialization after the specified number of instances. Must be greater than 0.")
-VALUE_LANGOPT(TrivialAutoVarInitMaxSize, 32, 0,
+BENIGN_VALUE_LANGOPT(TrivialAutoVarInitMaxSize, 32, 0,
              "stop trivial automatic variable initialization if var size exceeds the specified size (in bytes). Must be greater than 0.")
 ENUM_LANGOPT(SignedOverflowBehavior, SignedOverflowBehaviorTy, 2, SOB_Undefined,
              "signed integer overflow handling")

Thanks for the review, what you said makes sense. This is extremely important for us that we can get this to work though, so I was wondering if there was some way we could work around it. I'll use the rtti flag for all future examples.

Firstly, to check that I understand correctly, essentially the only thing that compiling a PCH file does is to generate an AST and export some symbols, so literally the only thing that compiling a module with -frtti vs -fno-rtti would do is that one the former would parse with __cpp_rtti defined.

So from what I can tell, you would end up with the following compilation steps:

clang++ ... -o mod_a.pcm
clang++ ... -fmodule-file mod_a.pcm -o mod_b.pcm
clang++ -fmodule-file mod_a.pcm -fmodule_file mod_b.pcm -o <binary/object file>

The first and second's -frtti would decide whether the macro was enabled in their specific parts of the AST, and the third's -frtti would determine whether to actually enable RTTI in the codegen.

I believe it's extremely justified to disallow a module compiled with RTTI to depend on one without (and vice versa), by default. However, I'm currently trying to understand if there's a specific harm from allowing this when you have the -Wno-module-file-config-mismatch. It seems to work just fine in our chromium repo when compiling a bunch of stuff with no exceptions that depends upon the standard library built with exceptions (though I haven't gotten to running the code yet).

For now I've removed everything but the TrivialAuto*

Could you update issue description too?

The issue is that if we allow the preprocessor's state to differ across modules, then the resulting compiled units can be arbitrary (and subtly incompatible).

I wonder if a possible solution is to record which macros are used (ie, are expanded or appear in #ifdef / defined)
And ONLY serialize the set of macros that are used.
That way, if your program never uses __SSP__, for example, then your module would not be incompatible just because SPP has been defined.

I think that's worth pondering a bit more @Bigcheese

The general issue with changing this to benign is that it ends up being non-deterministic and buggy for implicitly built modules. I think what we want here is COMPATIBLE_LANGOPT. By default it will still feed into the context hash, but the compiler won't reject loading such modules. If Chrome plans to use explicitly built modules then this is fine.

There are quite a few options we could change to compatible, but the big issues is in making sure that Clang won't crash when we do that. I think for RTTI it's fine as that should only impact the predefine and codegen, not the shape of the AST. Sadly we have no good way to test this in general, just on a case by case basis when we hit issues.

@Bigcheese marking just Trivial var init benign seems fine to me, right?

ping, I've just re-resolved the release notes conflicts

The issue is that if we allow the preprocessor's state to differ across modules, then the resulting compiled units can be arbitrary (and subtly incompatible).

I wonder if a possible solution is to record which macros are used (ie, are expanded or appear in #ifdef / defined) And ONLY serialize the set of macros that are used. That way, if your program never uses __SSP__, for example, then your module would not be incompatible just because SPP has been defined.

IIUC, you're saying that codegen options that create macros are benign when they are never read. This statement seems correct and would probably be a good optimization, however it won't solve all use cases.

In our use case, for example, we want our code built without exceptions to depend upon libc++ built with exceptions. As libc++ reads __cpp_exceptions, this won't work. I think that the correct thing to do would be to, similarly to other options which only affect a single macro, turn it into a compatible langopt, with a future potential optimization that if the macro is never read it can be turned into a benign langopt.

What do you think @cor3ntin? I understand that potential subtle compatibility issues might be a concern for you, but I think there does need to be a way to achieve this. If you feel concerned, we could lock it behind a compiler flag, or an experimental compiler flag to see if there's any subtle issues before enabling it for everyone, or whatever you think would make you comfortable with doing this.

I think one option would be to allow differences in macros, and rely on the ODR checker to catch when that would cause problems.

I think this looks fine but I'd like @Bigcheese @erichkeane @AaronBallman to look at it too.

I think this looks fine but I'd like @Bigcheese @erichkeane @AaronBallman to look at it too.

This looks fine as far as I can tell. Though, I'm not sure I have sufficient knowledge to be comfortable enough with the implications to approve this. @Bigcheese and @ChuanqiXu9 might be the most knowledgeable.

Better to update description of this PR to state only about trivial var init flags?