[Explicit Module Builds] Add 'ClangImporter' setting for explicitly-built modules #65869
Conversation
|
We do not really want to support Swift explicit modules combined with Clang implicit modules, so these things should always be in-tandem. This will then allow us to no longer require compiler clients to specify clang flags explicitly: |
|
@swift-ci test |
artemcm
force-pushed
the
ClangImporterExplicitBuildOptions
branch
from
7dfe832 to
0b54845
Compare
|
@swift-ci test |
| @@ -1460,6 +1460,9 @@ static bool ParseClangImporterArgs(ClangImporterOptions &Opts, | |||
| Opts.PCHDisableValidation |= Args.hasArg(OPT_pch_disable_validation); | |||
| } | |||
|
|
|||
| if (FrontendOpts.DisableImplicitModules) | |||
There was a problem hiding this comment.
This is an important change, it essentially prohibits implicit loading of Clang modules when Swift explicit module loading is enabled. It is not clear why such a combination would be useful, and it is not something we intend to validate, so may as well make it not possible.
|
@swift-ci test Windows platform |
…uilt modules This will mean that '-disable-implicit-swift-modules' also automatically implies two things: 1. Clang modules must also be explicit, and the importer's clang instance will get '-fno-implicit-modules' and '-fno-implicit-module-maps' 2. The importer's clang instance will no longer get a '-fmodules-cache-path=', since it is not needed in explicit builds
artemcm
force-pushed
the
ClangImporterExplicitBuildOptions
branch
from
0b54845 to
e2ea6cb
Compare
|
@swift-ci test |
This will mean that
-disable-implicit-swift-moduleswhen specified toswift-frontendalso automatically implies two things:-fno-implicit-modulesand-fno-implicit-module-maps.-fmodules-cache-path=, since it is not needed in explicit builds.