torarnv wrote: > All of these approaches are really band-aids, and clients should be able to > respect modulemaps vendored by a library without problems, but also > acknowledge that it can cause undesirable issues for clients. Using a > workaround seems fine for staging, but long term, the solution is really to > work with any clients of `-fcxx-modules -fmodules` to rectify any issues they > might run into, which could be nothing.
I think we're on the same page 🙂 I do wish I could enable them Qt-wide, and use that as a signal to get feedback on any issues triggered by `-fcxx-modules` in either our module maps or upstream in Clang. But with the end goal here being _Swift_ consumption of Qt, I want to make it as palpable as possible for Qt to accept the module maps as a default, which warrants being conservative on the C++ facing effects. > I don't think we have great docs, but lots of examples as test cases under > `clang/test/Modules/`. I also attached a Claude-based example that directly > shows how a modulemap is masked out. You could instead pass a vfsoverlay that > includes the modulemap and only pass that to swift clients. > [vfsrepro.zip](https://github.com/user-attachments/files/29821686/vfsrepro.zip) Thanks! 🙌🏻 I believe I can shoehorn something using this, and also use CMake genexes to only enable it if the consumer has `-fcxx-modules` in their build flags, so it won't pollute most consumers of C++ Qt. > You're right, but textual inclusion can be and has been source-breaking. My > hunch is that it's even less likely in your case than it is for folks to be > using `-fcxx-modules` and run into source compatibility issues just with your > modulemaps being respected. Ah, I see. So your gut feeling is (to clarify): * Consumers of Qt with `-fcxx-modules` are unlikely, so we could potentially expose the module maps and hope for the best * If we force consumers into a text inclusion path, that might in theory be source breaking for their existing Clang module use, but that's even less likely that the above point, so if we can't find a Qt-specific text-inclusion path via the VFS layer then `-fno-implicit-module-map-file` is a better option than silently picking up Qt module maps with `-fcxx-modules` ? > FWIW, there is an argument that vfsoverlays can introduce the same class of > issues, but they are niche enough and somewhat non-trivial to set up that it > hasn't been a problem at scale. Make sense. Adding another flag or mechanism would compound this problem, so if we can solve it with the existing VFS machinery we're at least not making things worse for Clang upstream. https://github.com/llvm/llvm-project/pull/208191 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
