cyndyishida 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.
--- > Nifty! I haven't seen this used, will need to read up on it. 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) > My assumption was that they would just fall back to regular non-module > textual inclusion. But if there are cases that then break without the module > map, then yes, that's not a very good tradeoff either. You're right, but textual inclusion can be and has been source-breaking. My hunch is that it's even less likely than it is for folks to be using `-fcxx-modules` and run into source compatibility issues just with your modulemaps being respected. > But for the new module map syntax, that happens during Qt build time, at > which point we don't know which Clang version the consumer is using. Oh, I see, that makes sense. > What about a new flag that doesn't hide the module itself, so the module list > is stable between consumers, but prevents implicit use via #include > <QtCore/qstring.h>, while still allowing explicit use via @import QtCore;? I'm not too concerned about Qt specifically, I'm more concerned about introducing or exacerbating the problems or footguns that occur when the compiler attributes the same declarations/identifiers to different producers. It's primarily when those decls are (de)serialized, when every decl is tied to a module. With this suggestion, what happens when both show up transitively in a single client? It is possible that a Swift module exposes declarations from a Clang module, and that Clang module allows resolving other Clang modules through it. If there exists a trivial compiler option to _easily_ selectively manipulate what modules to respect, it can be used liberally in ways that cause downstream headaches. 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. https://github.com/llvm/llvm-project/pull/208191 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
