[all-commits] [llvm/llvm-project] 0e1e1f: Reland Print library module manifest path again (...

Chuanqi Xu via All-commits all-commits at lists.llvm.org
Sun Mar 17 06:15:15 PDT 2024


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 0e1e1fc8f0eae6ebdce40ef2154aa90e35e5bed7
      https://github.com/llvm/llvm-project/commit/0e1e1fc8f0eae6ebdce40ef2154aa90e35e5bed7
  Author: Chuanqi Xu <yedeng.yd at linux.alibaba.com>
  Date:   2024-03-17 (Sun, 17 Mar 2024)

  Changed paths:
    M clang/include/clang/Driver/Driver.h
    M clang/include/clang/Driver/Options.td
    M clang/lib/Driver/Driver.cpp
    A clang/test/Driver/modules-print-library-module-manifest-path.cpp

  Log Message:
  -----------
  Reland Print library module manifest path again  (#84881)

Following of https://github.com/llvm/llvm-project/pull/82160

The reason why the above PR fails is that the `--sysroot` has lower
priority than the libc++ built from the same source. On the one hand, it
matches the codes behavior. We will add the built libc++ project paths
in the ToolChain class. But we will only add the path related to sysroot
in Linux class, which is derived from the ToolChain classes. So the
paths of just built libc++ is in the front of the paths relative to
sysroot. On the other hand, the behavior should be good from the higher
level. Since the just built libc++ has the same version number with the
just built clang, so it makes sense that these 2 compilers just matches.

So for patch it self, I hacked it by using resource dir in the test
since the resource dir has the higher priority, which is not strongly
correct since we won't do that in practice.

@kaz7 would you like to test on your environment to avoid this get
reverted again?

On the libc++ side, it shows that it lacks a `modules.json` file for the
just built libc++ directory. If we don't have that, it will be
problematic to use std modules from the just built clang and libc++
pair. Then it is not good. And I feel it may be problematic for future
compiler/standard library developers. So I feel this is somewhat a
libc++ issue that need to be fixed.

Also if we don't like the hacked test in the current patch, we must wait
for libc++ to fix this to proceed. But I feel this is somewhat odd since
the test of clang shouldn't dependent on libc++.

CC: @mordante

---------

Co-authored-by: Mark de Wever <koraq at xs4all.nl>



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications


More information about the All-commits mailing list