[PATCH] D25916: Modules: emit an error instead of a random crash (or a misleading error) due to use-after-free.

[Manman Ren via cfe-commits]

manmanren added a comment.

In https://reviews.llvm.org/D25916#594844, @benlangmuir wrote:

> > Does it mean that a system module should only import system modules? If a system module is allowed to import non-system modules, for a non-system module, we will validate diagnostic options differently depending on whether a system module or a non-system module imports it. This will cause a non-system module that was validated earlier to be invalidated by a child thread.
>
> It seems like we should validate the options the same way regardless of what the importer is, but I'm guessing this was done for a reason... What's the behaviour of a user-header imported by a system header (without modules)?  If the user header warnings show up even without -Wsystem-headers, then we should be okay validating, right?


I tried a simple example:
cat test.mm 
#include "a.h"
cat Inputs/System/a.h 
#include "b.h"
cat Inputs/b.h 
void double_declarator1(int *_Nonnull *); // expected-warning{{pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified)}}

clang -cc1 -fsyntax-only -fblocks -I Inputs/ -isystem Inputs/System/ test.mm
--> has no warning
~/llvm_gmail/debug/bin/clang -cc1 -fsyntax-only -fblocks -I Inputs/ -isystem Inputs/System/ test.mm -Wsystem-headers
--> has one warning

Without modules, the user header warnings do not show up if it is included by a system header (without -Wsystem-headers). To exactly match this behavior, user modules need to be validated considering the importing context. We will need to change the code snippets I mentioned earlier to re-validate the options when the importing context changes.

Thanks,
Manman


https://reviews.llvm.org/D25916