This is an archive of the discontinued LLVM Phabricator instance.

[clang][Modules] Add -fsystem-module flag
ClosedPublic

Authored by Bigcheese on Feb 28 2020, 5:38 PM.

Details

Summary

The -fsystem-module flag is used when explicitly building a module. It
forces the module to be treated as a system module. This is used when
converting an implicit build to an explicit build to match the
systemness the implicit build would have had for a given module.

Diff Detail

Event Timeline

Bigcheese created this revision.Feb 28 2020, 5:38 PM
bruno added a comment.Mar 2 2020, 1:41 PM

Hi Michael, thanks for improving this.

clang/include/clang/Driver/Options.td
1448

I wonder if -isystem-module wouldn't be better since it's kinda similar with -isystem for headers, but for modules.

clang/lib/Frontend/CompilerInvocation.cpp
1912

What happens when we use this with implicit modules? It will just be ignored? If so, users might think that using -fsystem-module might help them get rid of some warnings/errors, when in fact it won't.

clang/test/Modules/fsystem-module.m
2

Is this really needed given you are only using %t-saved below?

dexonsmith added inline comments.Mar 2 2020, 1:48 PM
clang/include/clang/Driver/Options.td
1448

FWIW, I prefer -fsystem-module. I would expect -i* to be modifying search paths, and this option does not do that.

This is used when
converting an implicit build to an explicit build to match the
systemness the implicit build would have had for a given module.

I had another thought. What if for the explicitly built "system" modules:

  • If -Wsystem-headers is on, leave them as user modules in the explicit build.
  • If -Wsystem-headers is off, turn off all diagnostics in the explicit build.

Does that give the right semantics, or is there something subtly different?

Bigcheese marked 2 inline comments as done.Mar 2 2020, 1:59 PM
Bigcheese added inline comments.
clang/lib/Frontend/CompilerInvocation.cpp
1912

It's an error unless you also pass -emit-module. If you also have implicit modules enabled while explicitly building a module then those modules will be treated as normal, but I don't think there's a huge cause for confusion there. The only way to use it is when explicitly building a module, so it's clear which module it applies to.

clang/test/Modules/fsystem-module.m
2

It's not, that's a leftover from the test I based this one on. I'll clean it up.

This is used when
converting an implicit build to an explicit build to match the
systemness the implicit build would have had for a given module.

I had another thought. What if for the explicitly built "system" modules:

  • If -Wsystem-headers is on, leave them as user modules in the explicit build.
  • If -Wsystem-headers is off, turn off all diagnostics in the explicit build.

Does that give the right semantics, or is there something subtly different?

I considered this, but decided against it because I wanted the implicit and explicit builds to be as similar as possible, and reduce the amount of changes made to the original command line. There's a lot of code in Clang dealing with system files, and I'm not 100% sure that -Wno-everything would be equivalent.

This is used when
converting an implicit build to an explicit build to match the
systemness the implicit build would have had for a given module.

I had another thought. What if for the explicitly built "system" modules:

  • If -Wsystem-headers is on, leave them as user modules in the explicit build.
  • If -Wsystem-headers is off, turn off all diagnostics in the explicit build.

Does that give the right semantics, or is there something subtly different?

I considered this, but decided against it because I wanted the implicit and explicit builds to be as similar as possible, and reduce the amount of changes made to the original command line. There's a lot of code in Clang dealing with system files, and I'm not 100% sure that -Wno-everything would be equivalent.

Okay, SGTM.

Bigcheese updated this revision to Diff 247755.Mar 2 2020, 4:27 PM

Cleaned up the test to not reference unused paths.

Bigcheese marked an inline comment as done.Mar 2 2020, 4:28 PM
bruno accepted this revision.Mar 3 2020, 8:46 AM

LGTM

This revision is now accepted and ready to land.Mar 3 2020, 8:46 AM
This revision was automatically updated to reflect the committed changes.