jansvoboda11 wrote: > > multi-project workspace builds cannot avoid hitting this kind of issue > > (demonstrated by the test) and they are left with a build error they cannot > > fix. > > Is this because a multi-project workspace results in separate build-products > directories but a single module cache? IOW, a single build session should > never depend on a module with the same name but derived from different search > paths?
They use single build products directory and the same module cache with the same context hash (at least under Swift EBM). > > Note that this slows down scans by ~7.5% > > Do you know where the added overhead comes from, or why lazy modulemap > parsing would avoid some of it? Is it caused by the need to rebuild the chain > of modules that were invalidated? That comes from extra module map parsing and loading. Lazy module map loading would avoid some of it, yes. This number is for the case where we do not need to rebuild the chain of modules - that will likely see more significant slowdown. I talked with @Bigcheese and @benlangmuir at length about this issue and my takeaway is that this patch just papers over the build system issues and slows down scans of projects that are configured correctly. I think a better solution would be to make it so that the scan of each project uses a separate context hash, which removes the "unfixable by developers" aspect of this issue. That would essentially reduce this issue to the one we already know about where within a single project build, we may first see module defined by the SDK module map and then by the module map in the build directory, which is easily fixable by each individual project. https://github.com/llvm/llvm-project/pull/133827 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
