Swift version 4.2-dev (LLVM 3c04b0ea85, Clang 197a5d4e3b, Swift db75a67)
Additional Detail from JIRA
When the -Xfrontend -serialize-debugging-options flag is passed to the compiler, it causes import search paths, framework search paths, and ClangImporter options to be written into the .swiftmodule files, so that LLDB can read them for debugging purposes.
However, these values, if present, are also unconditionally loaded by the compiler during normal compilation actions, and thus they have effects there as well (see ModuleFile.cpp).
Thus, it is possible to construct swiftc invocations that succeed or fail depending solely on whether debug options are serialized or not.
All the code that serializes these paths and ClangImporter options seems to indicate that they are intended to be used for debugging only, so I believe that one way to fix this would be to add a flag of some sort to ASTContext that indicates whether debug options should be loaded; lldb would set it and the compiler would omit it.
As far as I can tell, fixing this should be a safe, non-breaking change; it would only have the potential to break people who never build with debugging turned off and who don't pass correct import search paths to the compiler in all cases. However, if I comment out the lines in ModuleFile.cpp that I linked to above, I see that 5 of the compiler's tests fail. I'm digging into it more, but I believe these tests are making incorrect assumptions about the search paths and that fixing them is the correct course of action.
STEPS TO REPRODUCE
1. Download the attached zip file.
2. Run ./build.sh and observe that the build fails with the error "missing required module 'ModuleA'"
3. Run ./build.sh -Xfrontend -serialize-debugging-options and observe that the build succeeds.
4. Add -I nested to the compile options for compiling ModuleC.swift and run ./build.sh without additional arguments; observe that the build succeeds.
The text was updated successfully, but these errors were encountered:
I haven't opened the PR yet because I imagine most of you are quite busy this week 🙂 I'm looking forward to your insight—my fear is that someone might be relying on this behavior for non-debug builds (which is why I'm surprised that the behavior of -serialize-debugging-options isn't just tied to the presence of a -g group flag), or that there are other unintended consequences.