cyndyishida wrote: > This lets a project ship a standard-named module.modulemap for consumers that > opt in to modules (e.g. Swift's ClangImporter, which relies on implicit > discovery) while preventing unrelated C++ consumers from implicitly > modularizing the same headers.
It would be helpful to understand the real-world use case where enabling this option is desirable. Would you have a build log and scenario available? Following the thread to the GitHub issue, it seems like the initial problem was having multiple search paths into the same headers. Is that still the relevant use case? > Qt generally (historically) passes both -I$INSTALL_PATH/include and > -I$INSTALL_PATH/include/QtFoo (for each Qt module the project depends on, > e.g. QtCore, QtGui, etc), to enable both the #include <QtCore/qfoo.h> and > #include <qfoo.h> forms. And both forms are widely used by user projects, as > well as Qt internally. The complexity this PR's approach potentially introduces is once swift module compilations (lets say swift module A and B) start encoding dependencies to clang modules but have different entry points because they may be using a different set of `-fno-implicit-module-map-file` flags, but depend on the same underlying declarations, the downstream client (that imports both A and B) needs to reason about it and could run into the similar or even more complex issues where its even more difficult to map back where the mismatch is formed from. If the symptom always shows up as a `redefinition error` of the same declarations (and even source locations), we've been thinking about a pathway where the compiler can be more lax in cases where it can prove the repeated declarations are infact the same. Would that approach apply to your usecase? https://github.com/llvm/llvm-project/pull/208191 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
