================
@@ -131,13 +138,65 @@ def parseScript(test, preamble):
script += preamble
script += scriptInTest
+ has_std_module = False
+ has_std_compat_module = False
+ for module in modules:
+ if module == "std":
+ has_std_module = True
+ elif module == "std.compat":
+ has_std_compat_module = True
+ else:
+ script.insert(
+ 0,
+ f"echo \"The module '{module}' is not valid, use 'std' or
'std.compat'\"",
+ )
+ script.insert(1, "false")
+ return script
+
+ if modules:
+ # This flag is needed for both modules.
+ moduleCompileFlags.append("-fprebuilt-module-path=%T")
----------------
ChuanqiXu9 wrote:
I didn't read the patch completely so I don't know the concatenated command
line. But the behavior matches current expectation of clang. Now when clang
sees an `import` for a named module, clang will only find that named module by
`-fprebuilt-module-path` or
`-fmodule-file=<module-name>=<path-to-the-module-file>`.
I guess you're talking about the case about:
```
clang++ std.compat.pcm use.cc -o use
```
where use.cc uses std.compat module.
This command line will be split into 3 processes like:
```
clang_cc1 std.compat.pcm -c -o std.compat.o
clang_cc1 use.cc -c -o use.o
clang_cc1 std.compat.o use.o -o use
```
So the second step won't know about `std.compat.pcm`.
While it is technically possible to improve that, I feel it is not so useful
since the major expected users of modules should use a build system instead of
concatenating the command line manually.
https://github.com/llvm/llvm-project/pull/76246
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
