[PATCH] D145214: [TSAN] add support for riscv64

2023-10-06 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

Hi,

I believe you forgot to add `tsan_rtl_riscv64.S` to your patch when you land 
it. We are seeing build errors on our bots with following messages:

  -- Configuring done (12.3s)
  CMake Error at 
/b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/cmake/Modules/AddCompilerRT.cmake:357
 (add_library):
Cannot find source file:
  
  tsan_rtl_riscv64.S
  Call Stack (most recent call first):
/b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/lib/tsan/rtl/CMakeLists.txt:244 
(add_compiler_rt_runtime)
  
  
  CMake Error at 
/b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/cmake/Modules/AddCompilerRT.cmake:357
 (add_library):
No SOURCES given to target: clang_rt.tsan-riscv64
  Call Stack (most recent call first):
/b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/lib/tsan/rtl/CMakeLists.txt:244 
(add_compiler_rt_runtime)
  
  
  CMake Error at 
/b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/cmake/Modules/AddCompilerRT.cmake:357
 (add_library):
No SOURCES given to target: clang_rt.tsan-dynamic-riscv64
  Call Stack (most recent call first):
/b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/lib/tsan/rtl/CMakeLists.txt:268 
(add_compiler_rt_runtime)
  
  
  CMake Generate step failed.  Build files cannot be regenerated correctly.
  [5508/5672](1) Completed 'runtimes-i386-unknown-linux-gnu'
  FAILED: 
runtimes/runtimes-riscv64-unknown-linux-gnu-stamps/runtimes-riscv64-unknown-linux-gnu-configure
 
/b/s/w/ir/x/w/llvm_build/runtimes/runtimes-riscv64-unknown-linux-gnu-stamps/runtimes-riscv64-unknown-linux-gnu-configure
 
  cd /b/s/w/ir/x/w/llvm_build/runtimes/runtimes-riscv64-unknown-linux-gnu-bins 
&& 
/b/s/w/ir/x/w/cipd_tool/fuchsia/third_party/cmake/72c014f0086372a2bab7ed771e2ed942d6122d94331d19c95566bb25d2f962ff/bin/cmake
 --no-warn-unused-cli -DCMAKE_C_COMPILER=/b/s/w/ir/x/w/llvm_build/./bin/clang 
-DCMAKE_CXX_COMPILER=/b/s/w/ir/x/w/llvm_build/./bin/clang++ 
-DCMAKE_ASM_COMPILER=/b/s/w/ir/x/w/llvm_build/./bin/clang 
-DCMAKE_LINKER=/b/s/w/ir/x/w/llvm_build/./bin/ld.lld 
-DCMAKE_AR=/b/s/w/ir/x/w/llvm_build/./bin/llvm-ar 
-DCMAKE_RANLIB=/b/s/w/ir/x/w/llvm_build/./bin/llvm-ranlib 
-DCMAKE_NM=/b/s/w/ir/x/w/llvm_build/./bin/llvm-nm 
-DCMAKE_OBJDUMP=/b/s/w/ir/x/w/llvm_build/./bin/llvm-objdump 
-DCMAKE_OBJCOPY=/b/s/w/ir/x/w/llvm_build/./bin/llvm-objcopy 
-DCMAKE_STRIP=/b/s/w/ir/x/w/llvm_build/./bin/llvm-strip 
-DCMAKE_READELF=/b/s/w/ir/x/w/llvm_build/./bin/llvm-readelf 
-DCMAKE_C_COMPILER_TARGET=riscv64-unknown-linux-gnu 
-DCMAKE_CXX_COMPILER_TARGET=riscv64-unknown-linux-gnu 
-DCMAKE_ASM_COMPILER_TARGET=riscv64-unknown-linux-gnu -DCMAKE_INSTALL_PREFIX= 
-DCMAKE_SYSROOT=/b/s/w/ir/x/w/cipd/linux 
-DLLVM_BINARY_DIR=/b/s/w/ir/x/w/llvm_build 
-DLLVM_CONFIG_PATH=/b/s/w/ir/x/w/llvm_build/bin/llvm-config 
-DLLVM_ENABLE_WERROR=OFF -DLLVM_HOST_TRIPLE=x86_64-unknown-linux-gnu 
-DLLVM_HAVE_LINK_VERSION_SCRIPT=1 -DLLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO=OFF 
-DLLVM_USE_RELATIVE_PATHS_IN_FILES=ON "-DLLVM_LIT_ARGS=--resultdb-output=r.j 
-v" -DLLVM_SOURCE_PREFIX= -DPACKAGE_VERSION=18.0.0git 
-DCMAKE_BUILD_TYPE=Release 
-DCMAKE_MAKE_PROGRAM=/b/s/w/ir/x/w/cipd_tool/fuchsia/third_party/ninja/476febc43233af3534d14a045651a4f365106e894b0998df28fa241d68733c8d/ninja
 -DCMAKE_EXPORT_COMPILE_COMMANDS=1 -DCOMPILER_RT_BUILD_BUILTINS=OFF 
-DLLVM_INCLUDE_TESTS=ON -DLLVM_ENABLE_PROJECTS_USED=ON 
-DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON -DCMAKE_C_COMPILER_WORKS=ON 
-DCMAKE_CXX_COMPILER_WORKS=ON -DCMAKE_ASM_COMPILER_WORKS=ON 
-DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON 
-DLLVM_RUNTIMES_TARGET=riscv64-unknown-linux-gnu -DHAVE_LLVM_LIT=ON 
-DLLVM_DEFAULT_TARGET_TRIPLE=riscv64-unknown-linux-gnu 
"-DLLVM_ENABLE_RUNTIMES=compiler-rt;libcxx;libcxxabi;libunwind" 
-DLLVM_USE_LINKER=lld -DCMAKE_ASM_FLAGS=--target=riscv64-unknown-linux-gnu 
-DCMAKE_BUILD_TYPE=RelWithDebInfo 
-DCMAKE_CXX_FLAGS=--target=riscv64-unknown-linux-gnu 
-DCMAKE_C_FLAGS=--target=riscv64-unknown-linux-gnu 
-DCMAKE_EXE_LINKER_FLAGS=-fuse-ld=lld -DCMAKE_MODULE_LINKER_FLAGS=-fuse-ld=lld 
-DCMAKE_SHARED_LINKER_FLAGS=-fuse-ld=lld 
-DCMAKE_SYSROOT=/b/s/w/ir/x/w/cipd/focal -DCMAKE_SYSTEM_NAME=Linux 
-DCOMPILER_RT_BUILD_STANDALONE_LIBATOMIC=ON -DCOMPILER_RT_CAN_EXECUTE_TESTS=ON 
-DCOMPILER_RT_CXX_LIBRARY=libcxx -DCOMPILER_RT_USE_BUILTINS_LIBRARY=ON 
-DCOMPILER_RT_USE_LLVM_UNWINDER=ON -DLIBCXXABI_ENABLE_SHARED=OFF 
-DLIBCXXABI_INSTALL_LIBRARY=OFF -DLIBCXXABI_USE_COMPILER_RT=ON 
-DLIBCXXABI_USE_LLVM_UNWINDER=ON -DLIBCXX_ABI_VERSION=2 
-DLIBCXX_ENABLE_SHARED=OFF -DLIBCXX_ENABLE_STATIC_ABI_LIBRARY=ON 
-DLIBCXX_USE_COMPILER_RT=ON -DLIBUNWIND_ENABLE_SHARED=OFF 
-DLIBUNWIND_USE_COMPILER_RT=ON -DLLVM_ENABLE_ASSERTIONS=OFF 
"-DLLVM_ENABLE_RUNTIMES=compiler-rt;libcxx;libcxxabi;libunwind" 
-DLLVM_TOOLS_DIR=/b/s/w/ir/x/w/llvm_build/bin -DSANITIZER_CXX_ABI=libc++ 
-DSANITIZER_CXX_ABI_INTREE=ON -DSANITIZER_TEST_CXX=libc++ 
-DSANITIZER_TEST_CXX_INTREE=ON -GNinja -S 
/b/s/w/ir/x/w/llvm-llvm-project/llvm/runtimes/../../runtimes -B 
/b/s/w/ir/x/w/llvm_build/runtimes/runtimes-riscv64-unknown-linux-gnu-bins 

[PATCH] D158948: [clang][ASTImporter] Add import of type-related nodes

2023-09-08 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

In D158948#4642475 , @danix800 wrote:

> In D158948#4642422 , @haowei wrote:
>
>> Looking at 
>> https://github.com/llvm/llvm-project/blob/37a20cc68f545647e614c5ba4ae311dc3fd277e9/clang/lib/Testing/CommandLineArgs.cpp#L47,
>>  this is were the unreachable code was hit. Is it the intended behavior?
>>
>> Shall I enable `ImportMatrixType` and disable `ImportOpenCLPipe` tests so we 
>> can update the GoogleTest in LLVM?
>
> I'm not familiar with GoogleTest so I wasn't expecting this to happen.
>
> To enabling `ImportOpenCLPipe` we might use `"-x", "cl", "-cl-no-stdinc", 
> "-cl-std=CL2.0"` here 
> .
>
> See also https://reviews.llvm.org/D158872 for some extra context of both 
> testing with `ImportMatrixType` and `ImportOpenCLPipe`.

In a nutshell, `ImportOpenCLPipe` wasn't enabled after your patch, that is why 
the test failure was unnoticed. You have to add

  INSTANTIATE_TEST_SUITE_P(ParameterizedTests, ImportOpenCLPipe,
   DefaultTestValuesForRunOptions);

in the same namespace like other tests in this file to let it run. I am very 
unfamiliar with Clang AST codebase so sorry I don't really know what changes 
you need to make this test pass. At current state, this test will lead to 
unreachable code error.

https://github.com/llvm/llvm-project/pull/65823 is my attempt to roll 
GoogleTest 1.14.0 to bring some upstream bug fixes and improvements to LLVM. 
Patch 
https://github.com/llvm/llvm-project/pull/65823/commits/ff67955ecbafcf847e11188c44e8dd070899b0b6
 attempts to enable `ImportMatrixType` and explicitly disable 
`ImportOpenCLPipe` so the `check-clang` step can pass under GoogleTest v1.14.0


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158948/new/

https://reviews.llvm.org/D158948

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D158948: [clang][ASTImporter] Add import of type-related nodes

2023-09-08 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

Hi I am working on updating GoogleTest in LLVM to v1.14.0 and during my local 
testing, I noticed that this patch added 2 new tests `ImportMatrixType` and 
`ImportOpenCLPipe` through `TEST_P` calls, however, both tests were not 
instantiated by `INSTANTIATE_TEST_SUITE_P` so they were not ran during 
`check-clang`. This will causes test failures when using GoogleTest v1.14.0 
since it now explicitly fail when an `INSTANTIATE_TEST_SUITE_P` is not paired 
with an `TEST_P` I manually added

  INSTANTIATE_TEST_SUITE_P(ParameterizedTests, ImportMatrixType,
   DefaultTestValuesForRunOptions);
  
  INSTANTIATE_TEST_SUITE_P(ParameterizedTests, ImportOpenCLPipe,
   DefaultTestValuesForRunOptions);

to `ASTImporterTest.cpp` and reran the clang test and it failed with error 
message:

  [ RUN  ] ParameterizedTests/ImportOpenCLPipe.ImportPipeType/0
  Not implemented yet!
  UNREACHABLE executed at clang/lib/Testing/CommandLineArgs.cpp:47!
  Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH 
or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
  0  ASTTests 0x5565e9e71d18
  
  --
  exit: -6
  --

Looking at 
https://github.com/llvm/llvm-project/blob/37a20cc68f545647e614c5ba4ae311dc3fd277e9/clang/lib/Testing/CommandLineArgs.cpp#L47,
 this is were the unreachable code was hit. Is it the intended behavior?

Shall I enable `ImportMatrixType` and disable `ImportOpenCLPipe` tests so we 
can update the GoogleTest in LLVM?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158948/new/

https://reviews.llvm.org/D158948

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D153557: [clang][ExtractAPI] Add support for C++ classes

2023-08-02 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

FYI, this patch fails the Windows bots in a different way. (you can see the 
error triggered in the pre-merge build in 
https://buildkite.com/llvm-project/premerge-checks/builds/161603#018909c4-fe90-4de6-91a3-d251dc5ada8f)

The error message from our builders are:

  Script:
  --
  : 'RUN: at line 1';   rm -rf 
C:\b\s\w\ir\x\w\llvm_build\tools\clang\test\ExtractAPI\Output\class.cpp.tmp
  : 'RUN: at line 2';   split-file 
C:\b\s\w\ir\x\w\llvm-llvm-project\clang\test\ExtractAPI\class.cpp 
C:\b\s\w\ir\x\w\llvm_build\tools\clang\test\ExtractAPI\Output\class.cpp.tmp
  : 'RUN: at line 3';   sed -e 
"s@INPUT_DIR@C:/b/s/w/ir/x/w/llvm_build/tools/clang/test/ExtractAPI/Output/class.cpp.tmp@g"
  
C:\b\s\w\ir\x\w\llvm_build\tools\clang\test\ExtractAPI\Output\class.cpp.tmp/reference.output.json.in
 >> 
C:\b\s\w\ir\x\w\llvm_build\tools\clang\test\ExtractAPI\Output\class.cpp.tmp/reference.output.json
  : 'RUN: at line 5';   c:\b\s\w\ir\x\w\llvm_build\bin\clang.exe++ -extract-api 
-target arm64-apple-macosx -x c++-header  
C:\b\s\w\ir\x\w\llvm_build\tools\clang\test\ExtractAPI\Output\class.cpp.tmp/input.h
 -o 
C:\b\s\w\ir\x\w\llvm_build\tools\clang\test\ExtractAPI\Output\class.cpp.tmp/output.json
 -Xclang -verify
  : 'RUN: at line 9';   sed -e "s@\"generator\": \".*\"@\"generator\": \"?\"@g" 
 
C:\b\s\w\ir\x\w\llvm_build\tools\clang\test\ExtractAPI\Output\class.cpp.tmp/output.json
 >> 
C:\b\s\w\ir\x\w\llvm_build\tools\clang\test\ExtractAPI\Output\class.cpp.tmp/output-normalized.json
  : 'RUN: at line 11';   diff 
C:\b\s\w\ir\x\w\llvm_build\tools\clang\test\ExtractAPI\Output\class.cpp.tmp/reference.output.json
 
C:\b\s\w\ir\x\w\llvm_build\tools\clang\test\ExtractAPI\Output\class.cpp.tmp/output-normalized.json
  --
  Exit Code: 127
  
  Command Output (stdout):
  --
  $ ":" "RUN: at line 1"
  $ "rm" "-rf" 
"C:\b\s\w\ir\x\w\llvm_build\tools\clang\test\ExtractAPI\Output\class.cpp.tmp"
  $ ":" "RUN: at line 2"
  $ "split-file" 
"C:\b\s\w\ir\x\w\llvm-llvm-project\clang\test\ExtractAPI\class.cpp" 
"C:\b\s\w\ir\x\w\llvm_build\tools\clang\test\ExtractAPI\Output\class.cpp.tmp"
  $ ":" "RUN: at line 3"
  $ "sed" "-e" 
"s@INPUT_DIR@C:/b/s/w/ir/x/w/llvm_build/tools/clang/test/ExtractAPI/Output/class.cpp.tmp@g"
 
"C:\b\s\w\ir\x\w\llvm_build\tools\clang\test\ExtractAPI\Output\class.cpp.tmp/reference.output.json.in"
  $ ":" "RUN: at line 5"
  $ "c:\b\s\w\ir\x\w\llvm_build\bin\clang.exe++" "-extract-api" "-target" 
"arm64-apple-macosx" "-x" "c++-header" 
"C:\b\s\w\ir\x\w\llvm_build\tools\clang\test\ExtractAPI\Output\class.cpp.tmp/input.h"
 "-o" 
"C:\b\s\w\ir\x\w\llvm_build\tools\clang\test\ExtractAPI\Output\class.cpp.tmp/output.json"
 "-Xclang" "-verify"
  # command stderr:
  'c:\\b\\s\\w\\ir\\x\\w\\llvm_build\\bin\\clang.exe++': command not found
  error: command failed with exit status: 127
  
  --

Link to the failed task: 
https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-windows-x64/b8773853314698659521/overview

`%clang++` is probably not the correct way to invoke clang++ as it was replaced 
as `clang.exe++` on Windows


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D153557/new/

https://reviews.llvm.org/D153557

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D153557: [clang][ExtractAPI] Add support for C++ classes

2023-08-02 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

Thanks for reverting. I wasn't doing any changes to this when you were asking 
though, but looking at build log, it looks like the assertion error disappeared 
after f4de606ef271fe362f03d30c53a850f9877ec238 
 was 
landed.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D153557/new/

https://reviews.llvm.org/D153557

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D153557: [clang][ExtractAPI] Add support for C++ classes

2023-08-02 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

Hi, we are seeing a test error on `Clang :: 
ExtractAPI/constructor_destructor.cpp` after this patch was landed. Error 
message:

  Script:
  --
  : 'RUN: at line 1';   rm -rf 
/b/s/w/ir/x/w/llvm_build/tools/clang/test/ExtractAPI/Output/constructor_destructor.cpp.tmp
  : 'RUN: at line 2';   split-file 
/b/s/w/ir/x/w/llvm-llvm-project/clang/test/ExtractAPI/constructor_destructor.cpp
 
/b/s/w/ir/x/w/llvm_build/tools/clang/test/ExtractAPI/Output/constructor_destructor.cpp.tmp
  : 'RUN: at line 3';   sed -e 
"s@INPUT_DIR@/b/s/w/ir/x/w/llvm_build/tools/clang/test/ExtractAPI/Output/constructor_destructor.cpp.tmp@g"
  
/b/s/w/ir/x/w/llvm_build/tools/clang/test/ExtractAPI/Output/constructor_destructor.cpp.tmp/reference.output.json.in
 >> 
/b/s/w/ir/x/w/llvm_build/tools/clang/test/ExtractAPI/Output/constructor_destructor.cpp.tmp/reference.output.json
  : 'RUN: at line 5';   /b/s/w/ir/x/w/llvm_build/bin/clang++ -extract-api 
-target arm64-apple-macosx -x c++-header  
/b/s/w/ir/x/w/llvm_build/tools/clang/test/ExtractAPI/Output/constructor_destructor.cpp.tmp/input.h
 -o 
/b/s/w/ir/x/w/llvm_build/tools/clang/test/ExtractAPI/Output/constructor_destructor.cpp.tmp/output.json
 -Xclang -verify
  : 'RUN: at line 9';   sed -e "s@\"generator\": \".*\"@\"generator\": \"?\"@g" 
 
/b/s/w/ir/x/w/llvm_build/tools/clang/test/ExtractAPI/Output/constructor_destructor.cpp.tmp/output.json
 >> 
/b/s/w/ir/x/w/llvm_build/tools/clang/test/ExtractAPI/Output/constructor_destructor.cpp.tmp/output-normalized.json
  : 'RUN: at line 11';   diff 
/b/s/w/ir/x/w/llvm_build/tools/clang/test/ExtractAPI/Output/constructor_destructor.cpp.tmp/reference.output.json
 
/b/s/w/ir/x/w/llvm_build/tools/clang/test/ExtractAPI/Output/constructor_destructor.cpp.tmp/output-normalized.json
  --
  Exit Code: 1
  
  Command Output (stderr):
  --
  clang++: llvm/include/llvm/Support/JSON.h:317: 
llvm::json::Value::Value(std::string): Assertion `false && "Invalid UTF-8 in 
value used as JSON"' failed.
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ 
and include the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.Program arguments: /b/s/w/ir/x/w/llvm_build/bin/clang++ -extract-api 
-target arm64-apple-macosx -x c++-header 
/b/s/w/ir/x/w/llvm_build/tools/clang/test/ExtractAPI/Output/constructor_destructor.cpp.tmp/input.h
 -o 
/b/s/w/ir/x/w/llvm_build/tools/clang/test/ExtractAPI/Output/constructor_destructor.cpp.tmp/output.json
 -Xclang -verify
  #0 0x55a2ec85c458 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
(/b/s/w/ir/x/w/llvm_build/bin/clang+++0x83e5458)
  clang++: error: clang frontend command failed with exit code 134 (use -v to 
see invocation)
  Fuchsia clang version 18.0.0 (https://llvm.googlesource.com/llvm-project 
dad9de0ae5360b18c890985d212bec266bf8c122)
  Target: arm64-apple-macosx
  Thread model: posix
  InstalledDir: /b/s/w/ir/x/w/llvm_build/bin
  clang++: note: diagnostic msg: 
  
  
  PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
  Preprocessed source(s) and associated run script(s) are located at:
  clang++: note: diagnostic msg: /b/s/w/ir/x/t/lit-tmp-0iloyqe3/input-5086dc.hh
  clang++: note: diagnostic msg: /b/s/w/ir/x/t/lit-tmp-0iloyqe3/input-5086dc.sh
  clang++: note: diagnostic msg: 
  
  
  
  --

Link to the builder: 
https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8773854265208228753/overview

It looks like it triggers an assertion error in llvm's JSON library. Could you 
take a look please? If it takes some time to fix, could you revert your change 
please? Thanks.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D153557/new/

https://reviews.llvm.org/D153557

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D155241: [Fuchsia] Skip building debuginfod if httplib_ROOT is not specified

2023-07-13 Thread Haowei Wu via Phabricator via cfe-commits
haowei created this revision.
haowei added reviewers: phosek, mysterymath.
Herald added a subscriber: abrachet.
Herald added a project: All.
haowei requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch skipds building debuginfod if httplib_ROOT is not present in the 
configuration when building Fuchsia Clang toolchain.

I used list(REMOVE_ITEM) instead of list(APPEND) so user can still use 
-DLLVM_TOOLCHAIN_TOOLS to override the tools to build.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D155241

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -331,6 +331,10 @@
   scan-build-py
   CACHE STRING "")
 
+if (NOT httplib_ROOT)
+  list(REMOVE_ITEM LLVM_TOOLCHAIN_TOOLS llvm-debuginfod llvm-debuginfod-find)
+endif()
+
 set(LLVM_Toolchain_DISTRIBUTION_COMPONENTS
   bolt
   clang


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -331,6 +331,10 @@
   scan-build-py
   CACHE STRING "")
 
+if (NOT httplib_ROOT)
+  list(REMOVE_ITEM LLVM_TOOLCHAIN_TOOLS llvm-debuginfod llvm-debuginfod-find)
+endif()
+
 set(LLVM_Toolchain_DISTRIBUTION_COMPONENTS
   bolt
   clang
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D153931: [Fuchsia] Enable libcxx filesystem on Windows build.

2023-06-27 Thread Haowei Wu via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGfa872aa221e2: [Fuchsia] Enable libcxx filesystem on Windows 
build. (authored by haowei).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D153931/new/

https://reviews.llvm.org/D153931

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -119,7 +119,6 @@
   set(RUNTIMES_${target}_CMAKE_SYSTEM_NAME Windows CACHE STRING "")
   set(RUNTIMES_${target}_CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "")
   set(RUNTIMES_${target}_LIBCXX_ABI_VERSION 2 CACHE STRING "")
-  set(RUNTIMES_${target}_LIBCXX_ENABLE_FILESYSTEM OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LIBCXX_ENABLE_ABI_LINKER_SCRIPT OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LIBCXX_ENABLE_SHARED OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE 
STRING "")


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -119,7 +119,6 @@
   set(RUNTIMES_${target}_CMAKE_SYSTEM_NAME Windows CACHE STRING "")
   set(RUNTIMES_${target}_CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "")
   set(RUNTIMES_${target}_LIBCXX_ABI_VERSION 2 CACHE STRING "")
-  set(RUNTIMES_${target}_LIBCXX_ENABLE_FILESYSTEM OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LIBCXX_ENABLE_ABI_LINKER_SCRIPT OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LIBCXX_ENABLE_SHARED OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE STRING "")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D153931: [Fuchsia] Enable libcxx filesystem on Windows build.

2023-06-27 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 535194.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D153931/new/

https://reviews.llvm.org/D153931

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -119,7 +119,6 @@
   set(RUNTIMES_${target}_CMAKE_SYSTEM_NAME Windows CACHE STRING "")
   set(RUNTIMES_${target}_CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "")
   set(RUNTIMES_${target}_LIBCXX_ABI_VERSION 2 CACHE STRING "")
-  set(RUNTIMES_${target}_LIBCXX_ENABLE_FILESYSTEM OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LIBCXX_ENABLE_ABI_LINKER_SCRIPT OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LIBCXX_ENABLE_SHARED OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE 
STRING "")


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -119,7 +119,6 @@
   set(RUNTIMES_${target}_CMAKE_SYSTEM_NAME Windows CACHE STRING "")
   set(RUNTIMES_${target}_CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "")
   set(RUNTIMES_${target}_LIBCXX_ABI_VERSION 2 CACHE STRING "")
-  set(RUNTIMES_${target}_LIBCXX_ENABLE_FILESYSTEM OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LIBCXX_ENABLE_ABI_LINKER_SCRIPT OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LIBCXX_ENABLE_SHARED OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE STRING "")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D153931: [Fuchsia] Enable libcxx filesystem on Windows build.

2023-06-27 Thread Haowei Wu via Phabricator via cfe-commits
haowei created this revision.
haowei added reviewers: phosek, Prabhuk.
Herald added a subscriber: abrachet.
Herald added a project: All.
haowei requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch enables the libcxx filesystem when building runtimes for Windows.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D153931

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -119,7 +119,7 @@
   set(RUNTIMES_${target}_CMAKE_SYSTEM_NAME Windows CACHE STRING "")
   set(RUNTIMES_${target}_CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "")
   set(RUNTIMES_${target}_LIBCXX_ABI_VERSION 2 CACHE STRING "")
-  set(RUNTIMES_${target}_LIBCXX_ENABLE_FILESYSTEM OFF CACHE BOOL "")
+  set(RUNTIMES_${target}_LIBCXX_ENABLE_FILESYSTEM ON CACHE BOOL "")
   set(RUNTIMES_${target}_LIBCXX_ENABLE_ABI_LINKER_SCRIPT OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LIBCXX_ENABLE_SHARED OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE 
STRING "")


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -119,7 +119,7 @@
   set(RUNTIMES_${target}_CMAKE_SYSTEM_NAME Windows CACHE STRING "")
   set(RUNTIMES_${target}_CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "")
   set(RUNTIMES_${target}_LIBCXX_ABI_VERSION 2 CACHE STRING "")
-  set(RUNTIMES_${target}_LIBCXX_ENABLE_FILESYSTEM OFF CACHE BOOL "")
+  set(RUNTIMES_${target}_LIBCXX_ENABLE_FILESYSTEM ON CACHE BOOL "")
   set(RUNTIMES_${target}_LIBCXX_ENABLE_ABI_LINKER_SCRIPT OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LIBCXX_ENABLE_SHARED OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE STRING "")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D152318: [Fuchsia] Add llvm-strings to Fuchsia clang build

2023-06-07 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

In D152318#4402234 , @mstorsjo wrote:

> FWIW, I'm curious about where you need `llvm-strings` in a MinGW setting. 
> While it does match a GNU binutils tool, I'm kinda curious where it is needed.

llvm-strings exists in the `output_dir/bin` from a local llvm-mingw build using 
the scripts in your repo. So I think we might need it. I didn't dig into it why 
it exists in the first place. The current effort is to replicate the results. 
If it is not required I think there is no harm to added to Fuchsia's Clang 
configuration.

We are trying to build and setup a automated builder for llvm-mingw project 
using Fuchsia's Clang toolchain (instead of a pinned version of LLVM from 
llvm-mingw's build script) and using it to build some Windows host tools.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D152318/new/

https://reviews.llvm.org/D152318

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D152318: [Fuchsia] Add llvm-strings to Fuchsia clang build

2023-06-06 Thread Haowei Wu via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGbb398898dad9: [Fuchsia] Add llvm-strings to Fuchsia clang 
build. (authored by haowei).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D152318/new/

https://reviews.llvm.org/D152318

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -321,6 +321,7 @@
   llvm-readelf
   llvm-readobj
   llvm-size
+  llvm-strings
   llvm-strip
   llvm-symbolizer
   llvm-undname


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -321,6 +321,7 @@
   llvm-readelf
   llvm-readobj
   llvm-size
+  llvm-strings
   llvm-strip
   llvm-symbolizer
   llvm-undname
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D152318: [Fuchsia] Add llvm-strings to Fuchsia clang build

2023-06-06 Thread Haowei Wu via Phabricator via cfe-commits
haowei created this revision.
haowei added reviewers: phosek, mcgrathr.
Herald added subscribers: abrachet, mstorsjo.
Herald added a project: All.
haowei requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch adds 'llvm-strings' to Fuchsia clang build.

This tool is required to build a llvm based MinGW.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D152318

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -321,6 +321,7 @@
   llvm-readelf
   llvm-readobj
   llvm-size
+  llvm-strings
   llvm-strip
   llvm-symbolizer
   llvm-undname


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -321,6 +321,7 @@
   llvm-readelf
   llvm-readobj
   llvm-size
+  llvm-strings
   llvm-strip
   llvm-symbolizer
   llvm-undname
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D150939: [CMake] Remove BOLT from Fuchsia toolchain

2023-05-30 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150939/new/

https://reviews.llvm.org/D150939

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D144603: Disable compiler launcher on external projects and multi stage clang

2023-04-24 Thread Haowei Wu via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe38cdc5933b0: Disable compiler launcher on external projects 
and multi stage clang (authored by haowei).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D144603/new/

https://reviews.llvm.org/D144603

Files:
  clang/CMakeLists.txt
  llvm/cmake/modules/LLVMExternalProjectUtils.cmake


Index: llvm/cmake/modules/LLVMExternalProjectUtils.cmake
===
--- llvm/cmake/modules/LLVMExternalProjectUtils.cmake
+++ llvm/cmake/modules/LLVMExternalProjectUtils.cmake
@@ -165,6 +165,19 @@
 endforeach()
   endforeach()
 
+  # Populate the non-project-specific passthrough variables
+  foreach(variableName ${LLVM_EXTERNAL_PROJECT_PASSTHROUGH})
+if(DEFINED ${variableName})
+  if("${${variableName}}" STREQUAL "")
+set(value "")
+  else()
+string(REPLACE ";" "|" value "${${variableName}}")
+  endif()
+  list(APPEND PASSTHROUGH_VARIABLES
+-D${variableName}=${value})
+endif()
+  endforeach()
+
   if(ARG_USE_TOOLCHAIN AND NOT CMAKE_CROSSCOMPILING)
 if(CLANG_IN_TOOLCHAIN)
   if(is_msvc_target)
@@ -327,8 +340,6 @@
-DPACKAGE_VERSION=${PACKAGE_VERSION}
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
-   -DCMAKE_C_COMPILER_LAUNCHER=${CMAKE_C_COMPILER_LAUNCHER}
-   -DCMAKE_CXX_COMPILER_LAUNCHER=${CMAKE_CXX_COMPILER_LAUNCHER}
-DCMAKE_EXPORT_COMPILE_COMMANDS=1
${cmake_args}
${PASSTHROUGH_VARIABLES}
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -660,8 +660,6 @@
 LLVM_VERSION_SUFFIX
 LLVM_BINUTILS_INCDIR
 CLANG_REPOSITORY_STRING
-CMAKE_C_COMPILER_LAUNCHER
-CMAKE_CXX_COMPILER_LAUNCHER
 CMAKE_MAKE_PROGRAM
 CMAKE_OSX_ARCHITECTURES
 CMAKE_BUILD_TYPE


Index: llvm/cmake/modules/LLVMExternalProjectUtils.cmake
===
--- llvm/cmake/modules/LLVMExternalProjectUtils.cmake
+++ llvm/cmake/modules/LLVMExternalProjectUtils.cmake
@@ -165,6 +165,19 @@
 endforeach()
   endforeach()
 
+  # Populate the non-project-specific passthrough variables
+  foreach(variableName ${LLVM_EXTERNAL_PROJECT_PASSTHROUGH})
+if(DEFINED ${variableName})
+  if("${${variableName}}" STREQUAL "")
+set(value "")
+  else()
+string(REPLACE ";" "|" value "${${variableName}}")
+  endif()
+  list(APPEND PASSTHROUGH_VARIABLES
+-D${variableName}=${value})
+endif()
+  endforeach()
+
   if(ARG_USE_TOOLCHAIN AND NOT CMAKE_CROSSCOMPILING)
 if(CLANG_IN_TOOLCHAIN)
   if(is_msvc_target)
@@ -327,8 +340,6 @@
-DPACKAGE_VERSION=${PACKAGE_VERSION}
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
-   -DCMAKE_C_COMPILER_LAUNCHER=${CMAKE_C_COMPILER_LAUNCHER}
-   -DCMAKE_CXX_COMPILER_LAUNCHER=${CMAKE_CXX_COMPILER_LAUNCHER}
-DCMAKE_EXPORT_COMPILE_COMMANDS=1
${cmake_args}
${PASSTHROUGH_VARIABLES}
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -660,8 +660,6 @@
 LLVM_VERSION_SUFFIX
 LLVM_BINUTILS_INCDIR
 CLANG_REPOSITORY_STRING
-CMAKE_C_COMPILER_LAUNCHER
-CMAKE_CXX_COMPILER_LAUNCHER
 CMAKE_MAKE_PROGRAM
 CMAKE_OSX_ARCHITECTURES
 CMAKE_BUILD_TYPE
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148383: [driver] Enable response file when using lld on baremetal targets

2023-04-14 Thread Haowei Wu via Phabricator via cfe-commits
haowei created this revision.
haowei added reviewers: mcgrathr, phosek.
Herald added a subscriber: abidh.
Herald added a project: All.
haowei requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

This patch enables response file support when using lld on baremetal targets


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D148383

Files:
  clang/lib/Driver/ToolChains/BareMetal.cpp


Index: clang/lib/Driver/ToolChains/BareMetal.cpp
===
--- clang/lib/Driver/ToolChains/BareMetal.cpp
+++ clang/lib/Driver/ToolChains/BareMetal.cpp
@@ -345,7 +345,14 @@
   CmdArgs.push_back("-o");
   CmdArgs.push_back(Output.getFilename());
 
-  C.addCommand(std::make_unique(JA, *this, 
ResponseFileSupport::None(),
+  const char *Linker = Args.MakeArgString(TC.GetLinkerPath());
+  ResponseFileSupport LinkerResponseFileSupport = 
ResponseFileSupport::AtFileCurCP();
+  if (llvm::sys::path::filename(Linker) != "ld.lld" &&
+  llvm::sys::path::stem(Linker) != "ld.lld") {
+LinkerResponseFileSupport = ResponseFileSupport::None();
+  }
+
+  C.addCommand(std::make_unique(JA, *this, LinkerResponseFileSupport,
  
Args.MakeArgString(TC.GetLinkerPath()),
  CmdArgs, Inputs, Output));
 }


Index: clang/lib/Driver/ToolChains/BareMetal.cpp
===
--- clang/lib/Driver/ToolChains/BareMetal.cpp
+++ clang/lib/Driver/ToolChains/BareMetal.cpp
@@ -345,7 +345,14 @@
   CmdArgs.push_back("-o");
   CmdArgs.push_back(Output.getFilename());
 
-  C.addCommand(std::make_unique(JA, *this, ResponseFileSupport::None(),
+  const char *Linker = Args.MakeArgString(TC.GetLinkerPath());
+  ResponseFileSupport LinkerResponseFileSupport = ResponseFileSupport::AtFileCurCP();
+  if (llvm::sys::path::filename(Linker) != "ld.lld" &&
+  llvm::sys::path::stem(Linker) != "ld.lld") {
+LinkerResponseFileSupport = ResponseFileSupport::None();
+  }
+
+  C.addCommand(std::make_unique(JA, *this, LinkerResponseFileSupport,
  Args.MakeArgString(TC.GetLinkerPath()),
  CmdArgs, Inputs, Output));
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D146987: [Assignment Tracking] Enable by default

2023-03-31 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

This patch (which enables assignment tracking) and D147312 
 breaks llvm runtime build for 
`runtimes-armv7-unknown-linux-gnueabihf`

Error message:

  FAILED: libcxx/src/CMakeFiles/cxx_static.dir/charconv.cpp.o 
  /b/s/w/ir/cache/goma/client/gomacc 
/b/s/w/ir/x/w/staging/llvm_build/./bin/clang++ 
--target=armv7-unknown-linux-gnueabihf --sysroot=/b/s/w/ir/x/w/cipd/linux 
-DLIBCXX_BUILDING_LIBCXXABI -D_GLIBCXX_ASSERTIONS -D_LIBCPP_BUILDING_LIBRARY 
-D_LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS -D_LIBCPP_ENABLE_ASSERTIONS 
-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D_LIBCPP_LINK_PTHREAD_LIB 
-D_LIBCPP_LINK_RT_LIB -D_LIBCPP_REMOVE_TRANSITIVE_INCLUDES 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-I/b/s/w/ir/x/w/llvm-llvm-project/libcxx/src 
-I/b/s/w/ir/x/w/staging/llvm_build/include/c++/v1 
-I/b/s/w/ir/x/w/staging/llvm_build/include/armv7-unknown-linux-gnueabihf/c++/v1 
-I/b/s/w/ir/x/w/llvm-llvm-project/libcxxabi/include 
--target=armv7-unknown-linux-gnueabihf -fvisibility-inlines-hidden 
-Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra 
-Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers 
-Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type 
-Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment 
-Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported 
-fdiagnostics-color -ffunction-sections -fdata-sections 
-ffile-prefix-map=/b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-armv7-unknown-linux-gnueabihf-bins=../staging/llvm_build/runtimes/runtimes-armv7-unknown-linux-gnueabihf-bins
 -ffile-prefix-map=/b/s/w/ir/x/w/llvm-llvm-project/= -no-canonical-prefixes -O2 
-g -DNDEBUG -std=c++20 -fPIC -UNDEBUG -faligned-allocation -nostdinc++ 
-fvisibility-inlines-hidden -fvisibility=hidden -Wall -Wextra -Wnewline-eof 
-Wshadow -Wwrite-strings -Wno-unused-parameter -Wno-long-long 
-Werror=return-type -Wextra-semi -Wundef -Wunused-template -Wformat-nonliteral 
-Wno-user-defined-literals -Wno-covered-switch-default -Wno-suggest-override 
-Wno-error -MD -MT libcxx/src/CMakeFiles/cxx_static.dir/charconv.cpp.o -MF 
libcxx/src/CMakeFiles/cxx_static.dir/charconv.cpp.o.d -o 
libcxx/src/CMakeFiles/cxx_static.dir/charconv.cpp.o -c 
/b/s/w/ir/x/w/llvm-llvm-project/libcxx/src/charconv.cpp
  fragment covers entire variable
call void @llvm.dbg.value(metadata i32 %0, metadata !3116, metadata 
!DIExpression(DW_OP_LLVM_fragment, 0, 32)), !dbg !3130
  !3116 = !DILocalVariable(name: "__pred", arg: 3, scope: !3117, file: !3118, 
line: 23, type: !3121)
  fragment covers entire variable
call void @llvm.dbg.value(metadata i64 %0, metadata !3652, metadata 
!DIExpression(DW_OP_LLVM_fragment, 0, 64)), !dbg !3665
  !3652 = !DILocalVariable(name: "__pred", arg: 3, scope: !3653, file: !3118, 
line: 23, type: !3656)
  fragment covers entire variable
call void @llvm.dbg.value(metadata i32 %0, metadata !3116, metadata 
!DIExpression(DW_OP_LLVM_fragment, 0, 32)), !dbg !3130
  !3116 = !DILocalVariable(name: "__pred", arg: 3, scope: !3117, file: !3118, 
line: 23, type: !3121)
  fragment covers entire variable
call void @llvm.dbg.value(metadata i64 %0, metadata !3651, metadata 
!DIExpression(DW_OP_LLVM_fragment, 0, 64)), !dbg !3664
  !3651 = !DILocalVariable(name: "__pred", arg: 3, scope: !3652, file: !3118, 
line: 23, type: !3655)
  fatal error: error in backend: Broken module found, compilation aborted!
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ 
and include the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.Program arguments: /b/s/w/ir/x/w/staging/llvm_build/./bin/clang++ 
--target=armv7-unknown-linux-gnueabihf --sysroot=/b/s/w/ir/x/w/cipd/linux 
-DLIBCXX_BUILDING_LIBCXXABI -D_GLIBCXX_ASSERTIONS -D_LIBCPP_BUILDING_LIBRARY 
-D_LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS -D_LIBCPP_ENABLE_ASSERTIONS 
-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D_LIBCPP_LINK_PTHREAD_LIB 
-D_LIBCPP_LINK_RT_LIB -D_LIBCPP_REMOVE_TRANSITIVE_INCLUDES 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-I/b/s/w/ir/x/w/llvm-llvm-project/libcxx/src 
-I/b/s/w/ir/x/w/staging/llvm_build/include/c++/v1 
-I/b/s/w/ir/x/w/staging/llvm_build/include/armv7-unknown-linux-gnueabihf/c++/v1 
-I/b/s/w/ir/x/w/llvm-llvm-project/libcxxabi/include 
--target=armv7-unknown-linux-gnueabihf -fvisibility-inlines-hidden 
-Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra 
-Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers 
-Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type 
-Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment 
-Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported 
-fdiagnostics-color -ffunction-sections -fdata-sections 

[PATCH] D145449: [Fuchsia] Add LLDB options to stage 1 cmake.

2023-03-07 Thread Haowei Wu via Phabricator via cfe-commits
haowei accepted this revision.
haowei added a comment.
This revision is now accepted and ready to land.

LGTM, but please wait @phosek to approve it.




Comment at: clang/cmake/caches/Fuchsia.cmake:167
+if(FUCHSIA_ENABLE_LLDB)
+  list(APPEND _FUCHSIA_ENABLE_PROJECTS lldb)
+endif()

mysterymath wrote:
> haowei wrote:
> > You probably need a `string(REPLACE ";" "|" value 
> > "${_FUCHSIA_ENABLE_PROJECTS}")` after append a value. As by default cmake 
> > use `|` to separate items.
> > But do you actually need a `_FUCHSIA_ENABLE_PROJECTS` variable, couldn't 
> > you just append `lldb` at the end of `LLVM_ENABLE_PROJECTS` here?
> > You probably need a `string(REPLACE ";" "|" value 
> > "${_FUCHSIA_ENABLE_PROJECTS}")` after append a value. As by default cmake 
> > use `|` to separate items.
> Hm? CMake's list separator is the semicolon: 
> https://cmake.org/cmake/help/latest/command/list.html
> 
> > But do you actually need a `_FUCHSIA_ENABLE_PROJECTS` variable, couldn't 
> > you just append `lldb` at the end of `LLVM_ENABLE_PROJECTS` here?
> `(list APPEND ...)` doesn't work on cache variables. If I were to use the 
> (set CACHE FORCE) idiom instead, it would append lldb each time a configure 
> occurs. The idea here is to have FUCHSIA_ENABLE_LLDB affect the defaults, but 
> to respect whatever's already in the CMake cache otherwise.
> Hm? CMake's list separator is the semicolon: 
> https://cmake.org/cmake/help/latest/command/list.html
> 

I see, I am wrong. I thought it is similar to passthrough cmake variables to 
the next stage. 

> (list APPEND ...) doesn't work on cache variables. If I were to use the (set 
> CACHE FORCE) idiom instead, it would append lldb each time a configure 
> occurs. The idea here is to have FUCHSIA_ENABLE_LLDB affect the defaults, but 
> to respect whatever's already in the CMake cache otherwise.

I see. I didn't know that. 




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D145449/new/

https://reviews.llvm.org/D145449

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D145449: [Fuchsia] Add LLDB options to stage 1 cmake.

2023-03-06 Thread Haowei Wu via Phabricator via cfe-commits
haowei added inline comments.



Comment at: clang/cmake/caches/Fuchsia.cmake:167
+if(FUCHSIA_ENABLE_LLDB)
+  list(APPEND _FUCHSIA_ENABLE_PROJECTS lldb)
+endif()

You probably need a `string(REPLACE ";" "|" value 
"${_FUCHSIA_ENABLE_PROJECTS}")` after append a value. As by default cmake use 
`|` to separate items.
But do you actually need a `_FUCHSIA_ENABLE_PROJECTS` variable, couldn't you 
just append `lldb` at the end of `LLVM_ENABLE_PROJECTS` here?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D145449/new/

https://reviews.llvm.org/D145449

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D144603: Disable compiler launcher on external projects and multi stage clang

2023-03-06 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 502841.
haowei retitled this revision from "Add option to disable compiler launcher on 
external projects" to "Disable compiler launcher on external projects and multi 
stage clang".
haowei edited the summary of this revision.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D144603/new/

https://reviews.llvm.org/D144603

Files:
  clang/CMakeLists.txt
  llvm/cmake/modules/LLVMExternalProjectUtils.cmake


Index: llvm/cmake/modules/LLVMExternalProjectUtils.cmake
===
--- llvm/cmake/modules/LLVMExternalProjectUtils.cmake
+++ llvm/cmake/modules/LLVMExternalProjectUtils.cmake
@@ -165,6 +165,19 @@
 endforeach()
   endforeach()
 
+  # Populate the non-project-specific passthrough variables
+  foreach(variableName ${LLVM_EXTERNAL_PROJECT_PASSTHROUGH})
+if(DEFINED ${variableName})
+  if("${${variableName}}" STREQUAL "")
+set(value "")
+  else()
+string(REPLACE ";" "|" value "${${variableName}}")
+  endif()
+  list(APPEND PASSTHROUGH_VARIABLES
+-D${variableName}=${value})
+endif()
+  endforeach()
+
   if(ARG_USE_TOOLCHAIN AND NOT CMAKE_CROSSCOMPILING)
 if(CLANG_IN_TOOLCHAIN)
   if(is_msvc_target)
@@ -327,8 +340,6 @@
-DPACKAGE_VERSION=${PACKAGE_VERSION}
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
-   -DCMAKE_C_COMPILER_LAUNCHER=${CMAKE_C_COMPILER_LAUNCHER}
-   -DCMAKE_CXX_COMPILER_LAUNCHER=${CMAKE_CXX_COMPILER_LAUNCHER}
-DCMAKE_EXPORT_COMPILE_COMMANDS=1
${cmake_args}
${PASSTHROUGH_VARIABLES}
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -661,8 +661,6 @@
 LLVM_VERSION_SUFFIX
 LLVM_BINUTILS_INCDIR
 CLANG_REPOSITORY_STRING
-CMAKE_C_COMPILER_LAUNCHER
-CMAKE_CXX_COMPILER_LAUNCHER
 CMAKE_MAKE_PROGRAM
 CMAKE_OSX_ARCHITECTURES
 CMAKE_BUILD_TYPE


Index: llvm/cmake/modules/LLVMExternalProjectUtils.cmake
===
--- llvm/cmake/modules/LLVMExternalProjectUtils.cmake
+++ llvm/cmake/modules/LLVMExternalProjectUtils.cmake
@@ -165,6 +165,19 @@
 endforeach()
   endforeach()
 
+  # Populate the non-project-specific passthrough variables
+  foreach(variableName ${LLVM_EXTERNAL_PROJECT_PASSTHROUGH})
+if(DEFINED ${variableName})
+  if("${${variableName}}" STREQUAL "")
+set(value "")
+  else()
+string(REPLACE ";" "|" value "${${variableName}}")
+  endif()
+  list(APPEND PASSTHROUGH_VARIABLES
+-D${variableName}=${value})
+endif()
+  endforeach()
+
   if(ARG_USE_TOOLCHAIN AND NOT CMAKE_CROSSCOMPILING)
 if(CLANG_IN_TOOLCHAIN)
   if(is_msvc_target)
@@ -327,8 +340,6 @@
-DPACKAGE_VERSION=${PACKAGE_VERSION}
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
-   -DCMAKE_C_COMPILER_LAUNCHER=${CMAKE_C_COMPILER_LAUNCHER}
-   -DCMAKE_CXX_COMPILER_LAUNCHER=${CMAKE_CXX_COMPILER_LAUNCHER}
-DCMAKE_EXPORT_COMPILE_COMMANDS=1
${cmake_args}
${PASSTHROUGH_VARIABLES}
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -661,8 +661,6 @@
 LLVM_VERSION_SUFFIX
 LLVM_BINUTILS_INCDIR
 CLANG_REPOSITORY_STRING
-CMAKE_C_COMPILER_LAUNCHER
-CMAKE_CXX_COMPILER_LAUNCHER
 CMAKE_MAKE_PROGRAM
 CMAKE_OSX_ARCHITECTURES
 CMAKE_BUILD_TYPE
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D144603: Add option to disable compiler launcher on external projects

2023-03-01 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 501670.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D144603/new/

https://reviews.llvm.org/D144603

Files:
  clang/CMakeLists.txt
  clang/cmake/caches/Fuchsia-stage2.cmake
  clang/cmake/caches/Fuchsia.cmake
  llvm/cmake/modules/LLVMExternalProjectUtils.cmake


Index: llvm/cmake/modules/LLVMExternalProjectUtils.cmake
===
--- llvm/cmake/modules/LLVMExternalProjectUtils.cmake
+++ llvm/cmake/modules/LLVMExternalProjectUtils.cmake
@@ -302,6 +302,13 @@
 list(APPEND compiler_args -DCMAKE_ASM_COMPILER_TARGET=${ARG_TARGET_TRIPLE})
   endif()
 
+  if (NOT LLVM_DISABLE_COMPILER_LAUNCHER_FOR_EXT_PROJECT)
+list(APPEND
+  cmake_args
+  -DCMAKE_C_COMPILER_LAUNCHER=${CMAKE_C_COMPILER_LAUNCHER}
+  -DCMAKE_CXX_COMPILER_LAUNCHER=${CMAKE_CXX_COMPILER_LAUNCHER})
+  endif()
+
   ExternalProject_Add(${name}
 DEPENDS ${ARG_DEPENDS} llvm-config
 ${name}-clobber
@@ -327,8 +334,6 @@
-DPACKAGE_VERSION=${PACKAGE_VERSION}
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
-   -DCMAKE_C_COMPILER_LAUNCHER=${CMAKE_C_COMPILER_LAUNCHER}
-   -DCMAKE_CXX_COMPILER_LAUNCHER=${CMAKE_CXX_COMPILER_LAUNCHER}
-DCMAKE_EXPORT_COMPILE_COMMANDS=1
${cmake_args}
${PASSTHROUGH_VARIABLES}
Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -17,6 +17,7 @@
 set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "")
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
 set(LLVM_USE_RELATIVE_PATHS_IN_FILES ON CACHE BOOL "")
+set(LLVM_DISABLE_COMPILER_LAUNCHER_FOR_EXT_PROJECT ON CACHE BOOL "")
 
 # Passthrough stage1 flags to stage1.
 set(_FUCHSIA_BOOTSTRAP_PASSTHROUGH
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -23,6 +23,7 @@
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
 set(LLVM_STATIC_LINK_CXX_STDLIB ON CACHE BOOL "")
 set(LLVM_USE_RELATIVE_PATHS_IN_FILES ON CACHE BOOL "")
+set(LLVM_DISABLE_COMPILER_LAUNCHER_FOR_EXT_PROJECT ON CACHE BOOL "")
 
 if(WIN32)
   set(LLVM_USE_CRT_RELEASE "MT" CACHE STRING "")
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -661,8 +661,6 @@
 LLVM_VERSION_SUFFIX
 LLVM_BINUTILS_INCDIR
 CLANG_REPOSITORY_STRING
-CMAKE_C_COMPILER_LAUNCHER
-CMAKE_CXX_COMPILER_LAUNCHER
 CMAKE_MAKE_PROGRAM
 CMAKE_OSX_ARCHITECTURES
 CMAKE_BUILD_TYPE


Index: llvm/cmake/modules/LLVMExternalProjectUtils.cmake
===
--- llvm/cmake/modules/LLVMExternalProjectUtils.cmake
+++ llvm/cmake/modules/LLVMExternalProjectUtils.cmake
@@ -302,6 +302,13 @@
 list(APPEND compiler_args -DCMAKE_ASM_COMPILER_TARGET=${ARG_TARGET_TRIPLE})
   endif()
 
+  if (NOT LLVM_DISABLE_COMPILER_LAUNCHER_FOR_EXT_PROJECT)
+list(APPEND
+  cmake_args
+  -DCMAKE_C_COMPILER_LAUNCHER=${CMAKE_C_COMPILER_LAUNCHER}
+  -DCMAKE_CXX_COMPILER_LAUNCHER=${CMAKE_CXX_COMPILER_LAUNCHER})
+  endif()
+
   ExternalProject_Add(${name}
 DEPENDS ${ARG_DEPENDS} llvm-config
 ${name}-clobber
@@ -327,8 +334,6 @@
-DPACKAGE_VERSION=${PACKAGE_VERSION}
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
-   -DCMAKE_C_COMPILER_LAUNCHER=${CMAKE_C_COMPILER_LAUNCHER}
-   -DCMAKE_CXX_COMPILER_LAUNCHER=${CMAKE_CXX_COMPILER_LAUNCHER}
-DCMAKE_EXPORT_COMPILE_COMMANDS=1
${cmake_args}
${PASSTHROUGH_VARIABLES}
Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -17,6 +17,7 @@
 set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "")
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
 set(LLVM_USE_RELATIVE_PATHS_IN_FILES ON CACHE BOOL "")
+set(LLVM_DISABLE_COMPILER_LAUNCHER_FOR_EXT_PROJECT ON CACHE BOOL "")
 
 # Passthrough stage1 flags to stage1.
 set(_FUCHSIA_BOOTSTRAP_PASSTHROUGH
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -23,6 +23,7 @@
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
 set(LLVM_STATIC_LINK_CXX_STDLIB ON CACHE BOOL "")
 set(LLVM_USE_RELATIVE_PATHS_IN_FILES ON CACHE BOOL "")
+set(LLVM_DISABLE_COMPILER_LAUNCHER_FOR_EXT_PROJECT ON CACHE BOOL "")
 
 if(WIN32)
   set(LLVM_USE_CRT_RELEASE "MT" CACHE 

[PATCH] D144603: Add option to disable compiler launcher on external projects

2023-03-01 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

In D144603#4162223 , @phosek wrote:

> I agree, in that case let's remove 
> `C_COMPILER_LAUNCHER;CXX_COMPILER_LAUNCHER` from the list of default 
> passthrough variables which seems like a reasonable default, and provide 
> `CLANG_BOOTSTRAP_EXTRA_PASSTHROUGH` so developers have a way to pass these 
> through to the next stage if they want to.

There is already a `CLANG_BOOTSTRAP_PASSTHROUGH` flag 
https://github.com/llvm/llvm-project/blob/dc1c8917afd3f2b306797890a56be66087feb832/clang/CMakeLists.txt#L749
 that works in the way you describe the `CLANG_BOOTSTRAP_EXTRA_PASSTHROUGH` 
flag.

I think remove the compiler launcher from default pass through flags are fine. 
What about the using compiler launcher in runtime builds? I don't think we 
should read `CLANG_BOOTSTRAP_PASSTHROUGH` to determine if we should pass 
through compiler launcher flags.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D144603/new/

https://reviews.llvm.org/D144603

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D144603: Add option to disable compiler launcher on external projects

2023-03-01 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

In D144603#4162048 , @smeenai wrote:

> Hmm, what cache key does ccache use for compilers? Is it the `--version` 
> output string, the path, or some combination? If the path is involved then I 
> don't see any value in using ccache for configuring anything past stage1, 
> since the compiler will (presumably) be installed somewhere else afterwards 
> and not used directly from the build tree. If it's just `--version`, what are 
> the cache pollution concerns? The compiler binaries output by all the stages 
> should produce the same outputs given the same inputs (and presumably have 
> the same `--version`), right?

I am not sure about ccache. We use an internal distributed build cache system 
when we build LLVM. The compiler binary hash and the `--version` output will 
both be used to calculate the cache key so there is little value to use caching 
past stage1 as the runtime build and stage2+ will be built from a fresh from 
source compiler and it will always result in cache miss.

I don't believe ccache only uses `--version` output as cache key since two 
compiler binary with the same version string can have different output (e.g. 2 
WIP source tree but track the same git revision).

So think it would be beneficial to add a flag to avoid using compiler launcher 
past stage1.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D144603/new/

https://reviews.llvm.org/D144603

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D145010: [Fuchsia] Enable LLVM_USE_RELATIVE_PATHS_IN_FILES in bootstrap

2023-02-28 Thread Haowei Wu via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa7bb9a363923: [Fuchsia] Enable 
LLVM_USE_RELATIVE_PATHS_IN_FILES in bootstrap (authored by haowei).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D145010/new/

https://reviews.llvm.org/D145010

Files:
  clang/cmake/caches/Fuchsia.cmake


Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -16,6 +16,7 @@
 set(LLVM_ENABLE_ZLIB OFF CACHE BOOL "")
 set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "")
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
+set(LLVM_USE_RELATIVE_PATHS_IN_FILES ON CACHE BOOL "")
 
 # Passthrough stage1 flags to stage1.
 set(_FUCHSIA_BOOTSTRAP_PASSTHROUGH


Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -16,6 +16,7 @@
 set(LLVM_ENABLE_ZLIB OFF CACHE BOOL "")
 set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "")
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
+set(LLVM_USE_RELATIVE_PATHS_IN_FILES ON CACHE BOOL "")
 
 # Passthrough stage1 flags to stage1.
 set(_FUCHSIA_BOOTSTRAP_PASSTHROUGH
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D145010: [Fuchsia] Enable LLVM_USE_RELATIVE_PATHS_IN_FILES in bootstrap

2023-02-28 Thread Haowei Wu via Phabricator via cfe-commits
haowei created this revision.
haowei added reviewers: phosek, abrachet.
Herald added a project: All.
haowei requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch enables LLVM_USE_RELATIVE_PATHS_IN_FILES when building the bootstrap 
toolchain for 2 stages build.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D145010

Files:
  clang/cmake/caches/Fuchsia.cmake


Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -16,6 +16,7 @@
 set(LLVM_ENABLE_ZLIB OFF CACHE BOOL "")
 set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "")
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
+set(LLVM_USE_RELATIVE_PATHS_IN_FILES ON CACHE BOOL "")
 
 # Passthrough stage1 flags to stage1.
 set(_FUCHSIA_BOOTSTRAP_PASSTHROUGH


Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -16,6 +16,7 @@
 set(LLVM_ENABLE_ZLIB OFF CACHE BOOL "")
 set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "")
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
+set(LLVM_USE_RELATIVE_PATHS_IN_FILES ON CACHE BOOL "")
 
 # Passthrough stage1 flags to stage1.
 set(_FUCHSIA_BOOTSTRAP_PASSTHROUGH
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D144603: Add option to disable compiler launcher on external projects

2023-02-22 Thread Haowei Wu via Phabricator via cfe-commits
haowei created this revision.
haowei added a reviewer: phosek.
Herald added a subscriber: abrachet.
Herald added a project: All.
haowei requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

When using compiler caching program like ccache, there are cases that a user 
would like to disable using it when building external projects like the 2nd 
stage clang or compiler runtimes to avoid polluting the cache due to using a 
fresh from source toolchain. This patch adds 
"LLVM_DISABLE_COMPILER_LAUNCHER_FOR_EXT_PROJECT" option so the compiler 
launcher can be disabled in these cases.

I would appreciate it if someone can suggest a better name for this option.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D144603

Files:
  clang/CMakeLists.txt
  clang/cmake/caches/Fuchsia-stage2.cmake
  clang/cmake/caches/Fuchsia.cmake
  llvm/cmake/modules/LLVMExternalProjectUtils.cmake


Index: llvm/cmake/modules/LLVMExternalProjectUtils.cmake
===
--- llvm/cmake/modules/LLVMExternalProjectUtils.cmake
+++ llvm/cmake/modules/LLVMExternalProjectUtils.cmake
@@ -302,6 +302,13 @@
 list(APPEND compiler_args -DCMAKE_ASM_COMPILER_TARGET=${ARG_TARGET_TRIPLE})
   endif()
 
+  set(C_COMPILER_LAUNCHER ${CMAKE_C_COMPILER_LAUNCHER})
+  set(CXX_COMPILER_LAUNCHER ${CMAKE_CXX_COMPILER_LAUNCHER})
+  if (LLVM_DISABLE_COMPILER_LAUNCHER_FOR_EXT_PROJECT)
+set(C_COMPILER_LAUNCHER "")
+set(CXX_COMPILER_LAUNCHER "")
+  endif()
+
   ExternalProject_Add(${name}
 DEPENDS ${ARG_DEPENDS} llvm-config
 ${name}-clobber
@@ -327,8 +334,8 @@
-DPACKAGE_VERSION=${PACKAGE_VERSION}
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
-   -DCMAKE_C_COMPILER_LAUNCHER=${CMAKE_C_COMPILER_LAUNCHER}
-   -DCMAKE_CXX_COMPILER_LAUNCHER=${CMAKE_CXX_COMPILER_LAUNCHER}
+   -DCMAKE_C_COMPILER_LAUNCHER=${C_COMPILER_LAUNCHER}
+   -DCMAKE_CXX_COMPILER_LAUNCHER=${CXX_COMPILER_LAUNCHER}
-DCMAKE_EXPORT_COMPILE_COMMANDS=1
${cmake_args}
${PASSTHROUGH_VARIABLES}
Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -16,6 +16,7 @@
 set(LLVM_ENABLE_ZLIB OFF CACHE BOOL "")
 set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "")
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
+set(LLVM_DISABLE_COMPILER_LAUNCHER_FOR_EXT_PROJECT ON CACHE BOOL "")
 
 # Passthrough stage1 flags to stage1.
 set(_FUCHSIA_BOOTSTRAP_PASSTHROUGH
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -23,6 +23,7 @@
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
 set(LLVM_STATIC_LINK_CXX_STDLIB ON CACHE BOOL "")
 set(LLVM_USE_RELATIVE_PATHS_IN_FILES ON CACHE BOOL "")
+set(LLVM_DISABLE_COMPILER_LAUNCHER_FOR_EXT_PROJECT ON CACHE BOOL "")
 
 if(WIN32)
   set(LLVM_USE_CRT_RELEASE "MT" CACHE STRING "")
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -661,14 +661,18 @@
 LLVM_VERSION_SUFFIX
 LLVM_BINUTILS_INCDIR
 CLANG_REPOSITORY_STRING
-CMAKE_C_COMPILER_LAUNCHER
-CMAKE_CXX_COMPILER_LAUNCHER
 CMAKE_MAKE_PROGRAM
 CMAKE_OSX_ARCHITECTURES
 CMAKE_BUILD_TYPE
 LLVM_ENABLE_PROJECTS
 LLVM_ENABLE_RUNTIMES)
 
+  if (NOT LLVM_DISABLE_COMPILER_LAUNCHER_FOR_EXT_PROJECT)
+list(APPEND _BOOTSTRAP_DEFAULT_PASSTHROUGH
+  CMAKE_C_COMPILER_LAUNCHER
+  CMAKE_CXX_COMPILER_LAUNCHER)
+  endif()
+
   # We don't need to depend on compiler-rt/libcxx if we're building 
instrumented
   # because the next stage will use the same compiler used to build this stage.
   if(NOT LLVM_BUILD_INSTRUMENTED)


Index: llvm/cmake/modules/LLVMExternalProjectUtils.cmake
===
--- llvm/cmake/modules/LLVMExternalProjectUtils.cmake
+++ llvm/cmake/modules/LLVMExternalProjectUtils.cmake
@@ -302,6 +302,13 @@
 list(APPEND compiler_args -DCMAKE_ASM_COMPILER_TARGET=${ARG_TARGET_TRIPLE})
   endif()
 
+  set(C_COMPILER_LAUNCHER ${CMAKE_C_COMPILER_LAUNCHER})
+  set(CXX_COMPILER_LAUNCHER ${CMAKE_CXX_COMPILER_LAUNCHER})
+  if (LLVM_DISABLE_COMPILER_LAUNCHER_FOR_EXT_PROJECT)
+set(C_COMPILER_LAUNCHER "")
+set(CXX_COMPILER_LAUNCHER "")
+  endif()
+
   ExternalProject_Add(${name}
 DEPENDS ${ARG_DEPENDS} llvm-config
 ${name}-clobber
@@ -327,8 +334,8 @@
-DPACKAGE_VERSION=${PACKAGE_VERSION}
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
-   

[PATCH] D144595: [WIP] Experimenting building Windows runtimes when cross compiling LLVM toolchain

2023-02-22 Thread Haowei Wu via Phabricator via cfe-commits
haowei created this revision.
haowei added a reviewer: phosek.
Herald added a subscriber: kristof.beyls.
Herald added a project: All.
haowei requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

This is a working in progress patch, and it needs clean up and refactor. It is  
mainly for understanding what are needed to build windows runtime when the LLVM 
is being cross compiled for a different architecture. And to discuss the 
direction of refactoring the cmake configurations for the clang bootstrap build 
as well as LLVM runtimes build.

The use case is to include the Windows runtime build when cross compiling LLVM 
for an arch different from the host (e.g. building aarch64 on an x64 machine). 
This will be needed in the future when cross compile LLVM Windows toolchain for 
aarch64 on an x64 machine.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D144595

Files:
  clang/CMakeLists.txt
  llvm/cmake/modules/LLVMExternalProjectUtils.cmake
  llvm/runtimes/CMakeLists.txt

Index: llvm/runtimes/CMakeLists.txt
===
--- llvm/runtimes/CMakeLists.txt
+++ llvm/runtimes/CMakeLists.txt
@@ -77,6 +77,12 @@
 
   set_enable_per_target_runtime_dir()
 
+  message(NOTICE "builtin target for default")
+  #message(NOTICE "cmake args ${CMAKE_ARGS}")
+  message(NOTICE "cmake common args ${COMMON_CMAKE_ARGS}")
+  message(NOTICE "extra args:")
+  message(NOTICE ${BUILTINS_CMAKE_ARGS})
+
   llvm_ExternalProject_Add(builtins
${compiler_rt_path}/lib/builtins
DEPENDS ${ARG_DEPENDS}
@@ -111,6 +117,12 @@
 endif()
   endforeach()
 
+  message(NOTICE "builtin target for ${target}")
+  #message(NOTICE "cmake args ${CMAKE_ARGS}")
+  message(NOTICE "cmake common args ${COMMON_CMAKE_ARGS}")
+  message(NOTICE "extra args:")
+  message(NOTICE ${${target}_extra_args})
+
   llvm_ExternalProject_Add(builtins-${target}
${compiler_rt_path}/lib/builtins
DEPENDS ${ARG_DEPENDS}
@@ -221,6 +233,13 @@
 
   set_enable_per_target_runtime_dir()
 
+  message(NOTICE "runtime target for default")
+  #message(NOTICE "cmake args ${CMAKE_ARGS}")
+  message(NOTICE "cmake common args ${COMMON_CMAKE_ARGS}")
+  message(NOTICE "extra args:")
+  message(NOTICE ${RUNTIMES_CMAKE_ARGS})
+  message(NOTICE ${ARG_CMAKE_ARGS})
+
   llvm_ExternalProject_Add(runtimes
${CMAKE_CURRENT_SOURCE_DIR}/../../runtimes
DEPENDS ${ARG_DEPENDS}
@@ -349,6 +368,12 @@
 
   set_enable_per_target_runtime_dir()
 
+  message(NOTICE "runtime target for ${target}")
+  #message(NOTICE "cmake args ${CMAKE_ARGS}")
+  message(NOTICE "cmake common args ${COMMON_CMAKE_ARGS}")
+  message(NOTICE "extra args:")
+  message(NOTICE ${${name}_extra_args})
+
   llvm_ExternalProject_Add(runtimes-${name}
${CMAKE_CURRENT_SOURCE_DIR}/../../runtimes
DEPENDS ${${name}_deps}
Index: llvm/cmake/modules/LLVMExternalProjectUtils.cmake
===
--- llvm/cmake/modules/LLVMExternalProjectUtils.cmake
+++ llvm/cmake/modules/LLVMExternalProjectUtils.cmake
@@ -165,6 +165,9 @@
 endforeach()
   endforeach()
 
+  message(NOTICE "extproj ARG_USE_TOOLCHAIN is ${ARG_USE_TOOLCHAIN}")
+  message(NOTICE "extproj CMAKE_CROSSCOMPILING is ${CMAKE_CROSSCOMPILING}")
+  message(NOTICE "extproj CLANG_IN_TOOLCHAIN is ${CLANG_IN_TOOLCHAIN}")
   if(ARG_USE_TOOLCHAIN AND NOT CMAKE_CROSSCOMPILING)
 if(CLANG_IN_TOOLCHAIN)
   if(is_msvc_target)
@@ -249,18 +252,40 @@
   endif()
 
   if(CMAKE_CROSSCOMPILING OR _cmake_system_name STREQUAL AIX)
-set(compiler_args -DCMAKE_ASM_COMPILER=${CMAKE_ASM_COMPILER}
-  -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
-  -DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
-  -DCMAKE_LINKER=${CMAKE_LINKER}
-  -DCMAKE_AR=${CMAKE_AR}
-  -DCMAKE_RANLIB=${CMAKE_RANLIB}
-  -DCMAKE_NM=${CMAKE_NM}
-  -DCMAKE_OBJCOPY=${CMAKE_OBJCOPY}
-  -DCMAKE_OBJDUMP=${CMAKE_OBJDUMP}
-  -DCMAKE_STRIP=${CMAKE_STRIP}
-  -DCMAKE_READELF=${CMAKE_READELF})
+if (ARG_USE_TOOLCHAIN AND CLANG_IN_TOOLCHAIN AND is_msvc_target)
+  get_filename_component(HOST_TOOLCHAIN_DIR ${CMAKE_C_COMPILER} DIRECTORY)
+  set(compiler_args -DCMAKE_C_COMPILER=${HOST_TOOLCHAIN_DIR}/clang-cl${CMAKE_EXECUTABLE_SUFFIX}
+-DCMAKE_CXX_COMPILER=${HOST_TOOLCHAIN_DIR}/clang-cl${CMAKE_EXECUTABLE_SUFFIX}
+-DCMAKE_ASM_COMPILER=${HOST_TOOLCHAIN_DIR}/clang-cl${CMAKE_EXECUTABLE_SUFFIX})
+  if(lld IN_LIST TOOLCHAIN_TOOLS)
+list(APPEND compiler_args 

[PATCH] D143960: [Fuchsia] Set /winsysroot in windows runtimes linker flags

2023-02-14 Thread Haowei Wu via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGac835ecb5fea: [Fuchsia] Set /winsysroot in Windows runtimes 
linker flags (authored by haowei).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143960/new/

https://reviews.llvm.org/D143960

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -88,14 +88,13 @@
   ${LLVM_WINSYSROOT})
 string(REPLACE ";" " " WINDOWS_COMPILER_FLAGS "${WINDOWS_COMPILER_FLAGS}")
 set(WINDOWS_LINK_FLAGS
-/vfsoverlay:${LLVM_VFSOVERLAY}
-# TODO: On Windows, linker is invoked by cmake instead of the clang-cl 
driver,
-# so we have to manually set the libpath. We use clang-cl driver if we 
can
-# and remove these libpath flags.
--libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/lib/x64"
--libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/atlmfc/lib/x64"
--libpath:"${LLVM_WINSYSROOT}/Windows Kits/10/Lib/10.0.19041.0/ucrt/x64"
--libpath:"${LLVM_WINSYSROOT}/Windows Kits/10/Lib/10.0.19041.0/um/x64")
+  # TODO: lld-link has a bug that it cannot infer the machine type
+  # correctly when /winsysroot is set while Windows libraries search paths
+  # are not explicitly defined.
+  # Explicitly set the machine type for now.
+  /machine:X64
+  /vfsoverlay:${LLVM_VFSOVERLAY}
+  /winsysroot:${LLVM_WINSYSROOT})
 string(REPLACE ";" " " WINDOWS_LINK_FLAGS "${WINDOWS_LINK_FLAGS}")
   endif()
 


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -88,14 +88,13 @@
   ${LLVM_WINSYSROOT})
 string(REPLACE ";" " " WINDOWS_COMPILER_FLAGS "${WINDOWS_COMPILER_FLAGS}")
 set(WINDOWS_LINK_FLAGS
-/vfsoverlay:${LLVM_VFSOVERLAY}
-# TODO: On Windows, linker is invoked by cmake instead of the clang-cl driver,
-# so we have to manually set the libpath. We use clang-cl driver if we can
-# and remove these libpath flags.
--libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/lib/x64"
--libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/atlmfc/lib/x64"
--libpath:"${LLVM_WINSYSROOT}/Windows Kits/10/Lib/10.0.19041.0/ucrt/x64"
--libpath:"${LLVM_WINSYSROOT}/Windows Kits/10/Lib/10.0.19041.0/um/x64")
+  # TODO: lld-link has a bug that it cannot infer the machine type
+  # correctly when /winsysroot is set while Windows libraries search paths
+  # are not explicitly defined.
+  # Explicitly set the machine type for now.
+  /machine:X64
+  /vfsoverlay:${LLVM_VFSOVERLAY}
+  /winsysroot:${LLVM_WINSYSROOT})
 string(REPLACE ";" " " WINDOWS_LINK_FLAGS "${WINDOWS_LINK_FLAGS}")
   endif()
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D141808: [Driver] Add --vfsoverlay flag

2023-02-14 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

I am seeing test failures on pre submit Windows builder after this change was 
landed: See 
https://buildkite.com/llvm-project/premerge-checks/builds/135752#01864d34-9024-4c13-9137-88b6f41ec695


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141808/new/

https://reviews.llvm.org/D141808

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D143960: [Fuchsia] Set /winsysroot in windows runtimes linker flags

2023-02-13 Thread Haowei Wu via Phabricator via cfe-commits
haowei created this revision.
haowei added a reviewer: phosek.
Herald added a subscriber: abrachet.
Herald added a project: All.
haowei requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch sets '/winsysroot' flag when building Windows runtimes so we don't 
have to explicitly set Windows library search paths.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143960

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -88,14 +88,13 @@
   ${LLVM_WINSYSROOT})
 string(REPLACE ";" " " WINDOWS_COMPILER_FLAGS "${WINDOWS_COMPILER_FLAGS}")
 set(WINDOWS_LINK_FLAGS
-/vfsoverlay:${LLVM_VFSOVERLAY}
-# TODO: On Windows, linker is invoked by cmake instead of the clang-cl 
driver,
-# so we have to manually set the libpath. We use clang-cl driver if we 
can
-# and remove these libpath flags.
--libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/lib/x64"
--libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/atlmfc/lib/x64"
--libpath:"${LLVM_WINSYSROOT}/Windows Kits/10/Lib/10.0.19041.0/ucrt/x64"
--libpath:"${LLVM_WINSYSROOT}/Windows Kits/10/Lib/10.0.19041.0/um/x64")
+  # TODO: lld-link has a bug that it cannot infer the machine type
+  # correctly when /winsysroot is set while Windows libraries search paths
+  # are not explicitly defined.
+  # Explicitly set the machine type for now.
+  /machine:X64
+  /vfsoverlay:${LLVM_VFSOVERLAY}
+  /winsysroot:${LLVM_WINSYSROOT})
 string(REPLACE ";" " " WINDOWS_LINK_FLAGS "${WINDOWS_LINK_FLAGS}")
   endif()
 


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -88,14 +88,13 @@
   ${LLVM_WINSYSROOT})
 string(REPLACE ";" " " WINDOWS_COMPILER_FLAGS "${WINDOWS_COMPILER_FLAGS}")
 set(WINDOWS_LINK_FLAGS
-/vfsoverlay:${LLVM_VFSOVERLAY}
-# TODO: On Windows, linker is invoked by cmake instead of the clang-cl driver,
-# so we have to manually set the libpath. We use clang-cl driver if we can
-# and remove these libpath flags.
--libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/lib/x64"
--libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/atlmfc/lib/x64"
--libpath:"${LLVM_WINSYSROOT}/Windows Kits/10/Lib/10.0.19041.0/ucrt/x64"
--libpath:"${LLVM_WINSYSROOT}/Windows Kits/10/Lib/10.0.19041.0/um/x64")
+  # TODO: lld-link has a bug that it cannot infer the machine type
+  # correctly when /winsysroot is set while Windows libraries search paths
+  # are not explicitly defined.
+  # Explicitly set the machine type for now.
+  /machine:X64
+  /vfsoverlay:${LLVM_VFSOVERLAY}
+  /winsysroot:${LLVM_WINSYSROOT})
 string(REPLACE ";" " " WINDOWS_LINK_FLAGS "${WINDOWS_LINK_FLAGS}")
   endif()
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D142826: [Clang] Add -Wtype-limits to -Wextra for GCC compatibility

2023-02-07 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

There are also cases that this clang type-limit check will warn when checking 
if a enum type is larger than 0. For example, we are seeing warnings on ICU 
source code 
(https://github.com/unicode-org/icu/blob/8d5a97ae0f49f6974372736ca67db15c37522f6f/icu4c/source/i18n/displayoptions.cpp#L79)
 after this patch was landed.

  U_CAPI const char * U_EXPORT2
  udispopt_getGrammaticalCaseIdentifier(UDisplayOptionsGrammaticalCase 
grammaticalCase) {
  if (grammaticalCase >= 0 && grammaticalCase < 
UPRV_LENGTHOF(grammaticalCaseIds)) {
  return grammaticalCaseIds[grammaticalCase];
  }
  
  return grammaticalCaseIds[0];
  }

grammaticalCase is a enum. And whether enum type is unsigned or not does not 
seem to be strictly defined in C/C++ standard, it ups to the compiler to decide 
how enum type should be defined. In that case, this check is legit and 
shouldn't trigger an warning.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D142826/new/

https://reviews.llvm.org/D142826

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D143300: [randstruct] Don't allow implicit forward decl to stop struct randomization

2023-02-06 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

FYI, this patch looks like was pushed into a new "Main" branch instead of the 
actual "main" branch.
It causes git checkout failures on Windows, see error message:

  warning: encountered old-style '/ssl/certs/ca-bundle.crt' that should be 
'%(prefix)//ssl/certs/ca-bundle.crt'
  From https://llvm.googlesource.com/a/llvm-project
   * [new branch]Main   -> Main
  error: cannot lock ref 'refs/heads/main': is at 
f85a9a6452e8f49f9768d66a86434a88a5891614 but expected 
abbd256a810a0b0c92dda88a3050fc85cb604a9c
   ! abbd256a810a..14ca2e68ff4c  main   -> main  (unable to update local 
ref)

Windows use case aware but insensitive filesystem and 2 "main" branches will 
not work out.
See explanation at 
https://stackoverflow.com/questions/10068640/git-error-on-git-pull-unable-to-update-local-ref/66832220#66832220
I will attempt deleting the "Main" branch to correct this error.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143300/new/

https://reviews.llvm.org/D143300

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D141738: Add initial support for cross compile Windows runtimes under Linux when building Fuchsia clang toolchain

2023-02-06 Thread Haowei Wu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG5fcdab04c250: [Fuchsia] Build windows runtimes using cross 
compilation on Linux (authored by haowei).

Changed prior to commit:
  https://reviews.llvm.org/D141738?vs=493766=495281#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141738/new/

https://reviews.llvm.org/D141738

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  clang/cmake/caches/Fuchsia.cmake
  llvm/cmake/modules/AddLLVM.cmake
  llvm/cmake/modules/LLVMExternalProjectUtils.cmake

Index: llvm/cmake/modules/LLVMExternalProjectUtils.cmake
===
--- llvm/cmake/modules/LLVMExternalProjectUtils.cmake
+++ llvm/cmake/modules/LLVMExternalProjectUtils.cmake
@@ -93,7 +93,10 @@
   if(_cmake_system_name STREQUAL Darwin)
 list(APPEND ARG_TOOLCHAIN_TOOLS llvm-libtool-darwin llvm-lipo)
   elseif(is_msvc_target)
-list(APPEND ARG_TOOLCHAIN_TOOLS llvm-lib)
+list(APPEND ARG_TOOLCHAIN_TOOLS llvm-lib llvm-rc)
+if (LLVM_ENABLE_LIBXML2)
+  list(APPEND ARG_TOOLCHAIN_TOOLS llvm-mt)
+endif()
   else()
 # TODO: These tools don't fully support Mach-O format yet.
 list(APPEND ARG_TOOLCHAIN_TOOLS llvm-objcopy llvm-strip llvm-readelf)
@@ -212,6 +215,12 @@
 if(llvm-readelf IN_LIST TOOLCHAIN_TOOLS)
   list(APPEND compiler_args -DCMAKE_READELF=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-readelf${CMAKE_EXECUTABLE_SUFFIX})
 endif()
+if(llvm-mt IN_LIST TOOLCHAIN_TOOLS AND is_msvc_target)
+  list(APPEND compiler_args -DCMAKE_MT=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-mt${CMAKE_EXECUTABLE_SUFFIX})
+endif()
+if(llvm-rc IN_LIST TOOLCHAIN_TOOLS AND is_msvc_target)
+  list(APPEND compiler_args -DCMAKE_RC_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-rc${CMAKE_EXECUTABLE_SUFFIX})
+endif()
 list(APPEND ARG_DEPENDS ${TOOLCHAIN_TOOLS})
   endif()
 
Index: llvm/cmake/modules/AddLLVM.cmake
===
--- llvm/cmake/modules/AddLLVM.cmake
+++ llvm/cmake/modules/AddLLVM.cmake
@@ -1315,6 +1315,10 @@
 strings
 strip
 )
+  # Build llvm-mt if libxml2 is enabled. Can be used by runtimes.
+  if (LLVM_ENABLE_LIBXML2)
+list(APPEND LLVM_TOOLCHAIN_TOOLS llvm-mt)
+  endif()
 endif()
 
 macro(llvm_add_tool project name)
Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -34,6 +34,8 @@
   CMAKE_MODULE_LINKER_FLAGS
   CMAKE_SHARED_LINKER_FLAGS
   CMAKE_EXE_LINKER_FLAGS
+  LLVM_WINSYSROOT
+  LLVM_VFSOVERLAY
 )
 
 foreach(variable ${_FUCHSIA_BOOTSTRAP_PASSTHROUGH})
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -69,12 +69,44 @@
   set(RUNTIMES_CMAKE_ARGS "-DCMAKE_OSX_DEPLOYMENT_TARGET=10.13;-DCMAKE_OSX_ARCHITECTURES=arm64|x86_64" CACHE STRING "")
 endif()
 
-if(WIN32)
+if(WIN32 OR LLVM_WINSYSROOT)
+  if((NOT WIN32) AND (NOT LLVM_VFSOVERLAY))
+message(FATAL_ERROR "LLVM_VFSOVERLAY should be defined.")
+  endif()
   set(target "x86_64-pc-windows-msvc")
 
+  if (LLVM_WINSYSROOT)
+set(WINDOWS_COMPILER_FLAGS
+  -Xclang
+  -ivfsoverlay
+  -Xclang
+  ${LLVM_VFSOVERLAY}
+  # TODO: /winsysroot should be set by HandleLLVMOptions.cmake automatically
+  # but it current has a bug that prevents it from working under cross
+  # compilation. Set this flag manually for now.
+  /winsysroot
+  ${LLVM_WINSYSROOT})
+string(REPLACE ";" " " WINDOWS_COMPILER_FLAGS "${WINDOWS_COMPILER_FLAGS}")
+set(WINDOWS_LINK_FLAGS
+/vfsoverlay:${LLVM_VFSOVERLAY}
+# TODO: On Windows, linker is invoked by cmake instead of the clang-cl driver,
+# so we have to manually set the libpath. We use clang-cl driver if we can
+# and remove these libpath flags.
+-libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/lib/x64"
+-libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/atlmfc/lib/x64"
+-libpath:"${LLVM_WINSYSROOT}/Windows Kits/10/Lib/10.0.19041.0/ucrt/x64"
+-libpath:"${LLVM_WINSYSROOT}/Windows Kits/10/Lib/10.0.19041.0/um/x64")
+string(REPLACE ";" " " WINDOWS_LINK_FLAGS "${WINDOWS_LINK_FLAGS}")
+  endif()
+
   list(APPEND BUILTIN_TARGETS "${target}")
   set(BUILTINS_${target}_CMAKE_SYSTEM_NAME Windows CACHE STRING "")
   set(BUILTINS_${target}_CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "")
+  set(BUILTINS_${target}_CMAKE_C_FLAGS ${WINDOWS_COMPILER_FLAGS} CACHE STRING "")
+  set(BUILTINS_${target}_CMAKE_CXX_FLAGS ${WINDOWS_COMPILER_FLAGS} CACHE STRING "")
+  set(BUILTINS_${target}_CMAKE_EXE_LINKER_FLAGS ${WINDOWS_LINK_FLAGS} CACHE STRING "")
+  

[PATCH] D143025: [Clang] Add llvm-mt and llvm-rc to Clang bootstrap dependency

2023-02-06 Thread Haowei Wu via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGdc1c8917afd3: [Clang] Add llvm-mt and llvm-rc to Clang 
bootstrap dependency (authored by haowei).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143025/new/

https://reviews.llvm.org/D143025

Files:
  clang/CMakeLists.txt


Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -595,6 +595,14 @@
 add_dependencies(clang-bootstrap-deps lld)
   endif()
 
+  if (WIN32)
+# Build llvm-rc and llvm-mt which are needed by the Windows build.
+add_dependencies(clang-bootstrap-deps llvm-rc)
+if(LLVM_ENABLE_LIBXML2)
+  add_dependencies(clang-bootstrap-deps llvm-mt)
+endif()
+  endif()
+
   # If the next stage is LTO we need to depend on LTO and possibly lld or 
LLVMgold
   if(BOOTSTRAP_LLVM_ENABLE_LTO OR LLVM_ENABLE_LTO AND NOT 
LLVM_BUILD_INSTRUMENTED)
 if(APPLE)


Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -595,6 +595,14 @@
 add_dependencies(clang-bootstrap-deps lld)
   endif()
 
+  if (WIN32)
+# Build llvm-rc and llvm-mt which are needed by the Windows build.
+add_dependencies(clang-bootstrap-deps llvm-rc)
+if(LLVM_ENABLE_LIBXML2)
+  add_dependencies(clang-bootstrap-deps llvm-mt)
+endif()
+  endif()
+
   # If the next stage is LTO we need to depend on LTO and possibly lld or LLVMgold
   if(BOOTSTRAP_LLVM_ENABLE_LTO OR LLVM_ENABLE_LTO AND NOT LLVM_BUILD_INSTRUMENTED)
 if(APPLE)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D143025: [Clang] Add llvm-mt and llvm-rc to Clang bootstrap dependency

2023-02-06 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 495221.
haowei marked an inline comment as done.
haowei retitled this revision from "[Fuchsia] Add llvm-mt and llvm-rc to clang 
bootstrap dependency" to "[Clang] Add llvm-mt and llvm-rc to Clang bootstrap 
dependency".
haowei edited the summary of this revision.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143025/new/

https://reviews.llvm.org/D143025

Files:
  clang/CMakeLists.txt


Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -595,6 +595,14 @@
 add_dependencies(clang-bootstrap-deps lld)
   endif()
 
+  if (WIN32)
+# Build llvm-rc and llvm-mt which are needed by the Windows build.
+add_dependencies(clang-bootstrap-deps llvm-rc)
+if(LLVM_ENABLE_LIBXML2)
+  add_dependencies(clang-bootstrap-deps llvm-mt)
+endif()
+  endif()
+
   # If the next stage is LTO we need to depend on LTO and possibly lld or 
LLVMgold
   if(BOOTSTRAP_LLVM_ENABLE_LTO OR LLVM_ENABLE_LTO AND NOT 
LLVM_BUILD_INSTRUMENTED)
 if(APPLE)


Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -595,6 +595,14 @@
 add_dependencies(clang-bootstrap-deps lld)
   endif()
 
+  if (WIN32)
+# Build llvm-rc and llvm-mt which are needed by the Windows build.
+add_dependencies(clang-bootstrap-deps llvm-rc)
+if(LLVM_ENABLE_LIBXML2)
+  add_dependencies(clang-bootstrap-deps llvm-mt)
+endif()
+  endif()
+
   # If the next stage is LTO we need to depend on LTO and possibly lld or LLVMgold
   if(BOOTSTRAP_LLVM_ENABLE_LTO OR LLVM_ENABLE_LTO AND NOT LLVM_BUILD_INSTRUMENTED)
 if(APPLE)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D143288: [Fuchsia] Simplified the stage2 build setup

2023-02-06 Thread Haowei Wu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG630266aed342: [Fuchsia] Simplified the stage2 build setup 
(authored by haowei).

Changed prior to commit:
  https://reviews.llvm.org/D143288?vs=494694=495216#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143288/new/

https://reviews.llvm.org/D143288

Files:
  clang/cmake/caches/Fuchsia.cmake


Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -17,6 +17,34 @@
 set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "")
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
 
+# Passthrough stage1 flags to stage1.
+set(_FUCHSIA_BOOTSTRAP_PASSTHROUGH
+  LLVM_ENABLE_ZLIB
+  ZLIB_INCLUDE_DIR
+  ZLIB_LIBRARY
+  LLVM_ENABLE_ZSTD
+  zstd_DIR
+  LLVM_ENABLE_LIBXML2
+  LibXml2_ROOT
+  LLVM_ENABLE_CURL
+  CURL_ROOT
+  OpenSSL_ROOT
+  CMAKE_FIND_PACKAGE_PREFER_CONFIG
+  CMAKE_SYSROOT
+  CMAKE_MODULE_LINKER_FLAGS
+  CMAKE_SHARED_LINKER_FLAGS
+  CMAKE_EXE_LINKER_FLAGS
+)
+
+foreach(variable ${_FUCHSIA_BOOTSTRAP_PASSTHROUGH})
+  get_property(is_value_set CACHE ${variable} PROPERTY VALUE SET)
+  if(${is_value_set})
+get_property(value CACHE ${variable} PROPERTY VALUE)
+get_property(type CACHE ${variable} PROPERTY TYPE)
+set(BOOTSTRAP_${variable} "${value}" CACHE ${type} "")
+  endif()
+endforeach()
+
 if(WIN32)
   set(LLVM_USE_CRT_RELEASE "MT" CACHE STRING "")
 endif()
@@ -105,12 +133,6 @@
   endif()
 endif()
 
-if(UNIX)
-  set(BOOTSTRAP_CMAKE_SHARED_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
-  set(BOOTSTRAP_CMAKE_MODULE_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
-  set(BOOTSTRAP_CMAKE_EXE_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
-endif()
-
 set(BOOTSTRAP_LLVM_ENABLE_LLD ON CACHE BOOL "")
 set(BOOTSTRAP_LLVM_ENABLE_LTO ON CACHE BOOL "")
 


Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -17,6 +17,34 @@
 set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "")
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
 
+# Passthrough stage1 flags to stage1.
+set(_FUCHSIA_BOOTSTRAP_PASSTHROUGH
+  LLVM_ENABLE_ZLIB
+  ZLIB_INCLUDE_DIR
+  ZLIB_LIBRARY
+  LLVM_ENABLE_ZSTD
+  zstd_DIR
+  LLVM_ENABLE_LIBXML2
+  LibXml2_ROOT
+  LLVM_ENABLE_CURL
+  CURL_ROOT
+  OpenSSL_ROOT
+  CMAKE_FIND_PACKAGE_PREFER_CONFIG
+  CMAKE_SYSROOT
+  CMAKE_MODULE_LINKER_FLAGS
+  CMAKE_SHARED_LINKER_FLAGS
+  CMAKE_EXE_LINKER_FLAGS
+)
+
+foreach(variable ${_FUCHSIA_BOOTSTRAP_PASSTHROUGH})
+  get_property(is_value_set CACHE ${variable} PROPERTY VALUE SET)
+  if(${is_value_set})
+get_property(value CACHE ${variable} PROPERTY VALUE)
+get_property(type CACHE ${variable} PROPERTY TYPE)
+set(BOOTSTRAP_${variable} "${value}" CACHE ${type} "")
+  endif()
+endforeach()
+
 if(WIN32)
   set(LLVM_USE_CRT_RELEASE "MT" CACHE STRING "")
 endif()
@@ -105,12 +133,6 @@
   endif()
 endif()
 
-if(UNIX)
-  set(BOOTSTRAP_CMAKE_SHARED_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
-  set(BOOTSTRAP_CMAKE_MODULE_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
-  set(BOOTSTRAP_CMAKE_EXE_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
-endif()
-
 set(BOOTSTRAP_LLVM_ENABLE_LLD ON CACHE BOOL "")
 set(BOOTSTRAP_LLVM_ENABLE_LTO ON CACHE BOOL "")
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D143025: [Fuchsia] Add llvm-mt and llvm-rc to clang bootstrap dependency

2023-02-03 Thread Haowei Wu via Phabricator via cfe-commits
haowei marked 2 inline comments as done.
haowei added inline comments.



Comment at: clang/cmake/caches/Fuchsia.cmake:170-171
   runtimes
+  llvm-rc
+  llvm-mt
   CACHE STRING "")

phosek wrote:
> Could we do this in 
> https://github.com/llvm/llvm-project/blob/98f0e4f611b40c902cb0df3ef080ae2c00e862d4/clang/CMakeLists.txt#L619?
>  That would be more consistent with other tools such as `llvm-ar`.
I add it into clang/CMakeList.txt file.
the llvm-rc and llvm-mt will only be added to bootstrap tool list on Windows. 
As they will be required to build Windows runtime for the bootstrap toolchain. 
On Linux, the runtime for the bootstrap toolchain is Linux only so they are not 
required.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143025/new/

https://reviews.llvm.org/D143025

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D143025: [Fuchsia] Add llvm-mt and llvm-rc to clang bootstrap dependency

2023-02-03 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 494755.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143025/new/

https://reviews.llvm.org/D143025

Files:
  clang/CMakeLists.txt


Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -595,6 +595,17 @@
 add_dependencies(clang-bootstrap-deps lld)
   endif()
 
+  if (WIN32)
+# Build llvm-rc on Windows so it can be used to build
+# bootstrap runtime.
+add_dependencies(clang-bootstrap-deps llvm-rc)
+if(LLVM_ENABLE_LIBXML2)
+  # Build llvm-mt if libxml2 is enabled and available.
+  # the existance of libxml2 is checked in llvm/cmake/config-ix.cmake.
+  add_dependencies(clang-bootstrap-deps llvm-mt)
+endif()
+  endif()
+
   # If the next stage is LTO we need to depend on LTO and possibly lld or 
LLVMgold
   if(BOOTSTRAP_LLVM_ENABLE_LTO OR LLVM_ENABLE_LTO AND NOT 
LLVM_BUILD_INSTRUMENTED)
 if(APPLE)


Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -595,6 +595,17 @@
 add_dependencies(clang-bootstrap-deps lld)
   endif()
 
+  if (WIN32)
+# Build llvm-rc on Windows so it can be used to build
+# bootstrap runtime.
+add_dependencies(clang-bootstrap-deps llvm-rc)
+if(LLVM_ENABLE_LIBXML2)
+  # Build llvm-mt if libxml2 is enabled and available.
+  # the existance of libxml2 is checked in llvm/cmake/config-ix.cmake.
+  add_dependencies(clang-bootstrap-deps llvm-mt)
+endif()
+  endif()
+
   # If the next stage is LTO we need to depend on LTO and possibly lld or LLVMgold
   if(BOOTSTRAP_LLVM_ENABLE_LTO OR LLVM_ENABLE_LTO AND NOT LLVM_BUILD_INSTRUMENTED)
 if(APPLE)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D143288: [Fuchsia] Simplified the stage2 build setup

2023-02-03 Thread Haowei Wu via Phabricator via cfe-commits
haowei created this revision.
haowei added a reviewer: phosek.
Herald added a subscriber: abrachet.
Herald added a project: All.
haowei requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch simplified the BOOTSTRAP_ flags, allowing them to be passed through 
from regular flags.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143288

Files:
  clang/cmake/caches/Fuchsia.cmake


Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -17,6 +17,34 @@
 set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "")
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
 
+# Passthrough stage1 flags to stage1.
+set(_FUCHSIA_BOOTSTRAP_PASSTHROUGH
+  LLVM_ENABLE_ZLIB
+  ZLIB_INCLUDE_DIR
+  ZLIB_LIBRARY
+  LLVM_ENABLE_ZSTD
+  zstd_DIR
+  LLVM_ENABLE_LIBXML2
+  LibXml2_ROOT
+  LLVM_ENABLE_CURL
+  CURL_ROOT
+  OpenSSL_ROOT
+  CMAKE_FIND_PACKAGE_PREFER_CONFIG
+  CMAKE_SYSROOT
+  CMAKE_MODULE_LINKER_FLAGS
+  CMAKE_SHARED_LINKER_FLAGS
+  CMAKE_EXE_LINKER_FLAGS
+)
+
+foreach(variable ${_FUCHSIA_BOOTSTRAP_PASSTHROUGH})
+  get_property(is_value_set CACHE ${variable} PROPERTY VALUE SET)
+  if(${is_value_set})
+get_property(value CACHE ${variable} PROPERTY VALUE)
+get_property(type CACHE ${variable} PROPERTY TYPE)
+set(BOOTSTRAP_${variable} "${value}" CACHE ${type} "")
+  endif()
+endforeach()
+
 if(WIN32)
   set(LLVM_USE_CRT_RELEASE "MT" CACHE STRING "")
 endif()


Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -17,6 +17,34 @@
 set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "")
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
 
+# Passthrough stage1 flags to stage1.
+set(_FUCHSIA_BOOTSTRAP_PASSTHROUGH
+  LLVM_ENABLE_ZLIB
+  ZLIB_INCLUDE_DIR
+  ZLIB_LIBRARY
+  LLVM_ENABLE_ZSTD
+  zstd_DIR
+  LLVM_ENABLE_LIBXML2
+  LibXml2_ROOT
+  LLVM_ENABLE_CURL
+  CURL_ROOT
+  OpenSSL_ROOT
+  CMAKE_FIND_PACKAGE_PREFER_CONFIG
+  CMAKE_SYSROOT
+  CMAKE_MODULE_LINKER_FLAGS
+  CMAKE_SHARED_LINKER_FLAGS
+  CMAKE_EXE_LINKER_FLAGS
+)
+
+foreach(variable ${_FUCHSIA_BOOTSTRAP_PASSTHROUGH})
+  get_property(is_value_set CACHE ${variable} PROPERTY VALUE SET)
+  if(${is_value_set})
+get_property(value CACHE ${variable} PROPERTY VALUE)
+get_property(type CACHE ${variable} PROPERTY TYPE)
+set(BOOTSTRAP_${variable} "${value}" CACHE ${type} "")
+  endif()
+endforeach()
+
 if(WIN32)
   set(LLVM_USE_CRT_RELEASE "MT" CACHE STRING "")
 endif()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D141738: Add initial support for cross compile Windows runtimes under Linux when building Fuchsia clang toolchain

2023-02-02 Thread Haowei Wu via Phabricator via cfe-commits
haowei added inline comments.



Comment at: clang/cmake/caches/Fuchsia-stage2.cmake:95
+# and remove these libpath flags.
+-libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/lib/x64"
+-libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/atlmfc/lib/x64"

phosek wrote:
> phosek wrote:
> > haowei wrote:
> > > thakis wrote:
> > > > You can tell cmake to invoke lld-link, which has a /winsysroot: flag.
> > > What would be a good way to make CMake invoke lld-link (or through 
> > > clang-cl) instead of using `cmake vs_link` in this situation?
> > > We thought about using
> > > 
> > > ```
> > > set(CMAKE_${LANG}_SIMULATE_ID "MSVC")
> > > set(CMAKE_${LANG}_COMPILER_FRONTEND_VARIANT "GNU")
> > > ```
> > > 
> > > but I don't feel great about changing variables that are not suppose to 
> > > change. 
> > Wouldn't CMake use `lld-link` if you set `CMAKE_LINKER=lld-link`. We 
> > already do this in 
> > https://github.com/llvm/llvm-project/blob/0e09bb8b143c80426c497a924ee4fa57a26af6b5/llvm/cmake/modules/LLVMExternalProjectUtils.cmake#L179
> >  which is used by the bootstrapping build so you should be able to use 
> > `/winsysroot:` here.
> @haowei have tried this suggestion?
I tried:

```
FAILED: 
runtimes/runtimes-x86_64-pc-windows-msvc-stamps/runtimes-x86_64-pc-windows-msvc-configure
 
/mnt/nvme_sec/SRC/llvm-project/build-lldlink/runtimes/runtimes-x86_64-pc-windows-msvc-stamps/runtimes-x86_64-pc-windows-msvc-configure
 
cd 
/mnt/nvme_sec/SRC/llvm-project/build-lldlink/runtimes/runtimes-x86_64-pc-windows-msvc-bins
 && /mnt/nvme_sec/SRC/llvm-prebuilts/cmake/linux-amd64/bin/cmake \
-DCMAKE_C_COMPILER=/mnt/nvme_sec/SRC/llvm-project/build-lldlink/./bin/clang-cl \
-DCMAKE_CXX_COMPILER=/mnt/nvme_sec/SRC/llvm-project/build-lldlink/./bin/clang-cl
 \
-DCMAKE_ASM_COMPILER=/mnt/nvme_sec/SRC/llvm-project/build-lldlink/./bin/clang-cl
 \
-DCMAKE_LINKER=/mnt/nvme_sec/SRC/llvm-project/build-lldlink/./bin/lld-link \


```

But cmake is still using vs_link, see:

```
FAILED: cmTC_a05d1.exe 
: && /mnt/nvme_sec/SRC/llvm-prebuilts/cmake/linux-amd64/bin/cmake -E 
vs_link_exe --intdir=CMakeFiles/cmTC_a05d1.dir 
--rc=/mnt/nvme_sec/SRC/llvm-project/build-lldlink/./bin/llvm-rc 
--mt=/mnt/nvme_sec/SRC/llvm-project/build-lldlink/bin/llvm-mt --manifests  -- 
/mnt/nvme_sec/SRC/llvm-project/build-lldlink/bin/lld-link /nologo 
CMakeFiles/cmTC_a05d1.dir/CMakeCCompilerABI.c.obj  /out:cmTC_a05d1.exe 
/implib:cmTC_a05d1.lib /pdb:cmTC_a05d1.pdb /version:0.0 
/vfsoverlay:/mnt/nvme_sec/SRC/WinSDK/winsdk-cipd/llvm-vfsoverlay.yaml  /debug 
/INCREMENTAL /subsystem:console
```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141738/new/

https://reviews.llvm.org/D141738

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D143025: [Fuchsia] Add llvm-mt and llvm-rc to clang bootstrap dependency

2023-02-02 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 494364.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143025/new/

https://reviews.llvm.org/D143025

Files:
  clang/cmake/caches/Fuchsia.cmake


Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -17,6 +17,34 @@
 set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "")
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
 
+# Passthrough stage1 flags to stage1.
+set(_FUCHSIA_BOOTSTRAP_PASSTHROUGH
+  LLVM_ENABLE_ZLIB
+  ZLIB_INCLUDE_DIR
+  ZLIB_LIBRARY
+  LLVM_ENABLE_ZSTD
+  zstd_DIR
+  LLVM_ENABLE_LIBXML2
+  LibXml2_ROOT
+  LLVM_ENABLE_CURL
+  CURL_ROOT
+  OpenSSL_ROOT
+  CMAKE_FIND_PACKAGE_PREFER_CONFIG
+  CMAKE_SYSROOT
+  CMAKE_MODULE_LINKER_FLAGS
+  CMAKE_SHARED_LINKER_FLAGS
+  CMAKE_EXE_LINKER_FLAGS
+)
+
+foreach(variable ${_FUCHSIA_BOOTSTRAP_PASSTHROUGH})
+  get_property(is_value_set CACHE ${variable} PROPERTY VALUE SET)
+  if(${is_value_set})
+get_property(value CACHE ${variable} PROPERTY VALUE)
+get_property(type CACHE ${variable} PROPERTY TYPE)
+set(BOOTSTRAP_${variable} "${value}" CACHE ${type} "")
+  endif()
+endforeach()
+
 if(WIN32)
   set(LLVM_USE_CRT_RELEASE "MT" CACHE STRING "")
 endif()
@@ -105,12 +133,6 @@
   endif()
 endif()
 
-if(UNIX)
-  set(BOOTSTRAP_CMAKE_SHARED_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
-  set(BOOTSTRAP_CMAKE_MODULE_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
-  set(BOOTSTRAP_CMAKE_EXE_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
-endif()
-
 set(BOOTSTRAP_LLVM_ENABLE_LLD ON CACHE BOOL "")
 set(BOOTSTRAP_LLVM_ENABLE_LTO ON CACHE BOOL "")
 
@@ -145,6 +167,8 @@
 set(CLANG_BOOTSTRAP_EXTRA_DEPS
   builtins
   runtimes
+  llvm-rc
+  llvm-mt
   CACHE STRING "")
 set(CLANG_BOOTSTRAP_CMAKE_ARGS
   ${EXTRA_ARGS}


Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -17,6 +17,34 @@
 set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "")
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
 
+# Passthrough stage1 flags to stage1.
+set(_FUCHSIA_BOOTSTRAP_PASSTHROUGH
+  LLVM_ENABLE_ZLIB
+  ZLIB_INCLUDE_DIR
+  ZLIB_LIBRARY
+  LLVM_ENABLE_ZSTD
+  zstd_DIR
+  LLVM_ENABLE_LIBXML2
+  LibXml2_ROOT
+  LLVM_ENABLE_CURL
+  CURL_ROOT
+  OpenSSL_ROOT
+  CMAKE_FIND_PACKAGE_PREFER_CONFIG
+  CMAKE_SYSROOT
+  CMAKE_MODULE_LINKER_FLAGS
+  CMAKE_SHARED_LINKER_FLAGS
+  CMAKE_EXE_LINKER_FLAGS
+)
+
+foreach(variable ${_FUCHSIA_BOOTSTRAP_PASSTHROUGH})
+  get_property(is_value_set CACHE ${variable} PROPERTY VALUE SET)
+  if(${is_value_set})
+get_property(value CACHE ${variable} PROPERTY VALUE)
+get_property(type CACHE ${variable} PROPERTY TYPE)
+set(BOOTSTRAP_${variable} "${value}" CACHE ${type} "")
+  endif()
+endforeach()
+
 if(WIN32)
   set(LLVM_USE_CRT_RELEASE "MT" CACHE STRING "")
 endif()
@@ -105,12 +133,6 @@
   endif()
 endif()
 
-if(UNIX)
-  set(BOOTSTRAP_CMAKE_SHARED_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
-  set(BOOTSTRAP_CMAKE_MODULE_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
-  set(BOOTSTRAP_CMAKE_EXE_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
-endif()
-
 set(BOOTSTRAP_LLVM_ENABLE_LLD ON CACHE BOOL "")
 set(BOOTSTRAP_LLVM_ENABLE_LTO ON CACHE BOOL "")
 
@@ -145,6 +167,8 @@
 set(CLANG_BOOTSTRAP_EXTRA_DEPS
   builtins
   runtimes
+  llvm-rc
+  llvm-mt
   CACHE STRING "")
 set(CLANG_BOOTSTRAP_CMAKE_ARGS
   ${EXTRA_ARGS}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D141738: Add initial support for cross compile Windows runtimes under Linux when building Fuchsia clang toolchain

2023-01-31 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 493766.
haowei added a comment.

Correct dependency issues on llvm-mt


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141738/new/

https://reviews.llvm.org/D141738

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  clang/cmake/caches/Fuchsia.cmake
  llvm/cmake/modules/AddLLVM.cmake
  llvm/cmake/modules/LLVMExternalProjectUtils.cmake

Index: llvm/cmake/modules/LLVMExternalProjectUtils.cmake
===
--- llvm/cmake/modules/LLVMExternalProjectUtils.cmake
+++ llvm/cmake/modules/LLVMExternalProjectUtils.cmake
@@ -93,7 +93,10 @@
   if(_cmake_system_name STREQUAL Darwin)
 list(APPEND ARG_TOOLCHAIN_TOOLS llvm-libtool-darwin llvm-lipo)
   elseif(is_msvc_target)
-list(APPEND ARG_TOOLCHAIN_TOOLS llvm-lib)
+list(APPEND ARG_TOOLCHAIN_TOOLS llvm-lib llvm-rc)
+if (LLVM_ENABLE_LIBXML2)
+  list(APPEND ARG_TOOLCHAIN_TOOLS llvm-mt)
+endif()
   else()
 # TODO: These tools don't fully support Mach-O format yet.
 list(APPEND ARG_TOOLCHAIN_TOOLS llvm-objcopy llvm-strip llvm-readelf)
@@ -212,6 +215,12 @@
 if(llvm-readelf IN_LIST TOOLCHAIN_TOOLS)
   list(APPEND compiler_args -DCMAKE_READELF=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-readelf${CMAKE_EXECUTABLE_SUFFIX})
 endif()
+if(llvm-mt IN_LIST TOOLCHAIN_TOOLS AND is_msvc_target)
+  list(APPEND compiler_args -DCMAKE_MT=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-mt${CMAKE_EXECUTABLE_SUFFIX})
+endif()
+if(llvm-rc IN_LIST TOOLCHAIN_TOOLS AND is_msvc_target)
+  list(APPEND compiler_args -DCMAKE_RC_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-rc${CMAKE_EXECUTABLE_SUFFIX})
+endif()
 list(APPEND ARG_DEPENDS ${TOOLCHAIN_TOOLS})
   endif()
 
Index: llvm/cmake/modules/AddLLVM.cmake
===
--- llvm/cmake/modules/AddLLVM.cmake
+++ llvm/cmake/modules/AddLLVM.cmake
@@ -1315,6 +1315,10 @@
 strings
 strip
 )
+  # Build llvm-mt if libxml2 is enabled. Can be used by runtimes.
+  if (LLVM_ENABLE_LIBXML2)
+list(APPEND LLVM_TOOLCHAIN_TOOLS llvm-mt)
+  endif()
 endif()
 
 macro(llvm_add_tool project name)
Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -29,6 +29,8 @@
   CMAKE_MODULE_LINKER_FLAGS
   CMAKE_SHARED_LINKER_FLAGS
   CMAKE_EXE_LINKER_FLAGS
+  LLVM_WINSYSROOT
+  LLVM_VFSOVERLAY
 )
 
 set(_FUCHSIA_BOOTSTRAP_PASSTHROUGH_BOOL
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -69,12 +69,44 @@
   set(RUNTIMES_CMAKE_ARGS "-DCMAKE_OSX_DEPLOYMENT_TARGET=10.13;-DCMAKE_OSX_ARCHITECTURES=arm64|x86_64" CACHE STRING "")
 endif()
 
-if(WIN32)
+if(WIN32 OR LLVM_WINSYSROOT)
+  if((NOT WIN32) AND (NOT LLVM_VFSOVERLAY))
+message(FATAL_ERROR "LLVM_VFSOVERLAY should be defined.")
+  endif()
   set(target "x86_64-pc-windows-msvc")
 
+  if (LLVM_WINSYSROOT)
+set(WINDOWS_COMPILER_FLAGS
+  -Xclang
+  -ivfsoverlay
+  -Xclang
+  ${LLVM_VFSOVERLAY}
+  # TODO: /winsysroot should be set by HandleLLVMOptions.cmake automatically
+  # but it current has a bug that prevents it from working under cross
+  # compilation. Set this flag manually for now.
+  /winsysroot
+  ${LLVM_WINSYSROOT})
+string(REPLACE ";" " " WINDOWS_COMPILER_FLAGS "${WINDOWS_COMPILER_FLAGS}")
+set(WINDOWS_LINK_FLAGS
+/vfsoverlay:${LLVM_VFSOVERLAY}
+# TODO: On Windows, linker is invoked by cmake instead of the clang-cl driver,
+# so we have to manually set the libpath. We use clang-cl driver if we can
+# and remove these libpath flags.
+-libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/lib/x64"
+-libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/atlmfc/lib/x64"
+-libpath:"${LLVM_WINSYSROOT}/Windows Kits/10/Lib/10.0.19041.0/ucrt/x64"
+-libpath:"${LLVM_WINSYSROOT}/Windows Kits/10/Lib/10.0.19041.0/um/x64")
+string(REPLACE ";" " " WINDOWS_LINK_FLAGS "${WINDOWS_LINK_FLAGS}")
+  endif()
+
   list(APPEND BUILTIN_TARGETS "${target}")
   set(BUILTINS_${target}_CMAKE_SYSTEM_NAME Windows CACHE STRING "")
   set(BUILTINS_${target}_CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "")
+  set(BUILTINS_${target}_CMAKE_C_FLAGS ${WINDOWS_COMPILER_FLAGS} CACHE STRING "")
+  set(BUILTINS_${target}_CMAKE_CXX_FLAGS ${WINDOWS_COMPILER_FLAGS} CACHE STRING "")
+  set(BUILTINS_${target}_CMAKE_EXE_LINKER_FLAGS ${WINDOWS_LINK_FLAGS} CACHE STRING "")
+  set(BUILTINS_${target}_CMAKE_SHARED_LINKER_FLAGS ${WINDOWS_LINK_FLAGS} CACHE STRING "")
+  set(BUILTINS_${target}_CMAKE_MODULE_LINKER_FLAGS ${WINDOWS_LINK_FLAGS} CACHE STRING "")
 
   list(APPEND 

[PATCH] D143025: [Fuchsia] Add llvm-mt and llvm-rc to clang bootstrap dependency

2023-01-31 Thread Haowei Wu via Phabricator via cfe-commits
haowei created this revision.
haowei added a reviewer: phosek.
Herald added a subscriber: abrachet.
Herald added a project: All.
haowei requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

llvm-mt and llvm-rc tools are capable of building clang for Windows and 
compiler runtimes. We should use them in clang bootstrap build instead of 
relying on mt and rc provided by the host toolchain.
This patch also simplified the BOOTSTRAP_ flags, allowing them to be pass 
through from regular flags.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143025

Files:
  clang/cmake/caches/Fuchsia.cmake


Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -17,6 +17,40 @@
 set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "")
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
 
+# Passthrough stage1 flags to stage1.
+set(_FUCHSIA_BOOTSTRAP_PASSTHROUGH_STRINGS
+  ZLIB_INCLUDE_DIR
+  ZLIB_LIBRARY
+  zstd_DIR
+  LibXml2_ROOT
+  CURL_ROOT
+  OpenSSL_ROOT
+  CMAKE_SYSROOT
+  CMAKE_MODULE_LINKER_FLAGS
+  CMAKE_SHARED_LINKER_FLAGS
+  CMAKE_EXE_LINKER_FLAGS
+)
+
+set(_FUCHSIA_BOOTSTRAP_PASSTHROUGH_BOOL
+  LLVM_ENABLE_ZLIB
+  LLVM_ENABLE_ZSTD
+  LLVM_ENABLE_LIBXML2
+  LLVM_ENABLE_CURL
+  CMAKE_FIND_PACKAGE_PREFER_CONFIG
+)
+
+foreach(variableName ${_FUCHSIA_BOOTSTRAP_PASSTHROUGH_STRINGS})
+  if(DEFINED ${variableName})
+set(BOOTSTRAP_${variableName} "${${variableName}}" CACHE STRING "")
+  endif()
+endforeach()
+
+foreach(variableName ${_FUCHSIA_BOOTSTRAP_PASSTHROUGH_BOOL})
+  if(DEFINED ${variableName})
+set(BOOTSTRAP_${variableName} "${${variableName}}" CACHE BOOL "")
+  endif()
+endforeach()
+
 if(WIN32)
   set(LLVM_USE_CRT_RELEASE "MT" CACHE STRING "")
 endif()
@@ -105,12 +139,6 @@
   endif()
 endif()
 
-if(UNIX)
-  set(BOOTSTRAP_CMAKE_SHARED_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
-  set(BOOTSTRAP_CMAKE_MODULE_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
-  set(BOOTSTRAP_CMAKE_EXE_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
-endif()
-
 set(BOOTSTRAP_LLVM_ENABLE_LLD ON CACHE BOOL "")
 set(BOOTSTRAP_LLVM_ENABLE_LTO ON CACHE BOOL "")
 
@@ -145,6 +173,8 @@
 set(CLANG_BOOTSTRAP_EXTRA_DEPS
   builtins
   runtimes
+  llvm-rc
+  llvm-mt
   CACHE STRING "")
 set(CLANG_BOOTSTRAP_CMAKE_ARGS
   ${EXTRA_ARGS}


Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -17,6 +17,40 @@
 set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "")
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
 
+# Passthrough stage1 flags to stage1.
+set(_FUCHSIA_BOOTSTRAP_PASSTHROUGH_STRINGS
+  ZLIB_INCLUDE_DIR
+  ZLIB_LIBRARY
+  zstd_DIR
+  LibXml2_ROOT
+  CURL_ROOT
+  OpenSSL_ROOT
+  CMAKE_SYSROOT
+  CMAKE_MODULE_LINKER_FLAGS
+  CMAKE_SHARED_LINKER_FLAGS
+  CMAKE_EXE_LINKER_FLAGS
+)
+
+set(_FUCHSIA_BOOTSTRAP_PASSTHROUGH_BOOL
+  LLVM_ENABLE_ZLIB
+  LLVM_ENABLE_ZSTD
+  LLVM_ENABLE_LIBXML2
+  LLVM_ENABLE_CURL
+  CMAKE_FIND_PACKAGE_PREFER_CONFIG
+)
+
+foreach(variableName ${_FUCHSIA_BOOTSTRAP_PASSTHROUGH_STRINGS})
+  if(DEFINED ${variableName})
+set(BOOTSTRAP_${variableName} "${${variableName}}" CACHE STRING "")
+  endif()
+endforeach()
+
+foreach(variableName ${_FUCHSIA_BOOTSTRAP_PASSTHROUGH_BOOL})
+  if(DEFINED ${variableName})
+set(BOOTSTRAP_${variableName} "${${variableName}}" CACHE BOOL "")
+  endif()
+endforeach()
+
 if(WIN32)
   set(LLVM_USE_CRT_RELEASE "MT" CACHE STRING "")
 endif()
@@ -105,12 +139,6 @@
   endif()
 endif()
 
-if(UNIX)
-  set(BOOTSTRAP_CMAKE_SHARED_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
-  set(BOOTSTRAP_CMAKE_MODULE_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
-  set(BOOTSTRAP_CMAKE_EXE_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
-endif()
-
 set(BOOTSTRAP_LLVM_ENABLE_LLD ON CACHE BOOL "")
 set(BOOTSTRAP_LLVM_ENABLE_LTO ON CACHE BOOL "")
 
@@ -145,6 +173,8 @@
 set(CLANG_BOOTSTRAP_EXTRA_DEPS
   builtins
   runtimes
+  llvm-rc
+  llvm-mt
   CACHE STRING "")
 set(CLANG_BOOTSTRAP_CMAKE_ARGS
   ${EXTRA_ARGS}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D141738: Add initial support for cross compile Windows runtimes under Linux when building Fuchsia clang toolchain

2023-01-23 Thread Haowei Wu via Phabricator via cfe-commits
haowei added inline comments.



Comment at: clang/cmake/caches/Fuchsia-stage2.cmake:95
+# and remove these libpath flags.
+-libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/lib/x64"
+-libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/atlmfc/lib/x64"

thakis wrote:
> You can tell cmake to invoke lld-link, which has a /winsysroot: flag.
What would be a good way to make CMake invoke lld-link (or through clang-cl) 
instead of using `cmake vs_link` in this situation?
We thought about using

```
set(CMAKE_${LANG}_SIMULATE_ID "MSVC")
set(CMAKE_${LANG}_COMPILER_FRONTEND_VARIANT "GNU")
```

but I don't feel great about changing variables that are not suppose to change. 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141738/new/

https://reviews.llvm.org/D141738

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D141738: Add initial support for cross compile Windows runtimes under Linux when building Fuchsia clang toolchain

2023-01-23 Thread Haowei Wu via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG20bb7658f53b: [Fuchsia] Build windows runtimes using cross 
compilation on Linux (authored by haowei).

Changed prior to commit:
  https://reviews.llvm.org/D141738?vs=490994=491508#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141738/new/

https://reviews.llvm.org/D141738

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  llvm/cmake/modules/LLVMExternalProjectUtils.cmake


Index: llvm/cmake/modules/LLVMExternalProjectUtils.cmake
===
--- llvm/cmake/modules/LLVMExternalProjectUtils.cmake
+++ llvm/cmake/modules/LLVMExternalProjectUtils.cmake
@@ -93,7 +93,7 @@
   if(_cmake_system_name STREQUAL Darwin)
 list(APPEND ARG_TOOLCHAIN_TOOLS llvm-libtool-darwin llvm-lipo)
   elseif(is_msvc_target)
-list(APPEND ARG_TOOLCHAIN_TOOLS llvm-lib)
+list(APPEND ARG_TOOLCHAIN_TOOLS llvm-lib llvm-rc llvm-mt)
   else()
 # TODO: These tools don't fully support Mach-O format yet.
 list(APPEND ARG_TOOLCHAIN_TOOLS llvm-objcopy llvm-strip llvm-readelf)
@@ -213,6 +213,12 @@
 if(llvm-readelf IN_LIST TOOLCHAIN_TOOLS)
   list(APPEND compiler_args 
-DCMAKE_READELF=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-readelf${CMAKE_EXECUTABLE_SUFFIX})
 endif()
+if(llvm-mt IN_LIST TOOLCHAIN_TOOLS AND is_msvc_target)
+  list(APPEND compiler_args 
-DCMAKE_MT=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-mt${CMAKE_EXECUTABLE_SUFFIX})
+endif()
+if(llvm-rc IN_LIST TOOLCHAIN_TOOLS AND is_msvc_target)
+  list(APPEND compiler_args 
-DCMAKE_RC_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-rc${CMAKE_EXECUTABLE_SUFFIX})
+endif()
 list(APPEND ARG_DEPENDS ${TOOLCHAIN_TOOLS})
   endif()
 
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -69,12 +69,44 @@
   set(RUNTIMES_CMAKE_ARGS 
"-DCMAKE_OSX_DEPLOYMENT_TARGET=10.13;-DCMAKE_OSX_ARCHITECTURES=arm64|x86_64" 
CACHE STRING "")
 endif()
 
-if(WIN32)
+if(WIN32 OR LLVM_WINSYSROOT)
+  if((NOT WIN32) AND (NOT LLVM_VFSOVERLAY))
+message(FATAL_ERROR "LLVM_VFSOVERLAY should be defined.")
+  endif()
   set(target "x86_64-pc-windows-msvc")
 
+  if (LLVM_WINSYSROOT)
+set(WINDOWS_COMPILER_FLAGS
+  -Xclang
+  -ivfsoverlay
+  -Xclang
+  ${LLVM_VFSOVERLAY}
+  # TODO: /winsysroot should be set by HandleLLVMOptions.cmake 
automatically
+  # but it current has a bug that prevents it from working under cross
+  # compilation. Set this flag manually for now.
+  /winsysroot
+  ${LLVM_WINSYSROOT})
+string(REPLACE ";" " " WINDOWS_COMPILER_FLAGS "${WINDOWS_COMPILER_FLAGS}")
+set(WINDOWS_LINK_FLAGS
+/vfsoverlay:${LLVM_VFSOVERLAY}
+# TODO: On Windows, linker is invoked by cmake instead of the clang-cl 
driver,
+# so we have to manually set the libpath. We use clang-cl driver if we 
can
+# and remove these libpath flags.
+-libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/lib/x64"
+-libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/atlmfc/lib/x64"
+-libpath:"${LLVM_WINSYSROOT}/Windows Kits/10/Lib/10.0.19041.0/ucrt/x64"
+-libpath:"${LLVM_WINSYSROOT}/Windows Kits/10/Lib/10.0.19041.0/um/x64")
+string(REPLACE ";" " " WINDOWS_LINK_FLAGS "${WINDOWS_LINK_FLAGS}")
+  endif()
+
   list(APPEND BUILTIN_TARGETS "${target}")
   set(BUILTINS_${target}_CMAKE_SYSTEM_NAME Windows CACHE STRING "")
   set(BUILTINS_${target}_CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "")
+  set(BUILTINS_${target}_CMAKE_C_FLAGS ${WINDOWS_COMPILER_FLAGS} CACHE STRING 
"")
+  set(BUILTINS_${target}_CMAKE_CXX_FLAGS ${WINDOWS_COMPILER_FLAGS} CACHE 
STRING "")
+  set(BUILTINS_${target}_CMAKE_EXE_LINKER_FLAGS ${WINDOWS_LINK_FLAGS} CACHE 
STRING "")
+  set(BUILTINS_${target}_CMAKE_SHARED_LINKER_FLAGS ${WINDOWS_LINK_FLAGS} CACHE 
STRING "")
+  set(BUILTINS_${target}_CMAKE_MODULE_LINKER_FLAGS ${WINDOWS_LINK_FLAGS} CACHE 
STRING "")
 
   list(APPEND RUNTIME_TARGETS "${target}")
   set(RUNTIMES_${target}_CMAKE_SYSTEM_NAME Windows CACHE STRING "")
@@ -84,6 +116,11 @@
   set(RUNTIMES_${target}_LIBCXX_ENABLE_ABI_LINKER_SCRIPT OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LIBCXX_ENABLE_SHARED OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE 
STRING "")
+  set(RUNTIMES_${target}_CMAKE_C_FLAGS ${WINDOWS_COMPILER_FLAGS} CACHE STRING 
"")
+  set(RUNTIMES_${target}_CMAKE_CXX_FLAGS ${WINDOWS_COMPILER_FLAGS} CACHE 
STRING "")
+  set(RUNTIMES_${target}_CMAKE_EXE_LINKER_FLAGS ${WINDOWS_LINK_FLAGS} CACHE 
STRING "")
+  set(RUNTIMES_${target}_CMAKE_SHARED_LINKER_FLAGS ${WINDOWS_LINK_FLAGS} CACHE 
STRING "")
+  

[PATCH] D141738: Add initial support for cross compile Windows runtimes under Linux when building Fuchsia clang toolchain

2023-01-20 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

Thanks for the review. I will land the change once Fuchsia clang builders are 
green.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141738/new/

https://reviews.llvm.org/D141738

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D141738: Add initial support for cross compile Windows runtimes under Linux when building Fuchsia clang toolchain

2023-01-20 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 490994.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141738/new/

https://reviews.llvm.org/D141738

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  llvm/cmake/modules/LLVMExternalProjectUtils.cmake


Index: llvm/cmake/modules/LLVMExternalProjectUtils.cmake
===
--- llvm/cmake/modules/LLVMExternalProjectUtils.cmake
+++ llvm/cmake/modules/LLVMExternalProjectUtils.cmake
@@ -93,7 +93,7 @@
   if(_cmake_system_name STREQUAL Darwin)
 list(APPEND ARG_TOOLCHAIN_TOOLS llvm-libtool-darwin llvm-lipo)
   elseif(is_msvc_target)
-list(APPEND ARG_TOOLCHAIN_TOOLS llvm-lib)
+list(APPEND ARG_TOOLCHAIN_TOOLS llvm-lib llvm-rc llvm-mt)
   else()
 # TODO: These tools don't fully support Mach-O format yet.
 list(APPEND ARG_TOOLCHAIN_TOOLS llvm-objcopy llvm-strip llvm-readelf)
@@ -213,6 +213,12 @@
 if(llvm-readelf IN_LIST TOOLCHAIN_TOOLS)
   list(APPEND compiler_args 
-DCMAKE_READELF=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-readelf${CMAKE_EXECUTABLE_SUFFIX})
 endif()
+if(llvm-mt IN_LIST TOOLCHAIN_TOOLS AND is_msvc_target)
+  list(APPEND compiler_args 
-DCMAKE_MT=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-mt${CMAKE_EXECUTABLE_SUFFIX})
+endif()
+if(llvm-rc IN_LIST TOOLCHAIN_TOOLS AND is_msvc_target)
+  list(APPEND compiler_args 
-DCMAKE_RC_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-rc${CMAKE_EXECUTABLE_SUFFIX})
+endif()
 list(APPEND ARG_DEPENDS ${TOOLCHAIN_TOOLS})
   endif()
 
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -69,12 +69,44 @@
   set(RUNTIMES_CMAKE_ARGS 
"-DCMAKE_OSX_DEPLOYMENT_TARGET=10.13;-DCMAKE_OSX_ARCHITECTURES=arm64|x86_64" 
CACHE STRING "")
 endif()
 
-if(WIN32)
+if(WIN32 OR LLVM_WINSYSROOT)
+  if((NOT WIN32) AND (NOT LLVM_VFSOVERLAY))
+message(FATAL_ERROR "LLVM_VFSOVERLAY should be defined.")
+  endif()
   set(target "x86_64-pc-windows-msvc")
 
+  if (LLVM_WINSYSROOT)
+set(WINDOWS_COMPILER_FLAGS
+  -Xclang
+  -ivfsoverlay
+  -Xclang
+  ${LLVM_VFSOVERLAY}
+  # TODO: /winsysroot should be set by HandleLLVMOptions.cmake 
automatically
+  # but it current has a bug that prevents it from working under cross
+  # compilation. Set this flag manually for now.
+  /winsysroot
+  ${LLVM_WINSYSROOT})
+string(REPLACE ";" " " WINDOWS_COMPILER_FLAGS "${WINDOWS_COMPILER_FLAGS}")
+set(WINDOWS_LINK_FLAGS
+/vfsoverlay:${LLVM_VFSOVERLAY}
+# TODO: On Windows, linker is invoked by cmake instead of the clang-cl 
driver,
+# so we have to manually set the libpath. We use clang-cl driver if we 
can
+# and remove these libpath flags.
+-libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/lib/x64"
+-libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/atlmfc/lib/x64"
+-libpath:"${LLVM_WINSYSROOT}/Windows Kits/10/Lib/10.0.19041.0/ucrt/x64"
+-libpath:"${LLVM_WINSYSROOT}/Windows Kits/10/Lib/10.0.19041.0/um/x64")
+string(REPLACE ";" " " WINDOWS_LINK_FLAGS "${WINDOWS_LINK_FLAGS}")
+  endif()
+
   list(APPEND BUILTIN_TARGETS "${target}")
   set(BUILTINS_${target}_CMAKE_SYSTEM_NAME Windows CACHE STRING "")
   set(BUILTINS_${target}_CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "")
+  set(BUILTINS_${target}_CMAKE_C_FLAGS ${WINDOWS_COMPILER_FLAGS} CACHE STRING 
"")
+  set(BUILTINS_${target}_CMAKE_CXX_FLAGS ${WINDOWS_COMPILER_FLAGS} CACHE 
STRING "")
+  set(BUILTINS_${target}_CMAKE_EXE_LINKER_FLAGS ${WINDOWS_LINK_FLAGS} CACHE 
STRING "")
+  set(BUILTINS_${target}_CMAKE_SHARED_LINKER_FLAGS ${WINDOWS_LINK_FLAGS} CACHE 
STRING "")
+  set(BUILTINS_${target}_CMAKE_MODULE_LINKER_FLAGS ${WINDOWS_LINK_FLAGS} CACHE 
STRING "")
 
   list(APPEND RUNTIME_TARGETS "${target}")
   set(RUNTIMES_${target}_CMAKE_SYSTEM_NAME Windows CACHE STRING "")
@@ -84,6 +116,12 @@
   set(RUNTIMES_${target}_LIBCXX_ENABLE_ABI_LINKER_SCRIPT OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LIBCXX_ENABLE_SHARED OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE 
STRING "")
+  set(RUNTIMES_${target}_CMAKE_REQUIRED_FLAGS ${WINDOWS_COMPILER_FLAGS} CACHE 
STRING "")
+  set(RUNTIMES_${target}_CMAKE_C_FLAGS ${WINDOWS_COMPILER_FLAGS} CACHE STRING 
"")
+  set(RUNTIMES_${target}_CMAKE_CXX_FLAGS ${WINDOWS_COMPILER_FLAGS} CACHE 
STRING "")
+  set(RUNTIMES_${target}_CMAKE_EXE_LINKER_FLAGS ${WINDOWS_LINK_FLAGS} CACHE 
STRING "")
+  set(RUNTIMES_${target}_CMAKE_SHARED_LINKER_FLAGS ${WINDOWS_LINK_FLAGS} CACHE 
STRING "")
+  set(RUNTIMES_${target}_CMAKE_MODULE_LINKER_FLAGS ${WINDOWS_LINK_FLAGS} CACHE 
STRING "")
 endif()
 
 foreach(target 
aarch64-unknown-linux-gnu;armv7-unknown-linux-gnueabihf;i386-unknown-linux-gnu;x86_64-unknown-linux-gnu)


Index: 

[PATCH] D141738: Add initial support for cross compile Windows runtimes under Linux when building Fuchsia clang toolchain

2023-01-20 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 490921.
haowei added a comment.

Correct an issue llvm-rc and llvm-mt are not part of `TOOLCHAIN_TOOLS`


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141738/new/

https://reviews.llvm.org/D141738

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  llvm/cmake/modules/LLVMExternalProjectUtils.cmake


Index: llvm/cmake/modules/LLVMExternalProjectUtils.cmake
===
--- llvm/cmake/modules/LLVMExternalProjectUtils.cmake
+++ llvm/cmake/modules/LLVMExternalProjectUtils.cmake
@@ -93,7 +93,7 @@
   if(_cmake_system_name STREQUAL Darwin)
 list(APPEND ARG_TOOLCHAIN_TOOLS llvm-libtool-darwin llvm-lipo)
   elseif(is_msvc_target)
-list(APPEND ARG_TOOLCHAIN_TOOLS llvm-lib)
+list(APPEND ARG_TOOLCHAIN_TOOLS llvm-lib llvm-rc llvm-mt)
   else()
 # TODO: These tools don't fully support Mach-O format yet.
 list(APPEND ARG_TOOLCHAIN_TOOLS llvm-objcopy llvm-strip llvm-readelf)
@@ -213,6 +213,12 @@
 if(llvm-readelf IN_LIST TOOLCHAIN_TOOLS)
   list(APPEND compiler_args 
-DCMAKE_READELF=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-readelf${CMAKE_EXECUTABLE_SUFFIX})
 endif()
+if(llvm-mt IN_LIST TOOLCHAIN_TOOLS AND is_msvc_target)
+  list(APPEND compiler_args 
-DCMAKE_MT=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-mt${CMAKE_EXECUTABLE_SUFFIX})
+endif()
+if(llvm-rc IN_LIST TOOLCHAIN_TOOLS AND is_msvc_target)
+  list(APPEND compiler_args 
-DCMAKE_RC_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-rc${CMAKE_EXECUTABLE_SUFFIX})
+endif()
 list(APPEND ARG_DEPENDS ${TOOLCHAIN_TOOLS})
   endif()
 
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -69,13 +69,48 @@
   set(RUNTIMES_CMAKE_ARGS 
"-DCMAKE_OSX_DEPLOYMENT_TARGET=10.13;-DCMAKE_OSX_ARCHITECTURES=arm64|x86_64" 
CACHE STRING "")
 endif()
 
-if(WIN32)
+if(WIN32 OR LLVM_WINSYSROOT)
+  if((NOT WIN32) AND (NOT LLVM_VFSOVERLAY))
+message(FATAL_ERROR "LLVM_VFSOVERLAY should be defined.")
+  endif()
   set(target "x86_64-pc-windows-msvc")
 
+  if (LLVM_WINSYSROOT)
+set(CLANG_WINDOWS_CROSS_FLAGS
+  -Xclang
+  -ivfsoverlay
+  -Xclang
+  ${LLVM_VFSOVERLAY}
+  # TODO: /winsysroot should be set by HandleLLVMOptions.cmake 
automatically
+  # but it current has a bug that prevents it from working under cross
+  # compilation. Set this flag manually for now.
+  /winsysroot
+  ${LLVM_WINSYSROOT})
+string(REPLACE ";" " " CLANG_WINDOWS_CROSS_FLAGS 
"${CLANG_WINDOWS_CROSS_FLAGS}")
+set(LINK_WINDOWS_CROSS_FLAGS
+/vfsoverlay:${LLVM_VFSOVERLAY}
+# TODO: On Windows, linker is invoked by cmake instead of the clang-cl 
driver,
+# so we have to manually set the libpath. We use clang-cl driver if we 
can
+# and remove these libpath flags.
+-libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/lib/x64"
+-libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/atlmfc/lib/x64"
+-libpath:"${LLVM_WINSYSROOT}/Windows Kits/10/Lib/10.0.19041.0/ucrt/x64"
+-libpath:"${LLVM_WINSYSROOT}/Windows Kits/10/Lib/10.0.19041.0/um/x64")
+string(REPLACE ";" " " LINK_WINDOWS_CROSS_FLAGS 
"${LINK_WINDOWS_CROSS_FLAGS}")
+  endif()
+
   list(APPEND BUILTIN_TARGETS "${target}")
   set(BUILTINS_${target}_CMAKE_SYSTEM_NAME Windows CACHE STRING "")
   set(BUILTINS_${target}_CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "")
 
+  if(LLVM_WINSYSROOT)
+set(BUILTINS_${target}_CMAKE_C_FLAGS ${CLANG_WINDOWS_CROSS_FLAGS} CACHE 
STRING "")
+set(BUILTINS_${target}_CMAKE_CXX_FLAGS ${CLANG_WINDOWS_CROSS_FLAGS} CACHE 
STRING "")
+set(BUILTINS_${target}_CMAKE_EXE_LINKER_FLAGS ${LINK_WINDOWS_CROSS_FLAGS} 
CACHE STRING "")
+set(BUILTINS_${target}_CMAKE_SHARED_LINKER_FLAGS 
${LINK_WINDOWS_CROSS_FLAGS} CACHE STRING "")
+set(BUILTINS_${target}_CMAKE_MODULE_LINKER_FLAGS 
${LINK_WINDOWS_CROSS_FLAGS} CACHE STRING "")
+  endif()
+
   list(APPEND RUNTIME_TARGETS "${target}")
   set(RUNTIMES_${target}_CMAKE_SYSTEM_NAME Windows CACHE STRING "")
   set(RUNTIMES_${target}_CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "")
@@ -84,6 +119,15 @@
   set(RUNTIMES_${target}_LIBCXX_ENABLE_ABI_LINKER_SCRIPT OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LIBCXX_ENABLE_SHARED OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE 
STRING "")
+
+  if(LLVM_WINSYSROOT)
+set(RUNTIMES_${target}_CMAKE_REQUIRED_FLAGS ${CLANG_WINDOWS_CROSS_FLAGS} 
CACHE STRING "")
+set(RUNTIMES_${target}_CMAKE_C_FLAGS ${CLANG_WINDOWS_CROSS_FLAGS} CACHE 
STRING "")
+set(RUNTIMES_${target}_CMAKE_CXX_FLAGS ${CLANG_WINDOWS_CROSS_FLAGS} CACHE 
STRING "")
+set(RUNTIMES_${target}_CMAKE_EXE_LINKER_FLAGS ${LINK_WINDOWS_CROSS_FLAGS} 
CACHE STRING "")
+

[PATCH] D141738: Add initial support for cross compile Windows runtimes under Linux when building Fuchsia clang toolchain

2023-01-19 Thread Haowei Wu via Phabricator via cfe-commits
haowei marked 2 inline comments as done.
haowei added inline comments.



Comment at: clang/cmake/caches/Fuchsia-stage2.cmake:73
+
+if(WIN32 OR (LINUX AND WINDOWS_SDK_DIR))
+#if(WINDOWS_SDK_DIR)

phosek wrote:
> I'd drop this part altogether, let's build these anytime when 
> `WINDOWS_SDK_DIR` is set.
We need to do a soft transition if we drop the "WIN32" since the bots are not 
passing the WINSYSROOT flag yet. Let's keep the WIN32 here.



Comment at: clang/cmake/caches/Fuchsia-stage2.cmake:105-108
+-libpath:"${WINDOWS_SDK_DIR}/VC/Tools/MSVC/14.34.31933/lib/x64"
+-libpath:"${WINDOWS_SDK_DIR}/VC/Tools/MSVC/14.34.31933/atlmfc/lib/x64"
+-libpath:"${WINDOWS_SDK_DIR}/Windows Kits/10/Lib/10.0.19041.0/ucrt/x64"
+-libpath:"${WINDOWS_SDK_DIR}/Windows Kits/10/Lib/10.0.19041.0/um/x64")

phosek wrote:
> These should be set automatically if you set `/winsysroot` (through 
> `LLVM_WINSYSROOT`), see 
> https://github.com/llvm/llvm-project/blob/a64846bee0bb4b4912c8cf6bf018ba5d892065d1/clang/lib/Driver/ToolChains/MSVC.cpp#L107.
There is an issue that "CLANG_CL" variable is not correctly set when clang 
kicks runtime build. When CLANG_CL is not set, the /winsysroot will not be 
added by the LLVM_WINSYSROOT flag. I have some thoughts about it and prefer to 
address this issue in a follow up patch instead of put everything here.



Comment at: clang/cmake/caches/Fuchsia-stage2.cmake:144-145
+"${WINDOWS_SDK_DIR}/llvm-vfsoverlay.yaml"
+/winsysroot
+${WINDOWS_SDK_DIR})
+string(REPLACE ";" " " CLANG_WINDOWS_CROSS_FLAGS 
"${CLANG_WINDOWS_CROSS_FLAGS}")

phosek wrote:
> Can we instead set `RUNTIMES_${target}_LLVM_WINSYSROOT` to 
> `${WINDOWS_SDK_DIR}`?
As stated in an earlier comment, this will require fixing the setting the 
"CLANG_CL" variable in compiler version detection. 



Comment at: llvm/runtimes/CMakeLists.txt:359
 
-  if(NOT RUNTIMES_${name}_LLVM_USE_LINKER AND NOT 
RUNTIMES_${target}_LLVM_USE_LINKER)
+  if(NOT RUNTIMES_${name}_LLVM_USE_LINKER AND NOT 
RUNTIMES_${target}_LLVM_USE_LINKER AND NOT ${target} STREQUAL 
"x86_64-pc-windows-msvc")
 list(APPEND ${name}_extra_args -DLLVM_USE_LINKER=${LLVM_USE_LINKER})

phosek wrote:
> We should fix the build so that this isn't needed, it should be possible to 
> use `LLVM_USE_LINKER=lld` when targeting Windows.
I made some other changes and now the /fuse-ld=lld will be passed to 
lld-link.exe if we leave this line unchanged. 
It will through a warning but won't stop the build.
Once I fix the CLANG_CL issue, I can prevent it from inserting `/fuse-ld=lld` 
when using CLANG_CL


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141738/new/

https://reviews.llvm.org/D141738

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D141738: Add initial support for cross compile Windows runtimes under Linux when building Fuchsia clang toolchain

2023-01-19 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 490679.
haowei retitled this revision from "[WIP] Add initial support for cross compile 
Windows runtimes under Linux when building Fuchsia clang toolchain" to "Add 
initial support for cross compile Windows runtimes under Linux when building 
Fuchsia clang toolchain".
haowei edited the summary of this revision.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141738/new/

https://reviews.llvm.org/D141738

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  llvm/cmake/modules/LLVMExternalProjectUtils.cmake


Index: llvm/cmake/modules/LLVMExternalProjectUtils.cmake
===
--- llvm/cmake/modules/LLVMExternalProjectUtils.cmake
+++ llvm/cmake/modules/LLVMExternalProjectUtils.cmake
@@ -213,6 +213,12 @@
 if(llvm-readelf IN_LIST TOOLCHAIN_TOOLS)
   list(APPEND compiler_args 
-DCMAKE_READELF=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-readelf${CMAKE_EXECUTABLE_SUFFIX})
 endif()
+if(llvm-mt IN_LIST TOOLCHAIN_TOOLS AND is_msvc_target)
+  list(APPEND compiler_args 
-DCMAKE_MT=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-mt${CMAKE_EXECUTABLE_SUFFIX})
+endif()
+if(llvm-rc IN_LIST TOOLCHAIN_TOOLS AND is_msvc_target)
+  list(APPEND compiler_args 
-DCMAKE_RC_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-rc${CMAKE_EXECUTABLE_SUFFIX})
+endif()
 list(APPEND ARG_DEPENDS ${TOOLCHAIN_TOOLS})
   endif()
 
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -69,13 +69,48 @@
   set(RUNTIMES_CMAKE_ARGS 
"-DCMAKE_OSX_DEPLOYMENT_TARGET=10.13;-DCMAKE_OSX_ARCHITECTURES=arm64|x86_64" 
CACHE STRING "")
 endif()
 
-if(WIN32)
+if(WIN32 OR LLVM_WINSYSROOT)
+  if((NOT WIN32) AND (NOT LLVM_VFSOVERLAY))
+message(FATAL_ERROR "LLVM_VFSOVERLAY should be defined.")
+  endif()
   set(target "x86_64-pc-windows-msvc")
 
+  if (LLVM_WINSYSROOT)
+set(CLANG_WINDOWS_CROSS_FLAGS
+  -Xclang
+  -ivfsoverlay
+  -Xclang
+  ${LLVM_VFSOVERLAY}
+  # TODO: /winsysroot should be set by HandleLLVMOptions.cmake 
automatically
+  # but it current has a bug that prevents it from working under cross
+  # compilation. Set this flag manually for now.
+  /winsysroot
+  ${LLVM_WINSYSROOT})
+string(REPLACE ";" " " CLANG_WINDOWS_CROSS_FLAGS 
"${CLANG_WINDOWS_CROSS_FLAGS}")
+set(LINK_WINDOWS_CROSS_FLAGS
+/vfsoverlay:${LLVM_VFSOVERLAY}
+# TODO: On Windows, linker is invoked by cmake instead of the clang-cl 
driver,
+# so we have to manually set the libpath. We use clang-cl driver if we 
can
+# and remove these libpath flags.
+-libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/lib/x64"
+-libpath:"${LLVM_WINSYSROOT}/VC/Tools/MSVC/14.34.31933/atlmfc/lib/x64"
+-libpath:"${LLVM_WINSYSROOT}/Windows Kits/10/Lib/10.0.19041.0/ucrt/x64"
+-libpath:"${LLVM_WINSYSROOT}/Windows Kits/10/Lib/10.0.19041.0/um/x64")
+string(REPLACE ";" " " LINK_WINDOWS_CROSS_FLAGS 
"${LINK_WINDOWS_CROSS_FLAGS}")
+  endif()
+
   list(APPEND BUILTIN_TARGETS "${target}")
   set(BUILTINS_${target}_CMAKE_SYSTEM_NAME Windows CACHE STRING "")
   set(BUILTINS_${target}_CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "")
 
+  if(LLVM_WINSYSROOT)
+set(BUILTINS_${target}_CMAKE_C_FLAGS ${CLANG_WINDOWS_CROSS_FLAGS} CACHE 
STRING "")
+set(BUILTINS_${target}_CMAKE_CXX_FLAGS ${CLANG_WINDOWS_CROSS_FLAGS} CACHE 
STRING "")
+set(BUILTINS_${target}_CMAKE_EXE_LINKER_FLAGS ${LINK_WINDOWS_CROSS_FLAGS} 
CACHE STRING "")
+set(BUILTINS_${target}_CMAKE_SHARED_LINKER_FLAGS 
${LINK_WINDOWS_CROSS_FLAGS} CACHE STRING "")
+set(BUILTINS_${target}_CMAKE_MODULE_LINKER_FLAGS 
${LINK_WINDOWS_CROSS_FLAGS} CACHE STRING "")
+  endif()
+
   list(APPEND RUNTIME_TARGETS "${target}")
   set(RUNTIMES_${target}_CMAKE_SYSTEM_NAME Windows CACHE STRING "")
   set(RUNTIMES_${target}_CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "")
@@ -84,6 +119,15 @@
   set(RUNTIMES_${target}_LIBCXX_ENABLE_ABI_LINKER_SCRIPT OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LIBCXX_ENABLE_SHARED OFF CACHE BOOL "")
   set(RUNTIMES_${target}_LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE 
STRING "")
+
+  if(LLVM_WINSYSROOT)
+set(RUNTIMES_${target}_CMAKE_REQUIRED_FLAGS ${CLANG_WINDOWS_CROSS_FLAGS} 
CACHE STRING "")
+set(RUNTIMES_${target}_CMAKE_C_FLAGS ${CLANG_WINDOWS_CROSS_FLAGS} CACHE 
STRING "")
+set(RUNTIMES_${target}_CMAKE_CXX_FLAGS ${CLANG_WINDOWS_CROSS_FLAGS} CACHE 
STRING "")
+set(RUNTIMES_${target}_CMAKE_EXE_LINKER_FLAGS ${LINK_WINDOWS_CROSS_FLAGS} 
CACHE STRING "")
+set(RUNTIMES_${target}_CMAKE_SHARED_LINKER_FLAGS 
${LINK_WINDOWS_CROSS_FLAGS} CACHE STRING "")
+set(RUNTIMES_${target}_CMAKE_MODULE_LINKER_FLAGS 
${LINK_WINDOWS_CROSS_FLAGS} CACHE STRING "")
+  endif()
 endif()
 
 foreach(target 

[PATCH] D141738: [WIP] Add initial support for cross compile Windows runtimes under Linux when building Fuchsia clang toolchain

2023-01-13 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 489177.
haowei added a comment.

Correct C, CXX flag issue.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141738/new/

https://reviews.llvm.org/D141738

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  llvm/cmake/modules/LLVMExternalProjectUtils.cmake
  llvm/runtimes/CMakeLists.txt

Index: llvm/runtimes/CMakeLists.txt
===
--- llvm/runtimes/CMakeLists.txt
+++ llvm/runtimes/CMakeLists.txt
@@ -3,9 +3,12 @@
 # similar although simpler functionality. We should figure out how to merge
 # the two files.
 
+message(NOTICE "Fuchisa Clang compiler-rt hello world")
+message(NOTICE "CMAKE_CURRENT_SOURCE_DIR is ${CMAKE_CURRENT_SOURCE_DIR}")
 set(COMMON_CMAKE_ARGS "-DHAVE_LLVM_LIT=ON")
 foreach(proj ${LLVM_ENABLE_RUNTIMES})
   set(proj_dir "${CMAKE_CURRENT_SOURCE_DIR}/../../${proj}")
+  message(NOTICE "${proj}'s proj_dir is ${proj_dir}")
   if(IS_DIRECTORY ${proj_dir} AND EXISTS ${proj_dir}/CMakeLists.txt)
 list(APPEND runtimes ${proj_dir})
   else()
@@ -94,7 +97,9 @@
   check_apple_target(${target} builtin)
 
   get_cmake_property(variableNames VARIABLES)
+  #message(NOTICE "builtin variableNames ${variableNames}")
   foreach(variableName ${variableNames})
+#message(NOTICE "builtin variableName ${variableName}")
 string(FIND "${variableName}" "BUILTINS_${target}" out)
 if("${out}" EQUAL 0)
   string(REPLACE "BUILTINS_${target}_" "" new_name ${variableName})
@@ -103,6 +108,12 @@
 endif()
   endforeach()
 
+  message(NOTICE "builtin target for ${target}")
+  #message(NOTICE "cmake args ${CMAKE_ARGS}")
+  message(NOTICE "cmake common args ${COMMON_CMAKE_ARGS}")
+  message(NOTICE "extra args:")
+  message(NOTICE ${${target}_extra_args})
+
   llvm_ExternalProject_Add(builtins-${target}
${compiler_rt_path}/lib/builtins
DEPENDS ${ARG_DEPENDS}
@@ -139,6 +150,7 @@
   add_custom_target(install-builtins-stripped)
 endif()
 
+message(NOTICE "Fuchisa Clang builtins: ${LLVM_BUILTIN_TARGETS}")
 foreach(target ${LLVM_BUILTIN_TARGETS})
   builtin_register_target(${compiler_rt_path} ${target}
 DEPENDS clang-resource-headers)
@@ -344,10 +356,16 @@
 list(APPEND ${name}_extra_args -DLLVM_ENABLE_RUNTIMES=${LLVM_ENABLE_RUNTIMES_PASSTHROUGH})
   endif()
 
-  if(NOT RUNTIMES_${name}_LLVM_USE_LINKER AND NOT RUNTIMES_${target}_LLVM_USE_LINKER)
+  if(NOT RUNTIMES_${name}_LLVM_USE_LINKER AND NOT RUNTIMES_${target}_LLVM_USE_LINKER AND NOT ${target} STREQUAL "x86_64-pc-windows-msvc")
 list(APPEND ${name}_extra_args -DLLVM_USE_LINKER=${LLVM_USE_LINKER})
   endif()
 
+  message(NOTICE "runtime target for ${target}")
+  #message(NOTICE "cmake args ${CMAKE_ARGS}")
+  message(NOTICE "cmake common args ${COMMON_CMAKE_ARGS}")
+  message(NOTICE "extra args:")
+  message(NOTICE ${${name}_extra_args})
+
   llvm_ExternalProject_Add(runtimes-${name}
${CMAKE_CURRENT_SOURCE_DIR}/../../runtimes
DEPENDS ${${name}_deps}
@@ -419,6 +437,7 @@
   endif()
 endif()
 
+message(NOTICE "Fuchisa Clang runtimes: ${LLVM_RUNTIME_TARGETS}")
 foreach(name ${LLVM_RUNTIME_TARGETS})
   if(builtins_dep)
 if (LLVM_BUILTIN_TARGETS)
Index: llvm/cmake/modules/LLVMExternalProjectUtils.cmake
===
--- llvm/cmake/modules/LLVMExternalProjectUtils.cmake
+++ llvm/cmake/modules/LLVMExternalProjectUtils.cmake
@@ -168,7 +168,10 @@
   if(is_msvc_target)
 set(compiler_args -DCMAKE_C_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang-cl${CMAKE_EXECUTABLE_SUFFIX}
   -DCMAKE_CXX_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang-cl${CMAKE_EXECUTABLE_SUFFIX}
-  -DCMAKE_ASM_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang-cl${CMAKE_EXECUTABLE_SUFFIX})
+  -DCMAKE_ASM_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang-cl${CMAKE_EXECUTABLE_SUFFIX}
+  -DCMAKE_RC_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-rc
+  -DCMAKE_MT=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-mt
+  )
   else()
 set(compiler_args -DCMAKE_C_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang${CMAKE_EXECUTABLE_SUFFIX}
   -DCMAKE_CXX_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang++${CMAKE_EXECUTABLE_SUFFIX}
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -69,13 +69,51 @@
   set(RUNTIMES_CMAKE_ARGS "-DCMAKE_OSX_DEPLOYMENT_TARGET=10.13;-DCMAKE_OSX_ARCHITECTURES=arm64|x86_64" CACHE STRING "")
 endif()
 
-if(WIN32)
+
+if(WIN32 OR (LINUX AND WINDOWS_SDK_DIR))
+#if(WINDOWS_SDK_DIR)
+  #message(FATAL_ERROR "${WINDOWS_SDK_DIR} is set")
 

[PATCH] D141738: [WIP] Add initial support for cross compile Windows runtimes under Linux when building Fuchsia clang toolchain

2023-01-13 Thread Haowei Wu via Phabricator via cfe-commits
haowei created this revision.
haowei added a reviewer: phosek.
Herald added a subscriber: abrachet.
Herald added a project: All.
haowei requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Work in progress.

Initial work on building Windows compiler runtimes under Linux.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D141738

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  llvm/cmake/modules/LLVMExternalProjectUtils.cmake
  llvm/runtimes/CMakeLists.txt

Index: llvm/runtimes/CMakeLists.txt
===
--- llvm/runtimes/CMakeLists.txt
+++ llvm/runtimes/CMakeLists.txt
@@ -3,9 +3,12 @@
 # similar although simpler functionality. We should figure out how to merge
 # the two files.
 
+message(NOTICE "Fuchisa Clang compiler-rt hello world")
+message(NOTICE "CMAKE_CURRENT_SOURCE_DIR is ${CMAKE_CURRENT_SOURCE_DIR}")
 set(COMMON_CMAKE_ARGS "-DHAVE_LLVM_LIT=ON")
 foreach(proj ${LLVM_ENABLE_RUNTIMES})
   set(proj_dir "${CMAKE_CURRENT_SOURCE_DIR}/../../${proj}")
+  message(NOTICE "${proj}'s proj_dir is ${proj_dir}")
   if(IS_DIRECTORY ${proj_dir} AND EXISTS ${proj_dir}/CMakeLists.txt)
 list(APPEND runtimes ${proj_dir})
   else()
@@ -94,7 +97,9 @@
   check_apple_target(${target} builtin)
 
   get_cmake_property(variableNames VARIABLES)
+  #message(NOTICE "builtin variableNames ${variableNames}")
   foreach(variableName ${variableNames})
+#message(NOTICE "builtin variableName ${variableName}")
 string(FIND "${variableName}" "BUILTINS_${target}" out)
 if("${out}" EQUAL 0)
   string(REPLACE "BUILTINS_${target}_" "" new_name ${variableName})
@@ -103,6 +108,12 @@
 endif()
   endforeach()
 
+  message(NOTICE "builtin target for ${target}")
+  #message(NOTICE "cmake args ${CMAKE_ARGS}")
+  message(NOTICE "cmake common args ${COMMON_CMAKE_ARGS}")
+  message(NOTICE "extra args:")
+  message(NOTICE ${${target}_extra_args})
+
   llvm_ExternalProject_Add(builtins-${target}
${compiler_rt_path}/lib/builtins
DEPENDS ${ARG_DEPENDS}
@@ -139,6 +150,7 @@
   add_custom_target(install-builtins-stripped)
 endif()
 
+message(NOTICE "Fuchisa Clang builtins: ${LLVM_BUILTIN_TARGETS}")
 foreach(target ${LLVM_BUILTIN_TARGETS})
   builtin_register_target(${compiler_rt_path} ${target}
 DEPENDS clang-resource-headers)
@@ -344,10 +356,16 @@
 list(APPEND ${name}_extra_args -DLLVM_ENABLE_RUNTIMES=${LLVM_ENABLE_RUNTIMES_PASSTHROUGH})
   endif()
 
-  if(NOT RUNTIMES_${name}_LLVM_USE_LINKER AND NOT RUNTIMES_${target}_LLVM_USE_LINKER)
+  if(NOT RUNTIMES_${name}_LLVM_USE_LINKER AND NOT RUNTIMES_${target}_LLVM_USE_LINKER AND NOT ${target} STREQUAL "x86_64-pc-windows-msvc")
 list(APPEND ${name}_extra_args -DLLVM_USE_LINKER=${LLVM_USE_LINKER})
   endif()
 
+  message(NOTICE "runtime target for ${target}")
+  #message(NOTICE "cmake args ${CMAKE_ARGS}")
+  message(NOTICE "cmake common args ${COMMON_CMAKE_ARGS}")
+  message(NOTICE "extra args:")
+  message(NOTICE ${${name}_extra_args})
+
   llvm_ExternalProject_Add(runtimes-${name}
${CMAKE_CURRENT_SOURCE_DIR}/../../runtimes
DEPENDS ${${name}_deps}
@@ -419,6 +437,7 @@
   endif()
 endif()
 
+message(NOTICE "Fuchisa Clang runtimes: ${LLVM_RUNTIME_TARGETS}")
 foreach(name ${LLVM_RUNTIME_TARGETS})
   if(builtins_dep)
 if (LLVM_BUILTIN_TARGETS)
Index: llvm/cmake/modules/LLVMExternalProjectUtils.cmake
===
--- llvm/cmake/modules/LLVMExternalProjectUtils.cmake
+++ llvm/cmake/modules/LLVMExternalProjectUtils.cmake
@@ -168,7 +168,10 @@
   if(is_msvc_target)
 set(compiler_args -DCMAKE_C_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang-cl${CMAKE_EXECUTABLE_SUFFIX}
   -DCMAKE_CXX_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang-cl${CMAKE_EXECUTABLE_SUFFIX}
-  -DCMAKE_ASM_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang-cl${CMAKE_EXECUTABLE_SUFFIX})
+  -DCMAKE_ASM_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang-cl${CMAKE_EXECUTABLE_SUFFIX}
+  -DCMAKE_RC_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-rc
+  -DCMAKE_MT=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-mt
+  )
   else()
 set(compiler_args -DCMAKE_C_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang${CMAKE_EXECUTABLE_SUFFIX}
   -DCMAKE_CXX_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang++${CMAKE_EXECUTABLE_SUFFIX}
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -69,13 +69,49 @@
   set(RUNTIMES_CMAKE_ARGS 

[PATCH] D141448: [CMake][Fuchsia] Include llvm-ml in Fuchsia toolchain

2023-01-11 Thread Haowei Wu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGbc3edb627201: [CMake][Fuchsia] Include llvm-ml in Fuchsia 
toolchain (authored by haowei).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141448/new/

https://reviews.llvm.org/D141448

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -265,6 +265,7 @@
   llvm-lib
   llvm-libtool-darwin
   llvm-lipo
+  llvm-ml
   llvm-mt
   llvm-nm
   llvm-objcopy


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -265,6 +265,7 @@
   llvm-lib
   llvm-libtool-darwin
   llvm-lipo
+  llvm-ml
   llvm-mt
   llvm-nm
   llvm-objcopy
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D141448: [CMake][Fuchsia] Include llvm-ml in Fuchsia toolchain

2023-01-10 Thread Haowei Wu via Phabricator via cfe-commits
haowei created this revision.
haowei added a reviewer: phosek.
Herald added a subscriber: abrachet.
Herald added a project: All.
haowei requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This change includes llvm-ml tool in Fuchsia toolchain.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D141448

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -265,6 +265,7 @@
   llvm-lib
   llvm-libtool-darwin
   llvm-lipo
+  llvm-ml
   llvm-mt
   llvm-nm
   llvm-objcopy


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -265,6 +265,7 @@
   llvm-lib
   llvm-libtool-darwin
   llvm-lipo
+  llvm-ml
   llvm-mt
   llvm-nm
   llvm-objcopy
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137473: [vfs] Allow root paths relative to the directory of the vfsoverlay YAML file

2022-12-16 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

In D137473#3993584 , @bnbarham wrote:

> LGTM. If you could put up a PR after to fix the use of 
> `sys::fs::make_absolute` that would be appreciated .

Thanks, I will start working on the fix.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137473/new/

https://reviews.llvm.org/D137473

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137473: [vfs] Allow root paths relative to the directory of the vfsoverlay YAML file

2022-12-16 Thread Haowei Wu via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa903ecb4a26d: [vfs] Allow root paths relative to the 
vfsoverlay YAML file (authored by haowei).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137473/new/

https://reviews.llvm.org/D137473

Files:
  clang/test/VFS/Inputs/root-relative-overlay.yaml
  clang/test/VFS/relative-path.c
  llvm/include/llvm/Support/VirtualFileSystem.h
  llvm/lib/Support/VirtualFileSystem.cpp
  llvm/unittests/Support/VirtualFileSystemTest.cpp

Index: llvm/unittests/Support/VirtualFileSystemTest.cpp
===
--- llvm/unittests/Support/VirtualFileSystemTest.cpp
+++ llvm/unittests/Support/VirtualFileSystemTest.cpp
@@ -1456,18 +1456,20 @@
 
   std::unique_ptr
   getFromYAMLRawString(StringRef Content,
-   IntrusiveRefCntPtr ExternalFS) {
+   IntrusiveRefCntPtr ExternalFS,
+   StringRef YAMLFilePath = "") {
 std::unique_ptr Buffer = MemoryBuffer::getMemBuffer(Content);
-return getVFSFromYAML(std::move(Buffer), CountingDiagHandler, "", this,
-  ExternalFS);
+return getVFSFromYAML(std::move(Buffer), CountingDiagHandler, YAMLFilePath,
+  this, ExternalFS);
   }
 
   std::unique_ptr getFromYAMLString(
   StringRef Content,
-  IntrusiveRefCntPtr ExternalFS = new DummyFileSystem()) {
+  IntrusiveRefCntPtr ExternalFS = new DummyFileSystem(),
+  StringRef YAMLFilePath = "") {
 std::string VersionPlusContent("{\n  'version':0,\n");
 VersionPlusContent += Content.slice(Content.find('{') + 1, StringRef::npos);
-return getFromYAMLRawString(VersionPlusContent, ExternalFS);
+return getFromYAMLRawString(VersionPlusContent, ExternalFS, YAMLFilePath);
   }
 
   // This is intended as a "XFAIL" for windows hosts.
@@ -1853,6 +1855,69 @@
   EXPECT_EQ(0, NumDiagnostics);
 }
 
+TEST_F(VFSFromYAMLTest, RootRelativeTest) {
+  IntrusiveRefCntPtr Lower(new DummyFileSystem());
+  Lower->addDirectory("//root/foo/bar");
+  Lower->addRegularFile("//root/foo/bar/a");
+  IntrusiveRefCntPtr FS =
+  getFromYAMLString("{\n"
+"  'case-sensitive': false,\n"
+"  'root-relative': 'overlay-dir',\n"
+"  'roots': [\n"
+"{ 'name': 'b', 'type': 'file',\n"
+"  'external-contents': '//root/foo/bar/a'\n"
+"}\n"
+"  ]\n"
+"}",
+Lower, "//root/foo/bar/overlay");
+
+  ASSERT_NE(FS.get(), nullptr);
+  ErrorOr S = FS->status("//root/foo/bar/b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("//root/foo/bar/a", S->getName());
+
+  // On Windows, with overlay-relative set to true, the relative
+  // path in external-contents field will be prepend by OverlayDir
+  // with native path separator, regardless of the actual path separator
+  // used in YAMLFilePath field.
+#ifndef _WIN32
+  FS = getFromYAMLString("{\n"
+ "  'case-sensitive': false,\n"
+ "  'overlay-relative': true,\n"
+ "  'root-relative': 'overlay-dir',\n"
+ "  'roots': [\n"
+ "{ 'name': 'b', 'type': 'file',\n"
+ "  'external-contents': 'a'\n"
+ "}\n"
+ "  ]\n"
+ "}",
+ Lower, "//root/foo/bar/overlay");
+  ASSERT_NE(FS.get(), nullptr);
+  S = FS->status("//root/foo/bar/b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("//root/foo/bar/a", S->getName());
+#else
+  IntrusiveRefCntPtr LowerWindows(new DummyFileSystem());
+  LowerWindows->addDirectory("root\\foo\\bar");
+  LowerWindows->addRegularFile("root\\foo\\bar\\a");
+  FS = getFromYAMLString("{\n"
+ "  'case-sensitive': false,\n"
+ "  'overlay-relative': true,\n"
+ "  'root-relative': 'overlay-dir',\n"
+ "  'roots': [\n"
+ "{ 'name': 'b', 'type': 'file',\n"
+ "  'external-contents': 'a'\n"
+ "}\n"
+ "  ]\n"
+ "}",
+ LowerWindows, "root\\foo\\bar\\overlay");
+  ASSERT_NE(FS.get(), nullptr);
+  S = FS->status("root\\foo\\bar\\b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("root\\foo\\bar\\a", S->getName());
+#endif
+}
+
 TEST_F(VFSFromYAMLTest, ReturnsInternalPathVFSHit) {
   IntrusiveRefCntPtr BaseFS(
   new vfs::InMemoryFileSystem);
Index: llvm/lib/Support/VirtualFileSystem.cpp

[PATCH] D137473: [vfs] Allow root paths relative to the directory of the vfsoverlay YAML file

2022-12-13 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 482660.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137473/new/

https://reviews.llvm.org/D137473

Files:
  clang/test/VFS/Inputs/root-relative-overlay.yaml
  clang/test/VFS/relative-path.c
  llvm/include/llvm/Support/VirtualFileSystem.h
  llvm/lib/Support/VirtualFileSystem.cpp
  llvm/unittests/Support/VirtualFileSystemTest.cpp

Index: llvm/unittests/Support/VirtualFileSystemTest.cpp
===
--- llvm/unittests/Support/VirtualFileSystemTest.cpp
+++ llvm/unittests/Support/VirtualFileSystemTest.cpp
@@ -1456,18 +1456,20 @@
 
   std::unique_ptr
   getFromYAMLRawString(StringRef Content,
-   IntrusiveRefCntPtr ExternalFS) {
+   IntrusiveRefCntPtr ExternalFS,
+   StringRef YAMLFilePath = "") {
 std::unique_ptr Buffer = MemoryBuffer::getMemBuffer(Content);
-return getVFSFromYAML(std::move(Buffer), CountingDiagHandler, "", this,
-  ExternalFS);
+return getVFSFromYAML(std::move(Buffer), CountingDiagHandler, YAMLFilePath,
+  this, ExternalFS);
   }
 
   std::unique_ptr getFromYAMLString(
   StringRef Content,
-  IntrusiveRefCntPtr ExternalFS = new DummyFileSystem()) {
+  IntrusiveRefCntPtr ExternalFS = new DummyFileSystem(),
+  StringRef YAMLFilePath = "") {
 std::string VersionPlusContent("{\n  'version':0,\n");
 VersionPlusContent += Content.slice(Content.find('{') + 1, StringRef::npos);
-return getFromYAMLRawString(VersionPlusContent, ExternalFS);
+return getFromYAMLRawString(VersionPlusContent, ExternalFS, YAMLFilePath);
   }
 
   // This is intended as a "XFAIL" for windows hosts.
@@ -1853,6 +1855,69 @@
   EXPECT_EQ(0, NumDiagnostics);
 }
 
+TEST_F(VFSFromYAMLTest, RootRelativeTest) {
+  IntrusiveRefCntPtr Lower(new DummyFileSystem());
+  Lower->addDirectory("//root/foo/bar");
+  Lower->addRegularFile("//root/foo/bar/a");
+  IntrusiveRefCntPtr FS =
+  getFromYAMLString("{\n"
+"  'case-sensitive': false,\n"
+"  'root-relative': 'overlay-dir',\n"
+"  'roots': [\n"
+"{ 'name': 'b', 'type': 'file',\n"
+"  'external-contents': '//root/foo/bar/a'\n"
+"}\n"
+"  ]\n"
+"}",
+Lower, "//root/foo/bar/overlay");
+
+  ASSERT_NE(FS.get(), nullptr);
+  ErrorOr S = FS->status("//root/foo/bar/b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("//root/foo/bar/a", S->getName());
+
+  // On Windows, with overlay-relative set to true, the relative
+  // path in external-contents field will be prepend by OverlayDir
+  // with native path separator, regardless of the actual path separator
+  // used in YAMLFilePath field.
+#ifndef _WIN32
+  FS = getFromYAMLString("{\n"
+ "  'case-sensitive': false,\n"
+ "  'overlay-relative': true,\n"
+ "  'root-relative': 'overlay-dir',\n"
+ "  'roots': [\n"
+ "{ 'name': 'b', 'type': 'file',\n"
+ "  'external-contents': 'a'\n"
+ "}\n"
+ "  ]\n"
+ "}",
+ Lower, "//root/foo/bar/overlay");
+  ASSERT_NE(FS.get(), nullptr);
+  S = FS->status("//root/foo/bar/b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("//root/foo/bar/a", S->getName());
+#else
+  IntrusiveRefCntPtr LowerWindows(new DummyFileSystem());
+  LowerWindows->addDirectory("root\\foo\\bar");
+  LowerWindows->addRegularFile("root\\foo\\bar\\a");
+  FS = getFromYAMLString("{\n"
+ "  'case-sensitive': false,\n"
+ "  'overlay-relative': true,\n"
+ "  'root-relative': 'overlay-dir',\n"
+ "  'roots': [\n"
+ "{ 'name': 'b', 'type': 'file',\n"
+ "  'external-contents': 'a'\n"
+ "}\n"
+ "  ]\n"
+ "}",
+ LowerWindows, "root\\foo\\bar\\overlay");
+  ASSERT_NE(FS.get(), nullptr);
+  S = FS->status("root\\foo\\bar\\b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("root\\foo\\bar\\a", S->getName());
+#endif
+}
+
 TEST_F(VFSFromYAMLTest, ReturnsInternalPathVFSHit) {
   IntrusiveRefCntPtr BaseFS(
   new vfs::InMemoryFileSystem);
Index: llvm/lib/Support/VirtualFileSystem.cpp
===
--- llvm/lib/Support/VirtualFileSystem.cpp
+++ llvm/lib/Support/VirtualFileSystem.cpp
@@ -1350,32 +1350,51 @@
   if (llvm::sys::path::is_absolute(Path, llvm::sys::path::Style::posix) ||
 

[PATCH] D137473: [vfs] Allow root paths relative to the directory of the vfsoverlay YAML file

2022-12-13 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 482658.
haowei added a comment.

Rebased the change to solve the merge conflicts on the bots.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137473/new/

https://reviews.llvm.org/D137473

Files:
  clang/test/VFS/Inputs/root-relative-overlay.yaml
  clang/test/VFS/relative-path.c
  llvm/include/llvm/Support/VirtualFileSystem.h
  llvm/lib/Support/VirtualFileSystem.cpp
  llvm/unittests/Support/VirtualFileSystemTest.cpp

Index: llvm/unittests/Support/VirtualFileSystemTest.cpp
===
--- llvm/unittests/Support/VirtualFileSystemTest.cpp
+++ llvm/unittests/Support/VirtualFileSystemTest.cpp
@@ -1456,18 +1456,20 @@
 
   std::unique_ptr
   getFromYAMLRawString(StringRef Content,
-   IntrusiveRefCntPtr ExternalFS) {
+   IntrusiveRefCntPtr ExternalFS,
+   StringRef YAMLFilePath = "") {
 std::unique_ptr Buffer = MemoryBuffer::getMemBuffer(Content);
-return getVFSFromYAML(std::move(Buffer), CountingDiagHandler, "", this,
-  ExternalFS);
+return getVFSFromYAML(std::move(Buffer), CountingDiagHandler, YAMLFilePath,
+  this, ExternalFS);
   }
 
   std::unique_ptr getFromYAMLString(
   StringRef Content,
-  IntrusiveRefCntPtr ExternalFS = new DummyFileSystem()) {
+  IntrusiveRefCntPtr ExternalFS = new DummyFileSystem(),
+  StringRef YAMLFilePath = "") {
 std::string VersionPlusContent("{\n  'version':0,\n");
 VersionPlusContent += Content.slice(Content.find('{') + 1, StringRef::npos);
-return getFromYAMLRawString(VersionPlusContent, ExternalFS);
+return getFromYAMLRawString(VersionPlusContent, ExternalFS, YAMLFilePath);
   }
 
   // This is intended as a "XFAIL" for windows hosts.
@@ -1853,6 +1855,69 @@
   EXPECT_EQ(0, NumDiagnostics);
 }
 
+TEST_F(VFSFromYAMLTest, RootRelativeTest) {
+  IntrusiveRefCntPtr Lower(new DummyFileSystem());
+  Lower->addDirectory("//root/foo/bar");
+  Lower->addRegularFile("//root/foo/bar/a");
+  IntrusiveRefCntPtr FS =
+  getFromYAMLString("{\n"
+"  'case-sensitive': false,\n"
+"  'root-relative': 'overlay-dir',\n"
+"  'roots': [\n"
+"{ 'name': 'b', 'type': 'file',\n"
+"  'external-contents': '//root/foo/bar/a'\n"
+"}\n"
+"  ]\n"
+"}",
+Lower, "//root/foo/bar/overlay");
+
+  ASSERT_NE(FS.get(), nullptr);
+  ErrorOr S = FS->status("//root/foo/bar/b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("//root/foo/bar/a", S->getName());
+
+  // On Windows, with overlay-relative set to true, the relative
+  // path in external-contents field will be prepend by OverlayDir
+  // with native path separator, regardless of the actual path separator
+  // used in YAMLFilePath field.
+#ifndef _WIN32
+  FS = getFromYAMLString("{\n"
+ "  'case-sensitive': false,\n"
+ "  'overlay-relative': true,\n"
+ "  'root-relative': 'overlay-dir',\n"
+ "  'roots': [\n"
+ "{ 'name': 'b', 'type': 'file',\n"
+ "  'external-contents': 'a'\n"
+ "}\n"
+ "  ]\n"
+ "}",
+ Lower, "//root/foo/bar/overlay");
+  ASSERT_NE(FS.get(), nullptr);
+  S = FS->status("//root/foo/bar/b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("//root/foo/bar/a", S->getName());
+#else
+  IntrusiveRefCntPtr LowerWindows(new DummyFileSystem());
+  LowerWindows->addDirectory("root\\foo\\bar");
+  LowerWindows->addRegularFile("root\\foo\\bar\\a");
+  FS = getFromYAMLString("{\n"
+ "  'case-sensitive': false,\n"
+ "  'overlay-relative': true,\n"
+ "  'root-relative': 'overlay-dir',\n"
+ "  'roots': [\n"
+ "{ 'name': 'b', 'type': 'file',\n"
+ "  'external-contents': 'a'\n"
+ "}\n"
+ "  ]\n"
+ "}",
+ LowerWindows, "root\\foo\\bar\\overlay");
+  ASSERT_NE(FS.get(), nullptr);
+  S = FS->status("root\\foo\\bar\\b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("root\\foo\\bar\\a", S->getName());
+#endif
+}
+
 TEST_F(VFSFromYAMLTest, ReturnsInternalPathVFSHit) {
   IntrusiveRefCntPtr BaseFS(
   new vfs::InMemoryFileSystem);
Index: llvm/lib/Support/VirtualFileSystem.cpp
===
--- llvm/lib/Support/VirtualFileSystem.cpp
+++ llvm/lib/Support/VirtualFileSystem.cpp
@@ -1350,32 

[PATCH] D137473: [vfs] Allow root paths relative to the directory of the vfsoverlay YAML file

2022-12-13 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

I changed some comments and add more details.
If there is no objection, can I get an approval on this change so I can land 
it? It will unblock our development on Windows cross compilation support.




Comment at: llvm/lib/Support/VirtualFileSystem.cpp:1933-1935
 path_style = sys::path::is_absolute(Name, sys::path::Style::posix)
  ? sys::path::Style::posix
  : sys::path::Style::windows_backslash;

phosek wrote:
> haowei wrote:
> > bnbarham wrote:
> > > `windows_slash` is going to be `windows_backslash` here. I assume this 
> > > was fine since `sys::fs::make_absolute(Name)` would always return the 
> > > native style, but that isn't the case now. It's also unfortunate we 
> > > calculate this again when `makeAbsolute` only just did it.
> > Thanks for pointing that out. I need to consider the windows forward slash 
> > case.
> > 
> > There is a bit in consistency in the VFS implementation. for Windows. we 
> > can use forward slashes('/') on Windows. Most Windows API/Syscalls accept 
> > it. But some APIs may not work if you mix '/' with '\' in the path on 
> > Windows. What RedirectFileSystem::makeAbsolute is trying to do is, it first 
> > determine the slashes used in the WorkDir(either from process working 
> > directory or from command line flags, or OverlayDir), in which it can be a 
> > forward slash on Windows. Then it uses the same separator when appending 
> > the relative directory.  Using sys::fs::make_absolute will break that. 
> > 
> > The reason that I use makeAbsolute here is that the OverlayDir will likely 
> > use forward slash on Windows if people uses CMake options 
> > LINK_FLAG="/vfsoverlay:C:/path/to/overlay.xml". In that case, 
> > sys::fs::make_absolute will generate some paths like C:/path/to/foo\\bar, 
> > which may cause issues.
> > 
> > I will rewrite this to consider the forward slashes.
> This was also discussed in D87732 which may provide some additional context.
I looked into the implementation of llvm path library and how 
`windows_backslash` and `windows_slash` are implemented and used. 
TL;DR,
The difference between `windows_backslash` and `windows_slash` is that when 
llvm::get_separator is called, it returns a different slash. The rest of the 
API behaviors are the same. So in this `VirtualFileSystem.cpp`, it doesn't 
matter if the path_style is assigned to 
sys::path::Style::windows_backslash or sys::path::Style::windows_slash here as 
the output of this function `parseEntry` will be the same.



Comment at: llvm/unittests/Support/VirtualFileSystemTest.cpp:1878
+  // with native path seperator, regardless of the actual path seperator
+  // used in YAMLFilePath field.
+#ifndef _WIN32

haowei wrote:
> rnk wrote:
> > dexonsmith wrote:
> > > bnbarham wrote:
> > > > `separator` -> `separator`
> > > > 
> > > > As per my comment above, this is only true because we're either using 
> > > > posix or windows_backslash. I'm not sure what we really want here, 
> > > > should we always convert to native? Any thoughts @dexonsmith?
> > > > 
> > > > FWIW the non-windows case is identical to the above block. It'd be 
> > > > interesting to test `/` and `\` on both filesystems.
> > > I think we might need a Windows person to help answer; @rnk, can you 
> > > suggest someone to help answer @bnbarham's question?
> > I can try suggesting @hans, @compnerd, or @Bigcheese 
> The non-windows case enable the overlay-relative option. The above block 
> didn't. And that is where I discover the issue with overlay-relative always 
> uses native separator instead of trying to match OverlayDir.
> 
> The best approach for root-relative and overlay-relative option would 
> probably be matching the style of OverlayDir/WorkDir and unify the path 
> separator if they are mixed in a path.
> But this change will likely affects a few tests.
I corrected the typo.

I did some Windows API tests in the past week and I can confirm on Windows 10 
(but should be apply to all NT6 family Windows), the forward slashes "/" and 
backward slashes "\" are both legit path separators and they be mixed in a path 
in any combinations. They will behave properly and no errors will be reported. 
However, the cmd.exe and some other Windows program will have some issue if 
forward slashes is used or mixed with backward slashes because it looks like 
flag switches, probably because these programs parse the user Input and doing 
their own path processing before invoking Windows APIs.

In LLVM's case, since File IO will rely on Windows APIs, I think how my current 
code handling the path separators under relative path scenario is sufficient. 
It shouldn't bring new issues.

On Linux and other POSIX OS, the backward slash is a legit path character. 
e.g.
/foo/bar/\\a/b means 
```
foo
├- bar
  ├ `\a`
├ b
```
Therefore, if backward slashes are used in the overlay file under 

[PATCH] D137473: [vfs] Allow root paths relative to the directory of the vfsoverlay YAML file

2022-12-13 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 482644.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137473/new/

https://reviews.llvm.org/D137473

Files:
  clang/test/VFS/Inputs/root-relative-overlay.yaml
  clang/test/VFS/relative-path.c
  llvm/include/llvm/Support/VirtualFileSystem.h
  llvm/lib/Support/VirtualFileSystem.cpp
  llvm/unittests/Support/VirtualFileSystemTest.cpp

Index: llvm/unittests/Support/VirtualFileSystemTest.cpp
===
--- llvm/unittests/Support/VirtualFileSystemTest.cpp
+++ llvm/unittests/Support/VirtualFileSystemTest.cpp
@@ -1452,18 +1452,20 @@
 
   std::unique_ptr
   getFromYAMLRawString(StringRef Content,
-   IntrusiveRefCntPtr ExternalFS) {
+   IntrusiveRefCntPtr ExternalFS,
+   StringRef YAMLFilePath = "") {
 std::unique_ptr Buffer = MemoryBuffer::getMemBuffer(Content);
-return getVFSFromYAML(std::move(Buffer), CountingDiagHandler, "", this,
-  ExternalFS);
+return getVFSFromYAML(std::move(Buffer), CountingDiagHandler, YAMLFilePath,
+  this, ExternalFS);
   }
 
   std::unique_ptr getFromYAMLString(
   StringRef Content,
-  IntrusiveRefCntPtr ExternalFS = new DummyFileSystem()) {
+  IntrusiveRefCntPtr ExternalFS = new DummyFileSystem(),
+  StringRef YAMLFilePath = "") {
 std::string VersionPlusContent("{\n  'version':0,\n");
 VersionPlusContent += Content.slice(Content.find('{') + 1, StringRef::npos);
-return getFromYAMLRawString(VersionPlusContent, ExternalFS);
+return getFromYAMLRawString(VersionPlusContent, ExternalFS, YAMLFilePath);
   }
 
   // This is intended as a "XFAIL" for windows hosts.
@@ -1849,6 +1851,69 @@
   EXPECT_EQ(0, NumDiagnostics);
 }
 
+TEST_F(VFSFromYAMLTest, RootRelativeTest) {
+  IntrusiveRefCntPtr Lower(new DummyFileSystem());
+  Lower->addDirectory("//root/foo/bar");
+  Lower->addRegularFile("//root/foo/bar/a");
+  IntrusiveRefCntPtr FS =
+  getFromYAMLString("{\n"
+"  'case-sensitive': false,\n"
+"  'root-relative': 'overlay-dir',\n"
+"  'roots': [\n"
+"{ 'name': 'b', 'type': 'file',\n"
+"  'external-contents': '//root/foo/bar/a'\n"
+"}\n"
+"  ]\n"
+"}",
+Lower, "//root/foo/bar/overlay");
+
+  ASSERT_NE(FS.get(), nullptr);
+  ErrorOr S = FS->status("//root/foo/bar/b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("//root/foo/bar/a", S->getName());
+
+  // On Windows, with overlay-relative set to true, the relative
+  // path in external-contents field will be prepend by OverlayDir
+  // with native path separator, regardless of the actual path separator
+  // used in YAMLFilePath field.
+#ifndef _WIN32
+  FS = getFromYAMLString("{\n"
+ "  'case-sensitive': false,\n"
+ "  'overlay-relative': true,\n"
+ "  'root-relative': 'overlay-dir',\n"
+ "  'roots': [\n"
+ "{ 'name': 'b', 'type': 'file',\n"
+ "  'external-contents': 'a'\n"
+ "}\n"
+ "  ]\n"
+ "}",
+ Lower, "//root/foo/bar/overlay");
+  ASSERT_NE(FS.get(), nullptr);
+  S = FS->status("//root/foo/bar/b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("//root/foo/bar/a", S->getName());
+#else
+  IntrusiveRefCntPtr LowerWindows(new DummyFileSystem());
+  LowerWindows->addDirectory("root\\foo\\bar");
+  LowerWindows->addRegularFile("root\\foo\\bar\\a");
+  FS = getFromYAMLString("{\n"
+ "  'case-sensitive': false,\n"
+ "  'overlay-relative': true,\n"
+ "  'root-relative': 'overlay-dir',\n"
+ "  'roots': [\n"
+ "{ 'name': 'b', 'type': 'file',\n"
+ "  'external-contents': 'a'\n"
+ "}\n"
+ "  ]\n"
+ "}",
+ LowerWindows, "root\\foo\\bar\\overlay");
+  ASSERT_NE(FS.get(), nullptr);
+  S = FS->status("root\\foo\\bar\\b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("root\\foo\\bar\\a", S->getName());
+#endif
+}
+
 TEST_F(VFSFromYAMLTest, ReturnsInternalPathVFSHit) {
   IntrusiveRefCntPtr BaseFS(
   new vfs::InMemoryFileSystem);
Index: llvm/lib/Support/VirtualFileSystem.cpp
===
--- llvm/lib/Support/VirtualFileSystem.cpp
+++ llvm/lib/Support/VirtualFileSystem.cpp
@@ -1350,32 +1350,51 @@
   if (llvm::sys::path::is_absolute(Path, llvm::sys::path::Style::posix) ||
 

[PATCH] D137473: [vfs] Allow root paths relative to the directory of the vfsoverlay YAML file

2022-11-18 Thread Haowei Wu via Phabricator via cfe-commits
haowei added inline comments.



Comment at: llvm/lib/Support/VirtualFileSystem.cpp:1922
+  EC = FS->makeAbsolute(FullPath, Name);
+  Name = canonicalize(Name);
+} else {

bnbarham wrote:
> Why the canonicalization?
If the Name here somehow has something like //foo/./../bar, it will cause match 
failures. Canonicalize function removes these dots.
The setOverlayFileDir does not canonicalize the dir so this is quite common to 
see.



Comment at: llvm/lib/Support/VirtualFileSystem.cpp:1933-1935
 path_style = sys::path::is_absolute(Name, sys::path::Style::posix)
  ? sys::path::Style::posix
  : sys::path::Style::windows_backslash;

bnbarham wrote:
> `windows_slash` is going to be `windows_backslash` here. I assume this was 
> fine since `sys::fs::make_absolute(Name)` would always return the native 
> style, but that isn't the case now. It's also unfortunate we calculate this 
> again when `makeAbsolute` only just did it.
Thanks for pointing that out. I need to consider the windows forward slash case.

There is a bit in consistency in the VFS implementation. for Windows. we can 
use forward slashes('/') on Windows. Most Windows API/Syscalls accept it. But 
some APIs may not work if you mix '/' with '\' in the path on Windows. What 
RedirectFileSystem::makeAbsolute is trying to do is, it first determine the 
slashes used in the WorkDir(either from process working directory or from 
command line flags, or OverlayDir), in which it can be a forward slash on 
Windows. Then it uses the same separator when appending the relative directory. 
 Using sys::fs::make_absolute will break that. 

The reason that I use makeAbsolute here is that the OverlayDir will likely use 
forward slash on Windows if people uses CMake options 
LINK_FLAG="/vfsoverlay:C:/path/to/overlay.xml". In that case, 
sys::fs::make_absolute will generate some paths like C:/path/to/foo\\bar, which 
may cause issues.

I will rewrite this to consider the forward slashes.



Comment at: llvm/unittests/Support/VirtualFileSystemTest.cpp:1878
+  // with native path seperator, regardless of the actual path seperator
+  // used in YAMLFilePath field.
+#ifndef _WIN32

rnk wrote:
> dexonsmith wrote:
> > bnbarham wrote:
> > > `separator` -> `separator`
> > > 
> > > As per my comment above, this is only true because we're either using 
> > > posix or windows_backslash. I'm not sure what we really want here, should 
> > > we always convert to native? Any thoughts @dexonsmith?
> > > 
> > > FWIW the non-windows case is identical to the above block. It'd be 
> > > interesting to test `/` and `\` on both filesystems.
> > I think we might need a Windows person to help answer; @rnk, can you 
> > suggest someone to help answer @bnbarham's question?
> I can try suggesting @hans, @compnerd, or @Bigcheese 
The non-windows case enable the overlay-relative option. The above block 
didn't. And that is where I discover the issue with overlay-relative always 
uses native separator instead of trying to match OverlayDir.

The best approach for root-relative and overlay-relative option would probably 
be matching the style of OverlayDir/WorkDir and unify the path separator if 
they are mixed in a path.
But this change will likely affects a few tests.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137473/new/

https://reviews.llvm.org/D137473

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137473: [vfs] Allow root paths relative to the directory of the vfsoverlay YAML file

2022-11-16 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 475884.
haowei marked 2 inline comments as done.
haowei added a comment.

Fixing Windows test failures.
overlay-relative flag will always using native path separator, therefore, it 
needs a separate base FS and OverlayYAML file setup on Windows. This diff adds 
this.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137473/new/

https://reviews.llvm.org/D137473

Files:
  clang/test/VFS/Inputs/root-relative-overlay.yaml
  clang/test/VFS/relative-path.c
  llvm/include/llvm/Support/VirtualFileSystem.h
  llvm/lib/Support/VirtualFileSystem.cpp
  llvm/unittests/Support/VirtualFileSystemTest.cpp

Index: llvm/unittests/Support/VirtualFileSystemTest.cpp
===
--- llvm/unittests/Support/VirtualFileSystemTest.cpp
+++ llvm/unittests/Support/VirtualFileSystemTest.cpp
@@ -1452,18 +1452,20 @@
 
   std::unique_ptr
   getFromYAMLRawString(StringRef Content,
-   IntrusiveRefCntPtr ExternalFS) {
+   IntrusiveRefCntPtr ExternalFS,
+   StringRef YAMLFilePath = "") {
 std::unique_ptr Buffer = MemoryBuffer::getMemBuffer(Content);
-return getVFSFromYAML(std::move(Buffer), CountingDiagHandler, "", this,
-  ExternalFS);
+return getVFSFromYAML(std::move(Buffer), CountingDiagHandler, YAMLFilePath,
+  this, ExternalFS);
   }
 
   std::unique_ptr getFromYAMLString(
   StringRef Content,
-  IntrusiveRefCntPtr ExternalFS = new DummyFileSystem()) {
+  IntrusiveRefCntPtr ExternalFS = new DummyFileSystem(),
+  StringRef YAMLFilePath = "") {
 std::string VersionPlusContent("{\n  'version':0,\n");
 VersionPlusContent += Content.slice(Content.find('{') + 1, StringRef::npos);
-return getFromYAMLRawString(VersionPlusContent, ExternalFS);
+return getFromYAMLRawString(VersionPlusContent, ExternalFS, YAMLFilePath);
   }
 
   // This is intended as a "XFAIL" for windows hosts.
@@ -1849,6 +1851,69 @@
   EXPECT_EQ(0, NumDiagnostics);
 }
 
+TEST_F(VFSFromYAMLTest, RootRelativeTest) {
+  IntrusiveRefCntPtr Lower(new DummyFileSystem());
+  Lower->addDirectory("//root/foo/bar");
+  Lower->addRegularFile("//root/foo/bar/a");
+  IntrusiveRefCntPtr FS =
+  getFromYAMLString("{\n"
+"  'case-sensitive': false,\n"
+"  'root-relative': 'overlay-dir',\n"
+"  'roots': [\n"
+"{ 'name': 'b', 'type': 'file',\n"
+"  'external-contents': '//root/foo/bar/a'\n"
+"}\n"
+"  ]\n"
+"}",
+Lower, "//root/foo/bar/overlay");
+
+  ASSERT_NE(FS.get(), nullptr);
+  ErrorOr S = FS->status("//root/foo/bar/b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("//root/foo/bar/a", S->getName());
+
+  // On Windows, with overlay-relative set to true, the relative
+  // path in external-contents field will be prepend by OverlayDir
+  // with native path seperator, regardless of the actual path seperator
+  // used in YAMLFilePath field.
+#ifndef _WIN32
+  FS = getFromYAMLString("{\n"
+ "  'case-sensitive': false,\n"
+ "  'overlay-relative': true,\n"
+ "  'root-relative': 'overlay-dir',\n"
+ "  'roots': [\n"
+ "{ 'name': 'b', 'type': 'file',\n"
+ "  'external-contents': 'a'\n"
+ "}\n"
+ "  ]\n"
+ "}",
+ Lower, "//root/foo/bar/overlay");
+  ASSERT_NE(FS.get(), nullptr);
+  S = FS->status("//root/foo/bar/b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("//root/foo/bar/a", S->getName());
+#else
+  IntrusiveRefCntPtr LowerWindows(new DummyFileSystem());
+  LowerWindows->addDirectory("root\\foo\\bar");
+  LowerWindows->addRegularFile("root\\foo\\bar\\a");
+  FS = getFromYAMLString("{\n"
+ "  'case-sensitive': false,\n"
+ "  'overlay-relative': true,\n"
+ "  'root-relative': 'overlay-dir',\n"
+ "  'roots': [\n"
+ "{ 'name': 'b', 'type': 'file',\n"
+ "  'external-contents': 'a'\n"
+ "}\n"
+ "  ]\n"
+ "}",
+ LowerWindows, "root\\foo\\bar\\overlay");
+  ASSERT_NE(FS.get(), nullptr);
+  S = FS->status("root\\foo\\bar\\b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("root\\foo\\bar\\a", S->getName());
+#endif
+}
+
 TEST_F(VFSFromYAMLTest, ReturnsInternalPathVFSHit) {
   IntrusiveRefCntPtr BaseFS(
   new vfs::InMemoryFileSystem);
Index: 

[PATCH] D137473: [vfs] Allow root paths relative to the directory of the vfsoverlay YAML file

2022-11-15 Thread Haowei Wu via Phabricator via cfe-commits
haowei marked 2 inline comments as done.
haowei added inline comments.



Comment at: llvm/include/llvm/Support/VirtualFileSystem.h:1010
 
+  std::error_code makeAbsolute(StringRef WorkingDir,
+   SmallVectorImpl ) const;

bnbarham wrote:
> Should be private IMO
Moved it to private section and added comments



Comment at: llvm/lib/Support/VirtualFileSystem.cpp:1369
   // append Path ourselves.
+  if (!sys::path::is_absolute(WorkingDir, sys::path::Style::posix) &&
+  !sys::path::is_absolute(WorkingDir,

bnbarham wrote:
> Did you find this was needed? It's already checked by the normal 
> `makeAbsolute` (which checks this already) and the only other caller is when 
> we're using the overlay directory path, which should always be absolute.
No, it is not needed for now. As the OverlayDir is always abs when it was set. 
The normal makeAbsolute function checks "Path" param but not checking the 
returned WorkDir, which is OK because the return value from 
getCurrentWorkingDirectory will be abs or empty.

It is more to be future proof if someone decide to use this function for other 
purpose and putting a non-abs path in WorkingDir field will causes unexpected 
behaviors.

I also need to exclude empty WorkingDir though because in unit tests, the 
WorkingDir is always empty.




Comment at: llvm/lib/Support/VirtualFileSystem.cpp:1913
+ RedirectingFileSystem::RootRelativeKind::OverlayDir) {
+SmallString<256> FullPath = FS->getOverlayFileDir();
+assert(!FullPath.empty() && "Overlay file directory must exist");

bnbarham wrote:
> This is unused now. Maybe we should just merge the `else if` and `else` 
> branches and just grab either `getOverlayFileDir` or 
> `getCurrentWorkingDirectory` depending on `RootRelative`. They should 
> otherwise be identical.
I merged these 2 else block.
I have to use sys::fs::make_absolute function for now as using FS's CWD will 
break a few tests. It is better to address these test in a separate patch.



Comment at: llvm/unittests/Support/VirtualFileSystemTest.cpp:1875
+
+  IntrusiveRefCntPtr FSOverlayRelative =
+  getFromYAMLString("{\n"

bnbarham wrote:
> Just override the previous `FS`/`S` IMO - that way we avoid the accidental 
> `FS->status` a few lines down 
Thanks for pointing that out 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137473/new/

https://reviews.llvm.org/D137473

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137473: [vfs] Allow root paths relative to the directory of the vfsoverlay YAML file

2022-11-15 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 475591.
haowei added a comment.

Address review comments


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137473/new/

https://reviews.llvm.org/D137473

Files:
  clang/test/VFS/Inputs/root-relative-overlay.yaml
  clang/test/VFS/relative-path.c
  llvm/include/llvm/Support/VirtualFileSystem.h
  llvm/lib/Support/VirtualFileSystem.cpp
  llvm/unittests/Support/VirtualFileSystemTest.cpp

Index: llvm/unittests/Support/VirtualFileSystemTest.cpp
===
--- llvm/unittests/Support/VirtualFileSystemTest.cpp
+++ llvm/unittests/Support/VirtualFileSystemTest.cpp
@@ -1452,18 +1452,20 @@
 
   std::unique_ptr
   getFromYAMLRawString(StringRef Content,
-   IntrusiveRefCntPtr ExternalFS) {
+   IntrusiveRefCntPtr ExternalFS,
+   StringRef YAMLFilePath = "") {
 std::unique_ptr Buffer = MemoryBuffer::getMemBuffer(Content);
-return getVFSFromYAML(std::move(Buffer), CountingDiagHandler, "", this,
-  ExternalFS);
+return getVFSFromYAML(std::move(Buffer), CountingDiagHandler, YAMLFilePath,
+  this, ExternalFS);
   }
 
   std::unique_ptr getFromYAMLString(
   StringRef Content,
-  IntrusiveRefCntPtr ExternalFS = new DummyFileSystem()) {
+  IntrusiveRefCntPtr ExternalFS = new DummyFileSystem(),
+  StringRef YAMLFilePath = "") {
 std::string VersionPlusContent("{\n  'version':0,\n");
 VersionPlusContent += Content.slice(Content.find('{') + 1, StringRef::npos);
-return getFromYAMLRawString(VersionPlusContent, ExternalFS);
+return getFromYAMLRawString(VersionPlusContent, ExternalFS, YAMLFilePath);
   }
 
   // This is intended as a "XFAIL" for windows hosts.
@@ -1849,6 +1851,44 @@
   EXPECT_EQ(0, NumDiagnostics);
 }
 
+TEST_F(VFSFromYAMLTest, RootRelativeTest) {
+  IntrusiveRefCntPtr Lower(new DummyFileSystem());
+  Lower->addDirectory("//root/foo/bar");
+  Lower->addRegularFile("//root/foo/bar/a");
+  IntrusiveRefCntPtr FS =
+  getFromYAMLString("{\n"
+"  'case-sensitive': false,\n"
+"  'root-relative': 'overlay-dir',\n"
+"  'roots': [\n"
+"{ 'name': 'b', 'type': 'file',\n"
+"  'external-contents': '//root/foo/bar/a'\n"
+"}\n"
+"  ]\n"
+"}",
+Lower, "//root/foo/bar/overlay");
+
+  ASSERT_NE(FS.get(), nullptr);
+  ErrorOr S = FS->status("//root/foo/bar/b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("//root/foo/bar/a", S->getName());
+
+  FS = getFromYAMLString("{\n"
+ "  'case-sensitive': false,\n"
+ "  'overlay-relative': true,\n"
+ "  'root-relative': 'overlay-dir',\n"
+ "  'roots': [\n"
+ "{ 'name': 'b', 'type': 'file',\n"
+ "  'external-contents': 'a'\n"
+ "}\n"
+ "  ]\n"
+ "}",
+ Lower, "//root/foo/bar/overlay");
+  ASSERT_NE(FS.get(), nullptr);
+  S = FS->status("//root/foo/bar/b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("//root/foo/bar/a", S->getName());
+}
+
 TEST_F(VFSFromYAMLTest, ReturnsInternalPathVFSHit) {
   IntrusiveRefCntPtr BaseFS(
   new vfs::InMemoryFileSystem);
Index: llvm/lib/Support/VirtualFileSystem.cpp
===
--- llvm/lib/Support/VirtualFileSystem.cpp
+++ llvm/lib/Support/VirtualFileSystem.cpp
@@ -1356,22 +1356,33 @@
   if (!WorkingDir)
 return WorkingDir.getError();
 
+  return makeAbsolute(WorkingDir.get(), Path);
+}
+
+std::error_code
+RedirectingFileSystem::makeAbsolute(StringRef WorkingDir,
+SmallVectorImpl ) const {
   // We can't use sys::fs::make_absolute because that assumes the path style
   // is native and there is no way to override that.  Since we know WorkingDir
   // is absolute, we can use it to determine which style we actually have and
   // append Path ourselves.
+  if (!WorkingDir.empty() &&
+  !sys::path::is_absolute(WorkingDir, sys::path::Style::posix) &&
+  !sys::path::is_absolute(WorkingDir,
+  sys::path::Style::windows_backslash)) {
+return std::error_code();
+  }
   sys::path::Style style = sys::path::Style::windows_backslash;
-  if (sys::path::is_absolute(WorkingDir.get(), sys::path::Style::posix)) {
+  if (sys::path::is_absolute(WorkingDir, sys::path::Style::posix)) {
 style = sys::path::Style::posix;
   } else {
 // Distinguish between windows_backslash and windows_slash; getExistingStyle
 // returns posix for a path with windows_slash.
-if 

[PATCH] D137473: [vfs] Allow root paths relative to the directory of the vfsoverlay YAML file

2022-11-15 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 475574.
haowei added a comment.

I have to revert back to use process cwd instead of base fs cwd. There are a 
few tests relied the behavior of using process cwd that I need to take a closer 
look.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137473/new/

https://reviews.llvm.org/D137473

Files:
  clang/test/VFS/Inputs/root-relative-overlay.yaml
  clang/test/VFS/relative-path.c
  llvm/include/llvm/Support/VirtualFileSystem.h
  llvm/lib/Support/VirtualFileSystem.cpp
  llvm/unittests/Support/VirtualFileSystemTest.cpp

Index: llvm/unittests/Support/VirtualFileSystemTest.cpp
===
--- llvm/unittests/Support/VirtualFileSystemTest.cpp
+++ llvm/unittests/Support/VirtualFileSystemTest.cpp
@@ -1452,18 +1452,20 @@
 
   std::unique_ptr
   getFromYAMLRawString(StringRef Content,
-   IntrusiveRefCntPtr ExternalFS) {
+   IntrusiveRefCntPtr ExternalFS,
+   StringRef YAMLFilePath = "") {
 std::unique_ptr Buffer = MemoryBuffer::getMemBuffer(Content);
-return getVFSFromYAML(std::move(Buffer), CountingDiagHandler, "", this,
-  ExternalFS);
+return getVFSFromYAML(std::move(Buffer), CountingDiagHandler, YAMLFilePath,
+  this, ExternalFS);
   }
 
   std::unique_ptr getFromYAMLString(
   StringRef Content,
-  IntrusiveRefCntPtr ExternalFS = new DummyFileSystem()) {
+  IntrusiveRefCntPtr ExternalFS = new DummyFileSystem(),
+  StringRef YAMLFilePath = "") {
 std::string VersionPlusContent("{\n  'version':0,\n");
 VersionPlusContent += Content.slice(Content.find('{') + 1, StringRef::npos);
-return getFromYAMLRawString(VersionPlusContent, ExternalFS);
+return getFromYAMLRawString(VersionPlusContent, ExternalFS, YAMLFilePath);
   }
 
   // This is intended as a "XFAIL" for windows hosts.
@@ -1849,6 +1851,45 @@
   EXPECT_EQ(0, NumDiagnostics);
 }
 
+TEST_F(VFSFromYAMLTest, RootRelativeTest) {
+  IntrusiveRefCntPtr Lower(new DummyFileSystem());
+  Lower->addDirectory("//root/foo/bar");
+  Lower->addRegularFile("//root/foo/bar/a");
+  IntrusiveRefCntPtr FS =
+  getFromYAMLString("{\n"
+"  'case-sensitive': false,\n"
+"  'root-relative': 'overlay-dir',\n"
+"  'roots': [\n"
+"{ 'name': 'b', 'type': 'file',\n"
+"  'external-contents': '//root/foo/bar/a'\n"
+"}\n"
+"  ]\n"
+"}",
+Lower, "//root/foo/bar/overlay");
+
+  ASSERT_NE(FS.get(), nullptr);
+  ErrorOr S = FS->status("//root/foo/bar/b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("//root/foo/bar/a", S->getName());
+
+  IntrusiveRefCntPtr FSOverlayRelative =
+  getFromYAMLString("{\n"
+"  'case-sensitive': false,\n"
+"  'overlay-relative': true,\n"
+"  'root-relative': 'overlay-dir',\n"
+"  'roots': [\n"
+"{ 'name': 'b', 'type': 'file',\n"
+"  'external-contents': 'a'\n"
+"}\n"
+"  ]\n"
+"}",
+Lower, "//root/foo/bar/overlay");
+  ASSERT_NE(FSOverlayRelative.get(), nullptr);
+  ErrorOr SOverlayRelative = FS->status("//root/foo/bar/b");
+  ASSERT_FALSE(SOverlayRelative.getError());
+  EXPECT_EQ("//root/foo/bar/a", SOverlayRelative->getName());
+}
+
 TEST_F(VFSFromYAMLTest, ReturnsInternalPathVFSHit) {
   IntrusiveRefCntPtr BaseFS(
   new vfs::InMemoryFileSystem);
Index: llvm/lib/Support/VirtualFileSystem.cpp
===
--- llvm/lib/Support/VirtualFileSystem.cpp
+++ llvm/lib/Support/VirtualFileSystem.cpp
@@ -1356,22 +1356,33 @@
   if (!WorkingDir)
 return WorkingDir.getError();
 
+  return makeAbsolute(WorkingDir.get(), Path);
+}
+
+std::error_code
+RedirectingFileSystem::makeAbsolute(StringRef WorkingDir,
+SmallVectorImpl ) const {
   // We can't use sys::fs::make_absolute because that assumes the path style
   // is native and there is no way to override that.  Since we know WorkingDir
   // is absolute, we can use it to determine which style we actually have and
   // append Path ourselves.
+  if (!WorkingDir.empty() &&
+  !sys::path::is_absolute(WorkingDir, sys::path::Style::posix) &&
+  !sys::path::is_absolute(WorkingDir,
+  sys::path::Style::windows_backslash)) {
+return std::error_code();
+  }
   sys::path::Style style = sys::path::Style::windows_backslash;
-  if (sys::path::is_absolute(WorkingDir.get(), sys::path::Style::posix)) {
+  if 

[PATCH] D137473: [vfs] Allow root paths relative to the directory of the vfsoverlay YAML file

2022-11-14 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 475347.
haowei added a comment.

Unit test failures under Windows should be fixed now.

Root->name will also use base FS's current directory instead of process current 
directory now. Please take a look.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137473/new/

https://reviews.llvm.org/D137473

Files:
  clang/test/VFS/Inputs/root-relative-overlay.yaml
  clang/test/VFS/relative-path.c
  llvm/include/llvm/Support/VirtualFileSystem.h
  llvm/lib/Support/VirtualFileSystem.cpp
  llvm/unittests/Support/VirtualFileSystemTest.cpp

Index: llvm/unittests/Support/VirtualFileSystemTest.cpp
===
--- llvm/unittests/Support/VirtualFileSystemTest.cpp
+++ llvm/unittests/Support/VirtualFileSystemTest.cpp
@@ -1452,18 +1452,20 @@
 
   std::unique_ptr
   getFromYAMLRawString(StringRef Content,
-   IntrusiveRefCntPtr ExternalFS) {
+   IntrusiveRefCntPtr ExternalFS,
+   StringRef YAMLFilePath = "") {
 std::unique_ptr Buffer = MemoryBuffer::getMemBuffer(Content);
-return getVFSFromYAML(std::move(Buffer), CountingDiagHandler, "", this,
-  ExternalFS);
+return getVFSFromYAML(std::move(Buffer), CountingDiagHandler, YAMLFilePath,
+  this, ExternalFS);
   }
 
   std::unique_ptr getFromYAMLString(
   StringRef Content,
-  IntrusiveRefCntPtr ExternalFS = new DummyFileSystem()) {
+  IntrusiveRefCntPtr ExternalFS = new DummyFileSystem(),
+  StringRef YAMLFilePath = "") {
 std::string VersionPlusContent("{\n  'version':0,\n");
 VersionPlusContent += Content.slice(Content.find('{') + 1, StringRef::npos);
-return getFromYAMLRawString(VersionPlusContent, ExternalFS);
+return getFromYAMLRawString(VersionPlusContent, ExternalFS, YAMLFilePath);
   }
 
   // This is intended as a "XFAIL" for windows hosts.
@@ -1849,6 +1851,45 @@
   EXPECT_EQ(0, NumDiagnostics);
 }
 
+TEST_F(VFSFromYAMLTest, RootRelativeTest) {
+  IntrusiveRefCntPtr Lower(new DummyFileSystem());
+  Lower->addDirectory("//root/foo/bar");
+  Lower->addRegularFile("//root/foo/bar/a");
+  IntrusiveRefCntPtr FS =
+  getFromYAMLString("{\n"
+"  'case-sensitive': false,\n"
+"  'root-relative': 'overlay-dir',\n"
+"  'roots': [\n"
+"{ 'name': 'b', 'type': 'file',\n"
+"  'external-contents': '//root/foo/bar/a'\n"
+"}\n"
+"  ]\n"
+"}",
+Lower, "//root/foo/bar/overlay");
+
+  ASSERT_NE(FS.get(), nullptr);
+  ErrorOr S = FS->status("//root/foo/bar/b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("//root/foo/bar/a", S->getName());
+
+  IntrusiveRefCntPtr FSOverlayRelative =
+  getFromYAMLString("{\n"
+"  'case-sensitive': false,\n"
+"  'overlay-relative': true,\n"
+"  'root-relative': 'overlay-dir',\n"
+"  'roots': [\n"
+"{ 'name': 'b', 'type': 'file',\n"
+"  'external-contents': 'a'\n"
+"}\n"
+"  ]\n"
+"}",
+Lower, "//root/foo/bar/overlay");
+  ASSERT_NE(FSOverlayRelative.get(), nullptr);
+  ErrorOr SOverlayRelative = FS->status("//root/foo/bar/b");
+  ASSERT_FALSE(SOverlayRelative.getError());
+  EXPECT_EQ("//root/foo/bar/a", SOverlayRelative->getName());
+}
+
 TEST_F(VFSFromYAMLTest, ReturnsInternalPathVFSHit) {
   IntrusiveRefCntPtr BaseFS(
   new vfs::InMemoryFileSystem);
Index: llvm/lib/Support/VirtualFileSystem.cpp
===
--- llvm/lib/Support/VirtualFileSystem.cpp
+++ llvm/lib/Support/VirtualFileSystem.cpp
@@ -1356,22 +1356,32 @@
   if (!WorkingDir)
 return WorkingDir.getError();
 
+  return makeAbsolute(WorkingDir.get(), Path);
+}
+
+std::error_code
+RedirectingFileSystem::makeAbsolute(StringRef WorkingDir,
+SmallVectorImpl ) const {
   // We can't use sys::fs::make_absolute because that assumes the path style
   // is native and there is no way to override that.  Since we know WorkingDir
   // is absolute, we can use it to determine which style we actually have and
   // append Path ourselves.
+  if (!sys::path::is_absolute(WorkingDir, sys::path::Style::posix) &&
+  !sys::path::is_absolute(WorkingDir,
+  sys::path::Style::windows_backslash)) {
+return std::error_code();
+  }
   sys::path::Style style = sys::path::Style::windows_backslash;
-  if (sys::path::is_absolute(WorkingDir.get(), sys::path::Style::posix)) {
+  if (sys::path::is_absolute(WorkingDir, 

[PATCH] D137473: [vfs] Allow root paths relative to the directory of the vfsoverlay YAML file

2022-11-09 Thread Haowei Wu via Phabricator via cfe-commits
haowei added inline comments.



Comment at: clang/test/VFS/Inputs/root-relative-overlay.yaml:4
+  'case-sensitive': false,
+  'overlay-relative': true,
+  'root-relative': 'yaml-dir',

haowei wrote:
> haowei wrote:
> > bnbarham wrote:
> > > bnbarham wrote:
> > > > I'd prefer a test without `overlay-relative` set to make it clear they 
> > > > don't depend on each other.
> > > There's also unit tests in 
> > > `llvm/unittests/Support/VirtualFileSystemTest.cpp` that you could add to.
> > I need some time to patch this unit test for testing the new option.
> > Existing functions in this unit test file does not support defining the 
> > YAMLFilePath.
> > 
> > I will update this patch when I finish.
> I updated the yaml file and add unit tests with overlay-relative set to true 
> and false.
I updated `llvm/unittests/Support/VirtualFileSystemTest.cpp` to include tests 
on `root-relative` option.



Comment at: llvm/lib/Support/VirtualFileSystem.cpp:1903
+assert(!FullPath.empty() && "YAML file directory must exist");
+sys::fs::make_absolute(FS->getYAMLFileDir(), Name);
+Name = canonicalize(Name);

bnbarham wrote:
> haowei wrote:
> > bnbarham wrote:
> > > IMO both this and CWD should be using the base FS instead. VFS didn't 
> > > have a CWD previously, but now that it does it doesn't really make sense 
> > > to use the process wide CWD. Especially since `-working-directory` 
> > > doesn't change it.
> > Could you clarify a bit more about the "base FS" please? I am still quite 
> > new to the LLVM VFS system.  Which API should I use to get the appropriate 
> > working directory instead of the the process wide CWD?
> > 
> > I avoided changing the default behavior (relative to the process's current 
> > working directory) as I am a bit concerned breaking other people's use 
> > cases. 
> > 
> > I looked up a bit, the value "--working-directory" will be writen into 
> > "VFS->setCurrentWorkingDirectory()" Do you think it is a better idea to use 
> > this value instead of the process current working directory? Though it 
> > would still be a behavior change for users rely on process current working 
> > directories. 
> > Could you clarify a bit more about the "base FS" please?
> 
> By "base FS" I just meant the filesystem that's passed down when creating the 
> RedirectingFileSystem, ie. `ExternalFS` in `getVFSFromYAML`.
> 
> > Which API should I use to get the appropriate working directory instead of 
> > the the process wide CWD?
> 
> `ExternalFS->getCurrentWorkingDirectory()` and `ExternalFS->makeAbsolute` is 
> what I'd expect to be used here.
> 
> > Do you think it is a better idea to use this value instead of the process 
> > current working directory? Though it would still be a behavior change for 
> > users rely on process current working directories.
> 
> Yes, I think it's surprising that it currently *isn't* using it. It's just a 
> hold over from when the VFS didn't have the concept of CWD. I'd be happy with 
> accepting this patch as is, with a separate patch after that changes to using 
> the VFS CWD.
> Yes, I think it's surprising that it currently *isn't* using it. It's just a 
> hold over from when the VFS didn't have the concept of CWD. I'd be happy with 
> accepting this patch as is, with a separate patch after that changes to using 
> the VFS CWD.

I see, I can upload a follow up change after this one is landed. to use VFS CWD 
instead of process CWD here. It is also easier to revert if anything goes wrong.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137473/new/

https://reviews.llvm.org/D137473

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137473: [vfs] Allow root paths relative to the directory of the vfsoverlay YAML file

2022-11-09 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 474391.
haowei added a comment.

Add additional unit test.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137473/new/

https://reviews.llvm.org/D137473

Files:
  clang/test/VFS/Inputs/root-relative-overlay.yaml
  clang/test/VFS/relative-path.c
  llvm/include/llvm/Support/VirtualFileSystem.h
  llvm/lib/Support/VirtualFileSystem.cpp
  llvm/unittests/Support/VirtualFileSystemTest.cpp

Index: llvm/unittests/Support/VirtualFileSystemTest.cpp
===
--- llvm/unittests/Support/VirtualFileSystemTest.cpp
+++ llvm/unittests/Support/VirtualFileSystemTest.cpp
@@ -1452,18 +1452,20 @@
 
   std::unique_ptr
   getFromYAMLRawString(StringRef Content,
-   IntrusiveRefCntPtr ExternalFS) {
+   IntrusiveRefCntPtr ExternalFS,
+   StringRef YAMLFilePath = "") {
 std::unique_ptr Buffer = MemoryBuffer::getMemBuffer(Content);
-return getVFSFromYAML(std::move(Buffer), CountingDiagHandler, "", this,
-  ExternalFS);
+return getVFSFromYAML(std::move(Buffer), CountingDiagHandler, YAMLFilePath,
+  this, ExternalFS);
   }
 
   std::unique_ptr getFromYAMLString(
   StringRef Content,
-  IntrusiveRefCntPtr ExternalFS = new DummyFileSystem()) {
+  IntrusiveRefCntPtr ExternalFS = new DummyFileSystem(),
+  StringRef YAMLFilePath = "") {
 std::string VersionPlusContent("{\n  'version':0,\n");
 VersionPlusContent += Content.slice(Content.find('{') + 1, StringRef::npos);
-return getFromYAMLRawString(VersionPlusContent, ExternalFS);
+return getFromYAMLRawString(VersionPlusContent, ExternalFS, YAMLFilePath);
   }
 
   // This is intended as a "XFAIL" for windows hosts.
@@ -1849,6 +1851,45 @@
   EXPECT_EQ(0, NumDiagnostics);
 }
 
+TEST_F(VFSFromYAMLTest, RootRelativeTest) {
+  IntrusiveRefCntPtr Lower(new DummyFileSystem());
+  Lower->addDirectory("//root/foo/bar");
+  Lower->addRegularFile("//root/foo/bar/a");
+  IntrusiveRefCntPtr FS =
+  getFromYAMLString("{\n"
+"  'case-sensitive': false,\n"
+"  'root-relative': 'overlay-dir',\n"
+"  'roots': [\n"
+"{ 'name': 'b', 'type': 'file',\n"
+"  'external-contents': '//root/foo/bar/a'\n"
+"}\n"
+"  ]\n"
+"}",
+Lower, "//root/foo/bar/overlay");
+
+  ASSERT_NE(FS.get(), nullptr);
+  ErrorOr S = FS->status("//root/foo/bar/b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("//root/foo/bar/a", S->getName());
+
+  IntrusiveRefCntPtr FSOverlayRelative =
+  getFromYAMLString("{\n"
+"  'case-sensitive': false,\n"
+"  'overlay-relative': true,\n"
+"  'root-relative': 'overlay-dir',\n"
+"  'roots': [\n"
+"{ 'name': 'b', 'type': 'file',\n"
+"  'external-contents': 'a'\n"
+"}\n"
+"  ]\n"
+"}",
+Lower, "//root/foo/bar/overlay");
+  ASSERT_NE(FSOverlayRelative.get(), nullptr);
+  ErrorOr SOverlayRelative = FS->status("//root/foo/bar/b");
+  ASSERT_FALSE(SOverlayRelative.getError());
+  EXPECT_EQ("//root/foo/bar/a", SOverlayRelative->getName());
+}
+
 TEST_F(VFSFromYAMLTest, ReturnsInternalPathVFSHit) {
   IntrusiveRefCntPtr BaseFS(
   new vfs::InMemoryFileSystem);
Index: llvm/lib/Support/VirtualFileSystem.cpp
===
--- llvm/lib/Support/VirtualFileSystem.cpp
+++ llvm/lib/Support/VirtualFileSystem.cpp
@@ -1482,12 +1482,12 @@
   return Combined;
 }
 
-void RedirectingFileSystem::setExternalContentsPrefixDir(StringRef PrefixDir) {
-  ExternalContentsPrefixDir = PrefixDir.str();
+void RedirectingFileSystem::setOverlayFileDir(StringRef Dir) {
+  OverlayFileDir = Dir.str();
 }
 
-StringRef RedirectingFileSystem::getExternalContentsPrefixDir() const {
-  return ExternalContentsPrefixDir;
+StringRef RedirectingFileSystem::getOverlayFileDir() const {
+  return OverlayFileDir;
 }
 
 void RedirectingFileSystem::setFallthrough(bool Fallthrough) {
@@ -1621,6 +1621,20 @@
 return None;
   }
 
+  Optional
+  parseRootRelativeKind(yaml::Node *N) {
+SmallString<12> Storage;
+StringRef Value;
+if (!parseScalarString(N, Value, Storage))
+  return None;
+if (Value.equals_insensitive("cwd")) {
+  return RedirectingFileSystem::RootRelativeKind::CWD;
+} else if (Value.equals_insensitive("overlay-dir")) {
+  return RedirectingFileSystem::RootRelativeKind::OverlayDir;
+}
+return None;
+  }
+
   struct KeyStatus {
 bool Required;
 bool Seen = false;
@@ -1828,7 

[PATCH] D137473: [vfs] Allow root paths relative to the directory of the vfsoverlay YAML file

2022-11-08 Thread Haowei Wu via Phabricator via cfe-commits
haowei added inline comments.



Comment at: clang/test/VFS/Inputs/root-relative-overlay.yaml:4
+  'case-sensitive': false,
+  'overlay-relative': true,
+  'root-relative': 'yaml-dir',

bnbarham wrote:
> bnbarham wrote:
> > I'd prefer a test without `overlay-relative` set to make it clear they 
> > don't depend on each other.
> There's also unit tests in `llvm/unittests/Support/VirtualFileSystemTest.cpp` 
> that you could add to.
I need some time to patch this unit test for testing the new option.
Existing functions in this unit test file does not support defining the 
YAMLFilePath.

I will update this patch when I finish.



Comment at: clang/test/VFS/Inputs/root-relative-overlay.yaml:4
+  'case-sensitive': false,
+  'overlay-relative': true,
+  'root-relative': 'yaml-dir',

haowei wrote:
> bnbarham wrote:
> > bnbarham wrote:
> > > I'd prefer a test without `overlay-relative` set to make it clear they 
> > > don't depend on each other.
> > There's also unit tests in 
> > `llvm/unittests/Support/VirtualFileSystemTest.cpp` that you could add to.
> I need some time to patch this unit test for testing the new option.
> Existing functions in this unit test file does not support defining the 
> YAMLFilePath.
> 
> I will update this patch when I finish.
I updated the yaml file and add unit tests with overlay-relative set to true 
and false.



Comment at: llvm/include/llvm/Support/VirtualFileSystem.h:660
 ///   'use-external-names': 
+///   'root-relative': 
 ///   'overlay-relative': 

bnbarham wrote:
> phosek wrote:
> > Could we make this just a boolean akin to `overlay-relative` since there 
> > are only two options (default to `false`)?
> I personally prefer being explicit here, `overlay-relative` is fairly 
> confusing as it is.
> 
> `overlay-relative` isn't about allowing relative paths, but instead means 
> that *all* external paths should be prefixed with the directory of the 
> overlay. To put another way, external paths can be relative whether this is 
> true/false, `overlay-relative` just *always* prepends the overlay path.
> 
> Could you add a comment to make it clear that this has no interaction with 
> `overlay-relative`? If you want to add a comment to `overlay-relative` with 
> something like the above that would also be appreciated :)
I also think `overlay-relative` is a bit misleading and it should be an enum 
instead of a boolean option. And it should only work if the external paths are 
relative instead of blindly prepend the overlay dir to every external paths. 
But changing this will be a breaking change so I prefer to avoid it in this 
patch.

I updated the descriptions.



Comment at: llvm/include/llvm/Support/VirtualFileSystem.h:752
+  enum class RootRelativeKind {
+/// The roots are relative to the current working directory.
+CWD,

bnbarham wrote:
> `to the current working directory when the overlay is created.` is maybe a 
> little clearer to me
Added into the comments.



Comment at: llvm/include/llvm/Support/VirtualFileSystem.h:755
+/// The roots are relative to the directory where the YAML file locates.
+YAMLDir
+  };

bnbarham wrote:
> Any thoughts on something like `OverlayDir` instead?
I think OverlayDir is better.



Comment at: llvm/lib/Support/VirtualFileSystem.cpp:1903
+assert(!FullPath.empty() && "YAML file directory must exist");
+sys::fs::make_absolute(FS->getYAMLFileDir(), Name);
+Name = canonicalize(Name);

bnbarham wrote:
> IMO both this and CWD should be using the base FS instead. VFS didn't have a 
> CWD previously, but now that it does it doesn't really make sense to use the 
> process wide CWD. Especially since `-working-directory` doesn't change it.
Could you clarify a bit more about the "base FS" please? I am still quite new 
to the LLVM VFS system.  Which API should I use to get the appropriate working 
directory instead of the the process wide CWD?

I avoided changing the default behavior (relative to the process's current 
working directory) as I am a bit concerned breaking other people's use cases. 

I looked up a bit, the value "--working-directory" will be writen into 
"VFS->setCurrentWorkingDirectory()" Do you think it is a better idea to use 
this value instead of the process current working directory? Though it would 
still be a behavior change for users rely on process current working 
directories. 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137473/new/

https://reviews.llvm.org/D137473

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137473: [vfs] Allow root paths relative to the directory of the vfsoverlay YAML file

2022-11-08 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 474115.
haowei marked 2 inline comments as done.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137473/new/

https://reviews.llvm.org/D137473

Files:
  clang/test/VFS/Inputs/root-relative-overlay.yaml
  clang/test/VFS/relative-path.c
  llvm/include/llvm/Support/VirtualFileSystem.h
  llvm/lib/Support/VirtualFileSystem.cpp

Index: llvm/lib/Support/VirtualFileSystem.cpp
===
--- llvm/lib/Support/VirtualFileSystem.cpp
+++ llvm/lib/Support/VirtualFileSystem.cpp
@@ -1482,12 +1482,12 @@
   return Combined;
 }
 
-void RedirectingFileSystem::setExternalContentsPrefixDir(StringRef PrefixDir) {
-  ExternalContentsPrefixDir = PrefixDir.str();
+void RedirectingFileSystem::setOverlayFileDir(StringRef Dir) {
+  OverlayFileDir = Dir.str();
 }
 
-StringRef RedirectingFileSystem::getExternalContentsPrefixDir() const {
-  return ExternalContentsPrefixDir;
+StringRef RedirectingFileSystem::getOverlayFileDir() const {
+  return OverlayFileDir;
 }
 
 void RedirectingFileSystem::setFallthrough(bool Fallthrough) {
@@ -1621,6 +1621,20 @@
 return None;
   }
 
+  Optional
+  parseRootRelativeKind(yaml::Node *N) {
+SmallString<12> Storage;
+StringRef Value;
+if (!parseScalarString(N, Value, Storage))
+  return None;
+if (Value.equals_insensitive("cwd")) {
+  return RedirectingFileSystem::RootRelativeKind::CWD;
+} else if (Value.equals_insensitive("overlay-dir")) {
+  return RedirectingFileSystem::RootRelativeKind::OverlayDir;
+}
+return None;
+  }
+
   struct KeyStatus {
 bool Required;
 bool Seen = false;
@@ -1828,7 +1842,7 @@
 
 SmallString<256> FullPath;
 if (FS->IsRelativeOverlay) {
-  FullPath = FS->getExternalContentsPrefixDir();
+  FullPath = FS->getOverlayFileDir();
   assert(!FullPath.empty() &&
  "External contents prefix directory must exist");
   llvm::sys::path::append(FullPath, Value);
@@ -1884,6 +1898,15 @@
   } else if (sys::path::is_absolute(Name,
 sys::path::Style::windows_backslash)) {
 path_style = sys::path::Style::windows_backslash;
+  } else if (FS->RootRelative ==
+ RedirectingFileSystem::RootRelativeKind::OverlayDir) {
+SmallString<256> FullPath = FS->getOverlayFileDir();
+assert(!FullPath.empty() && "Overlay file directory must exist");
+sys::fs::make_absolute(FS->getOverlayFileDir(), Name);
+Name = canonicalize(Name);
+path_style = sys::path::is_absolute(Name, sys::path::Style::posix)
+ ? sys::path::Style::posix
+ : sys::path::Style::windows_backslash;
   } else {
 // Relative VFS root entries are made absolute to the current working
 // directory, then we can determine the path style from that.
@@ -1962,6 +1985,7 @@
 KeyStatusPair("version", true),
 KeyStatusPair("case-sensitive", false),
 KeyStatusPair("use-external-names", false),
+KeyStatusPair("root-relative", false),
 KeyStatusPair("overlay-relative", false),
 KeyStatusPair("fallthrough", false),
 KeyStatusPair("redirecting-with", false),
@@ -2051,6 +2075,13 @@
   error(I.getValue(), "expected valid redirect kind");
   return false;
 }
+  } else if (Key == "root-relative") {
+if (auto Kind = parseRootRelativeKind(I.getValue())) {
+  FS->RootRelative = *Kind;
+} else {
+  error(I.getValue(), "expected valid root-relative kind");
+  return false;
+}
   } else {
 llvm_unreachable("key missing from Keys");
   }
@@ -2100,13 +2131,13 @@
 // Example:
 //-ivfsoverlay dummy.cache/vfs/vfs.yaml
 // yields:
-//  FS->ExternalContentsPrefixDir => //dummy.cache/vfs
+//  FS->YAMLFileDir => //dummy.cache/vfs
 //
 SmallString<256> OverlayAbsDir = sys::path::parent_path(YAMLFilePath);
 std::error_code EC = llvm::sys::fs::make_absolute(OverlayAbsDir);
 assert(!EC && "Overlay dir final path must be absolute");
 (void)EC;
-FS->setExternalContentsPrefixDir(OverlayAbsDir);
+FS->setOverlayFileDir(OverlayAbsDir);
   }
 
   if (!P.parse(Root, FS.get()))
Index: llvm/include/llvm/Support/VirtualFileSystem.h
===
--- llvm/include/llvm/Support/VirtualFileSystem.h
+++ llvm/include/llvm/Support/VirtualFileSystem.h
@@ -651,17 +651,28 @@
 /// \endverbatim
 ///
 /// The roots may be absolute or relative. If relative they will be made
-/// absolute against the current working directory.
+/// absolute against either current working directory or the directory where
+/// the Overlay YAML file is located, depending on the 'root-relative'
+/// configuration.
 ///
 /// All configuration options are 

[PATCH] D137473: [vfs] Allow root paths relative to the directory of the vfsoverlay YAML file

2022-11-07 Thread Haowei Wu via Phabricator via cfe-commits
haowei added reviewers: bnbarham, keith.
haowei added a comment.

Please take a look.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137473/new/

https://reviews.llvm.org/D137473

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137473: [vfs] Allow root paths relative to the directory of the vfsoverlay YAML file

2022-11-04 Thread Haowei Wu via Phabricator via cfe-commits
haowei created this revision.
haowei added reviewers: phosek, abrachet.
Herald added a subscriber: hiraditya.
Herald added a project: All.
haowei requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

VFS overlay file allow using relative paths in root->name paths (root directory 
of the virtual file) and external-contents (the actual files). While the 
'external-contents' could be configured to relative to directory of the YAML 
file (change https://reviews.llvm.org/D17457), before this change, the root 
paths could only be relative to the current working directory.

This patch add the "root-relative" to the YAML file format. When this option is 
set to "yaml-dir" the root->name will be prepend by the YAML file directory. 
This option is helpful when compiling on case sensitive file systems when cross 
compiling to Windows as we can create a vfsoverlay YAML file for the Windows 
libraries without using absolute paths. Related change: 
https://reviews.llvm.org/D125800


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D137473

Files:
  clang/test/VFS/Inputs/root-relative-overlay.yaml
  clang/test/VFS/relative-path.c
  llvm/include/llvm/Support/VirtualFileSystem.h
  llvm/lib/Support/VirtualFileSystem.cpp

Index: llvm/lib/Support/VirtualFileSystem.cpp
===
--- llvm/lib/Support/VirtualFileSystem.cpp
+++ llvm/lib/Support/VirtualFileSystem.cpp
@@ -1482,13 +1482,11 @@
   return Combined;
 }
 
-void RedirectingFileSystem::setExternalContentsPrefixDir(StringRef PrefixDir) {
-  ExternalContentsPrefixDir = PrefixDir.str();
+void RedirectingFileSystem::setYAMLFileDir(StringRef Dir) {
+  YAMLFileDir = Dir.str();
 }
 
-StringRef RedirectingFileSystem::getExternalContentsPrefixDir() const {
-  return ExternalContentsPrefixDir;
-}
+StringRef RedirectingFileSystem::getYAMLFileDir() const { return YAMLFileDir; }
 
 void RedirectingFileSystem::setFallthrough(bool Fallthrough) {
   if (Fallthrough) {
@@ -1621,6 +1619,20 @@
 return None;
   }
 
+  Optional
+  parseRootRelativeKind(yaml::Node *N) {
+SmallString<9> Storage;
+StringRef Value;
+if (!parseScalarString(N, Value, Storage))
+  return None;
+if (Value.equals_insensitive("cwd")) {
+  return RedirectingFileSystem::RootRelativeKind::CWD;
+} else if (Value.equals_insensitive("yaml-dir")) {
+  return RedirectingFileSystem::RootRelativeKind::YAMLDir;
+}
+return None;
+  }
+
   struct KeyStatus {
 bool Required;
 bool Seen = false;
@@ -1828,7 +1840,7 @@
 
 SmallString<256> FullPath;
 if (FS->IsRelativeOverlay) {
-  FullPath = FS->getExternalContentsPrefixDir();
+  FullPath = FS->getYAMLFileDir();
   assert(!FullPath.empty() &&
  "External contents prefix directory must exist");
   llvm::sys::path::append(FullPath, Value);
@@ -1884,6 +1896,15 @@
   } else if (sys::path::is_absolute(Name,
 sys::path::Style::windows_backslash)) {
 path_style = sys::path::Style::windows_backslash;
+  } else if (FS->RootRelative ==
+ RedirectingFileSystem::RootRelativeKind::YAMLDir) {
+SmallString<256> FullPath = FS->getYAMLFileDir();
+assert(!FullPath.empty() && "YAML file directory must exist");
+sys::fs::make_absolute(FS->getYAMLFileDir(), Name);
+Name = canonicalize(Name);
+path_style = sys::path::is_absolute(Name, sys::path::Style::posix)
+ ? sys::path::Style::posix
+ : sys::path::Style::windows_backslash;
   } else {
 // Relative VFS root entries are made absolute to the current working
 // directory, then we can determine the path style from that.
@@ -1962,6 +1983,7 @@
 KeyStatusPair("version", true),
 KeyStatusPair("case-sensitive", false),
 KeyStatusPair("use-external-names", false),
+KeyStatusPair("root-relative", false),
 KeyStatusPair("overlay-relative", false),
 KeyStatusPair("fallthrough", false),
 KeyStatusPair("redirecting-with", false),
@@ -2051,6 +2073,13 @@
   error(I.getValue(), "expected valid redirect kind");
   return false;
 }
+  } else if (Key == "root-relative") {
+if (auto Kind = parseRootRelativeKind(I.getValue())) {
+  FS->RootRelative = *Kind;
+} else {
+  error(I.getValue(), "expected valid root-relative kind");
+  return false;
+}
   } else {
 llvm_unreachable("key missing from Keys");
   }
@@ -2100,13 +2129,13 @@
 // Example:
 //-ivfsoverlay dummy.cache/vfs/vfs.yaml
 // yields:
-//  FS->ExternalContentsPrefixDir => //dummy.cache/vfs
+//  FS->YAMLFileDir => //dummy.cache/vfs
 //
 SmallString<256> OverlayAbsDir = sys::path::parent_path(YAMLFilePath);
   

[PATCH] D134371: [clang-doc] Add typedef/using information.

2022-09-27 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

In D134371#3819605 , @nemanjai wrote:

> This causes failures with `-Werror` such as: 
> https://lab.llvm.org/buildbot/#/builders/57/builds/22322
> Please fix or revert.

Thanks for reporting this. I reverted this change.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134371/new/

https://reviews.llvm.org/D134371

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D134235: [clang-doc] Clean up *Info constructors.

2022-09-26 Thread Haowei Wu via Phabricator via cfe-commits
haowei accepted this revision.
haowei added a comment.
This revision is now accepted and ready to land.

LGTM
@paulkirth Do you have more comments?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134235/new/

https://reviews.llvm.org/D134235

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D134235: [clang-doc] Clean up *Info constructors.

2022-09-26 Thread Haowei Wu via Phabricator via cfe-commits
haowei added inline comments.



Comment at: clang-tools-extra/clang-doc/BitcodeReader.cpp:336
 Reference *I, FieldId ) {
   switch (ID) {
   case REFERENCE_USR:

This block ID came from L582, which read from a bitcode file when 
`BI_REFERENCE_BLOCK_ID` is encountered. I am not familiar with the content of 
an arbitrary bitcode file. But after your patch, if this block ID is 
encountered, it will result in an error (a behavior change).

It looks like `REFERENCE_IS_IN_GLOBAL_NAMESPACE` is only defined in in 
clang-doc and not part of LLVM's bitcode header. So it looks like it is not a 
standardized ID to me. Could you confirm it?

If `REFERENCE_IS_IN_GLOBAL_NAMESPACE` only presents in bitcode file generated 
from BitcodeWriter from clang-doc and we are not expecting to provide 
compatibility to an arbitrary bitcode generated from elsewhere, I am OK with 
deleting this field (I still don't think this is the right approach to do but I 
don't have a strong opinion on this either). 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134235/new/

https://reviews.llvm.org/D134235

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D134235: [clang-doc] Clean up *Info constructors.

2022-09-26 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

@brettw Thanks for the clarification. I was oncall for buildgardener last week 
and got quite busy due to breakages.

Thanks for your clarification, that is really helpful to understand the your 
intent. While I still don't see the way these constructors are implemented is 
an issue. I don't have a strong opinions on this and OK with your refactors.

"semantically equivalent" means these test code should have same input/output, 
performance same routines of task and use same amount of memory. Before your 
change, these typeinfo's symbolID in the test are always pointing to a constant 
EmptySID, after your change, some of these typeinfo points to an empty symbol 
ID in allocated in memory when typeinfo is created. While the output is the 
same, they are not equivalent. For refactor changes, I would prefer to avoid 
introducing such changes.

I have one question about deleting the IsInGlobalNamespace. I understand it is 
not well implemented and has a bug in its constructor, but I don't think we 
should simply delete it just because it is buggy and not well used. It is part 
of C++ and commonly used. Do you have any plan to add it back after all the 
refactor work finishes?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134235/new/

https://reviews.llvm.org/D134235

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D134235: [clang-doc] Clean up *Info constructors.

2022-09-20 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

I am a bit puzzled by the intent of cleaning up the constructors in Info 
object. I didn't see it as an issue to have multiple constructors, which is a 
common practice. After this clean up It doesn't make it easier to use these 
objects, in fact, in `Serialize.cpp`, you have to explicitly specify a new 
SymbolID() when creating a new Reference object. While this change won't affect 
(except for the global namespace) the output from clang-docs, it is not 
semantically equivalent before the cleanup.

Would you mind explaining the reasons for removing these constructors?




Comment at: clang-tools-extra/clang-doc/Representation.h:165
-  : Type(Type, Field, IT) {}
-  TypeInfo(SymbolID Type, StringRef Field, InfoType IT, StringRef Path)
-  : Type(Type, Field, IT, Path) {}

The clean up here prevents setting a customized SymbolID for TypeInfo, which 
becomes a problem in the HTMLGeneratorTest, in which TypeInfo is constructed 
with an constant EmptySID. While the outcome is the same, it is not 
semantically equivalent.  



Comment at: clang-tools-extra/clang-doc/Representation.h:219
 
-  int LineNumber;   // Line number of this Location.
+  int LineNumber = 0;   // Line number of this Location.
   SmallString<32> Filename; // File for this Location.

This is already set in the constructor. Does it still need to be set explicitly 
here? 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134235/new/

https://reviews.llvm.org/D134235

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D131714: [compiler-rt][builtins] Add compiler flags to catch potential errors that can lead to security vulnerabilities

2022-08-25 Thread Haowei Wu via Phabricator via cfe-commits
haowei added subscribers: mcgrathr, phosek, gulfem.
haowei added a comment.

After looking into the code, I think I should point out that 
`compiler-rt/include/profile/InstrProfData.inc` is a published header and its 
API details cannot be changed trivially without coordination with external 
users, so seemingly cosmetic changes should be avoided if they might require 
changes for users of the header, which includes changing any of the 
identifiers. In our case, Fuchsia uses the API in this file and due to this 
change, we are seeing build breakages.

At this point. I recommend to revert all related changes to this code review 
instead of trying to attempt to fix the problem multiple times without success.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131714/new/

https://reviews.llvm.org/D131714

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D131714: [compiler-rt][builtins] Add compiler flags to catch potential errors that can lead to security vulnerabilities

2022-08-25 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

We are also saw failures on Fuchsia builders when using ToT clang:

  [31281/267743] CXX 
host_x64/obj/src/lib/llvm-profdata/llvm-profdata-for-test.llvm-profdata.cc.o
  FAILED: 
host_x64/obj/src/lib/llvm-profdata/llvm-profdata-for-test.llvm-profdata.cc.o
  ../../../recipe_cleanup/clang2x5u_bg_/bin/clang++ -MD -MF 
host_x64/obj/src/lib/llvm-profdata/llvm-profdata-for-test.llvm-profdata.cc.o.d 
-DHAVE_PROFDATA=1 -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -...
  In file included from ../../src/lib/llvm-profdata/llvm-profdata.cc:224:
  
../../../recipe_cleanup/clang2x5u_bg_/lib/clang/16.0.0/include/profile/InstrProfData.inc:132:43:
 error: use of undeclared identifier 'DataSizeInitVal'
  INSTR_PROF_RAW_HEADER(uint64_t, DataSize, DataSizeInitVal)
^
  
../../../recipe_cleanup/clang2x5u_bg_/lib/clang/16.0.0/include/profile/InstrProfData.inc:135:47:
 error: use of undeclared identifier 'CountersSizeInitVal'
  INSTR_PROF_RAW_HEADER(uint64_t, CountersSize, CountersSizeInitVal)
^
  2 errors generated.
  clang++: error: failing because '-gen-reproducer' is used
  Fuchsia clang version 16.0.0 (https://llvm.googlesource.com/llvm-project 
0473ac8876b94fc27f145c48106675b9dedcb20d)
  Target: x86_64-unknown-linux-gnu
  Thread model: posix
  InstalledDir: ../../../recipe_cleanup/clang2x5u_bg_/bin
  clang++: note: diagnostic msg:
  
  
  PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
  Preprocessed source(s) and associated run script(s) are located at:
  clang++: note: diagnostic msg: clang-crashreports/llvm-profdata-424b79.cpp
  clang++: note: diagnostic msg: clang-crashreports/llvm-profdata-424b79.sh
  clang++: note: diagnostic msg:
  
  

Failing task: 
https://ci.chromium.org/ui/p/fuchsia/builders/ci/clang_toolchain.ci.core.x64-debug-tot-build_only/b8804902579506128897/overview

Could you revert your change if it takes a while to fix forward?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131714/new/

https://reviews.llvm.org/D131714

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D128619: [Clang] Implement P0848 (Conditionally Trivial Special Member Functions)

2022-08-24 Thread Haowei Wu via Phabricator via cfe-commits
haowei added subscribers: haowei, phosek, mcgrathr.
haowei added a comment.

Hi,

We are seeing build failures on Fuchsia build bots after this change was 
landed. and we suspect this patch causes clang to miscompile certain code. I 
filed bug https://github.com/llvm/llvm-project/issues/57351 and included a 
reproducer. Could you take a look? If it is confirmed to be a bug and take long 
time to fix, could you revert this change please?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128619/new/

https://reviews.llvm.org/D128619

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D126192: [Driver] Improve linking options for target AVR

2022-06-14 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

I tested this patch on our windows builder and it passed as well. 
This patch LGTM. (I cannot click accept as the this review is already closed)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126192/new/

https://reviews.llvm.org/D126192

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D126192: [Driver] Improve linking options for target AVR

2022-06-14 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

In D126192#3583915 , @benshi001 wrote:

> It seems the file 
> `/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/Inputs/basic_avr_tree/usr/bin/ld.lld`
>  is missing on your machine, which I have newly created in current patch.

That file was missing. For some reason, it was missing from the patch I 
downloaded from phabricator( if you look at 
https://reviews.llvm.org/file/data/2wqpf52swpb3xkcz7lip/PHID-FILE-filks6eto62wxww6m23w/D126192.vson.id436992.diff).

After manually create clang/test/Driver/Inputs/basic_avr_tree/usr/bin/ld.lld 
and set permission to 0755 (test will fail if I don't do it). All tests will 
pass under linux-x64. I will need to test it on a Windows host to make sure it 
all pass, which will take a while.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126192/new/

https://reviews.llvm.org/D126192

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D126192: [Driver] Improve linking options for target AVR

2022-06-14 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

Emmm, I applied your latest patch on top of 
main(6e02e27536b9de25a651cfc9c2966ce471169355 
) but I 
still get a test failure on `Clang :: Driver/avr-toolchain.c`.

`Clang :: Driver/avr-ld.c` no longer fail.
Error message:

  FAIL: Clang :: Driver/avr-toolchain.c (7349 of 16540)
   TEST 'Clang :: Driver/avr-toolchain.c' FAILED 

  Script:
  --
  : 'RUN: at line 4';   
/mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/clang -### 
/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/avr-toolchain.c --target=avr 
--sysroot=/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/Inputs/basic_avr_tree
  
-resource-dir=/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/Inputs/resource_dir
 2>&1 | /mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/FileCheck 
--check-prefix=CHECK1 
/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 15';   
/mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/clang -### 
/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/avr-toolchain.c --target=avr 
--sysroot=/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/Inputs/basic_avr_tree
  _2/opt/local -S 2>&1 | 
/mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/FileCheck 
--check-prefix=CHECK2 
/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 21';   
/mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/clang -### 
/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/avr-toolchain.c --target=avr 
--sysroot=/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/Inputs/basic_avr_tree
  _2 -S 2>&1 | /mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/FileCheck 
--check-prefix=CHECK3 
/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 27';   
/mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/clang -### 
/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/avr-toolchain.c --target=avr 
2>&1 | /mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/FileCheck -check-pre
  fix=CC1 /mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 30';   
/mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/clang -### 
/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/avr-toolchain.c --target=avr 
-fuse-init-array -fuse-cxa-atexit 2>&1 | /mnt/nvme_sec/SRC/llvm-project/build-re
  vert-test/bin/FileCheck -check-prefix=CHECK4 
/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 35';   
/mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/clang -### 
/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/avr-toolchain.c --target=avr 
--sysroot=/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/Inputs/basic_avr_tree
   2>&1 -nostdinc | 
/mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/FileCheck 
--check-prefix=NOSTDINC 
/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 36';   
/mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/clang -### 
/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/avr-toolchain.c --target=avr 
--sysroot=/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/Inputs/basic_avr_tree
   2>&1 -nostdlibinc | 
/mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/FileCheck 
--check-prefix=NOSTDINC 
/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 39';   
/mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/clang -### --target=avr 
--sysroot=/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/Inputs/basic_avr_tree
 -mmcu=atmega328 /mnt/nvme_sec/SRC/llvm-project/clang/test/Driver
  /avr-toolchain.c 2>&1 | 
/mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/FileCheck 
--check-prefix=NOWARN 
/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 40';   
/mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/clang -### --target=avr 
--sysroot=/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/Inputs/basic_avr_tree
 -mmcu=atmega328 -S /mnt/nvme_sec/SRC/llvm-project/clang/test/Dri
  ver/avr-toolchain.c 2>&1 | 
/mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/FileCheck 
--check-prefix=NOWARN 
/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 41';   
/mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/clang -### --target=avr 
--sysroot=/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/Inputs/ 
-mmcu=atmega328 -S /mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/avr-toolch
  ain.c 2>&1 | /mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/FileCheck 
--check-prefix=NOWARN 
/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 44';   
/mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/clang -### --target=avr 
--sysroot=/mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/Inputs/basic_avr_tree
 -S /mnt/nvme_sec/SRC/llvm-project/clang/test/Driver/avr-toolchai
  n.c 2>&1 | /mnt/nvme_sec/SRC/llvm-project/build-revert-test/bin/FileCheck 

[PATCH] D127814: [Driver] Force avr-ld to be default linker for target AVR

2022-06-14 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

I tested this patch on top of 
https://github.com/llvm/llvm-project/commit/3b6e166999bb83197c8b70468c2d371c58cf0c25
 (reverted in 
https://github.com/llvm/llvm-project/commit/7fae15f9251d3b392058e2fc84898b53619d36ad)
 and Clang driver tests now pass without issue.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127814/new/

https://reviews.llvm.org/D127814

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D126192: [Driver] Improve linking options for target AVR

2022-06-14 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

I already reverted the change in 
https://github.com/llvm/llvm-project/commit/7fae15f9251d3b392058e2fc84898b53619d36ad
 . It is likely the breakage is caused by the fact that Fuchsia's Clang by 
default use `lld`, see 
`clang/cmake/caches/Fuchsia-stage2.cmake:set(CLANG_DEFAULT_LINKER lld CACHE 
STRING "")` . Please let me know if you need to test your new patch with this 
configuration. I am happy to help.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126192/new/

https://reviews.llvm.org/D126192

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D126192: [Driver] Improve linking options for target AVR

2022-06-14 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

We are seeing Clang driver test failures after this patch. On Fuchsia's mac 
clang builder,  `Clang :: Driver/avr-ld.c` and `Clang :: 
Driver/avr-toolchain.c` are failing. 
Failed build task: 
https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-mac-x64/b8811424628472375921/overview
 Error message:

Clang :: Driver/avr-toolchain.c;

  Script:
  --
  : 'RUN: at line 4';   /opt/s/w/ir/x/w/staging/llvm_build/bin/clang -### 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c 
--target=avr 
--sysroot=/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/Inputs/basic_avr_tree
 
-resource-dir=/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/Inputs/resource_dir
 2>&1 | /opt/s/w/ir/x/w/staging/llvm_build/bin/FileCheck --check-prefix=CHECK1 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 15';   /opt/s/w/ir/x/w/staging/llvm_build/bin/clang -### 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c 
--target=avr 
--sysroot=/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/Inputs/basic_avr_tree_2/opt/local
 -S 2>&1 | /opt/s/w/ir/x/w/staging/llvm_build/bin/FileCheck 
--check-prefix=CHECK2 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 21';   /opt/s/w/ir/x/w/staging/llvm_build/bin/clang -### 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c 
--target=avr 
--sysroot=/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/Inputs/basic_avr_tree_2
 -S 2>&1 | /opt/s/w/ir/x/w/staging/llvm_build/bin/FileCheck 
--check-prefix=CHECK3 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 27';   /opt/s/w/ir/x/w/staging/llvm_build/bin/clang -### 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c 
--target=avr 2>&1 | /opt/s/w/ir/x/w/staging/llvm_build/bin/FileCheck 
-check-prefix=CC1 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 30';   /opt/s/w/ir/x/w/staging/llvm_build/bin/clang -### 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c 
--target=avr -fuse-init-array -fuse-cxa-atexit 2>&1 | 
/opt/s/w/ir/x/w/staging/llvm_build/bin/FileCheck -check-prefix=CHECK4 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 35';   /opt/s/w/ir/x/w/staging/llvm_build/bin/clang -### 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c 
--target=avr 
--sysroot=/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/Inputs/basic_avr_tree
 2>&1 -nostdinc | /opt/s/w/ir/x/w/staging/llvm_build/bin/FileCheck 
--check-prefix=NOSTDINC 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 36';   /opt/s/w/ir/x/w/staging/llvm_build/bin/clang -### 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c 
--target=avr 
--sysroot=/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/Inputs/basic_avr_tree
 2>&1 -nostdlibinc | /opt/s/w/ir/x/w/staging/llvm_build/bin/FileCheck 
--check-prefix=NOSTDINC 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 39';   /opt/s/w/ir/x/w/staging/llvm_build/bin/clang -### 
--target=avr 
--sysroot=/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/Inputs/basic_avr_tree
 -mmcu=atmega328 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c 2>&1 | 
/opt/s/w/ir/x/w/staging/llvm_build/bin/FileCheck --check-prefix=NOWARN 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 40';   /opt/s/w/ir/x/w/staging/llvm_build/bin/clang -### 
--target=avr 
--sysroot=/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/Inputs/basic_avr_tree
 -mmcu=atmega328 -S 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c 2>&1 | 
/opt/s/w/ir/x/w/staging/llvm_build/bin/FileCheck --check-prefix=NOWARN 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 41';   /opt/s/w/ir/x/w/staging/llvm_build/bin/clang -### 
--target=avr 
--sysroot=/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/Inputs/ 
-mmcu=atmega328 -S 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c 2>&1 | 
/opt/s/w/ir/x/w/staging/llvm_build/bin/FileCheck --check-prefix=NOWARN 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 44';   /opt/s/w/ir/x/w/staging/llvm_build/bin/clang -### 
--target=avr 
--sysroot=/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/Inputs/basic_avr_tree
 -S /opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c 2>&1 | 
/opt/s/w/ir/x/w/staging/llvm_build/bin/FileCheck --check-prefixes=NOMCU,LINKA 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c
  : 'RUN: at line 45';   /opt/s/w/ir/x/w/staging/llvm_build/bin/clang -### 
--target=avr 
--sysroot=/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/Inputs/ -S 
/opt/s/w/ir/x/w/llvm-llvm-project/clang/test/Driver/avr-toolchain.c 2>&1 | 

[PATCH] D119479: [clang][extract-api] Add global record support

2022-03-16 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

In D119479#3387880 , @zixuw wrote:

> @haowei I got a quick fix of completely purging the generator output in the 
> test case. Could you take a look to have a sanity check before I land the fix 
> on main?
>
>   diff --git a/clang/test/SymbolGraph/global_record.c 
> b/clang/test/SymbolGraph/global_record.c
>   index ba4bf967e630..1e0294cda153 100644
>   --- a/clang/test/SymbolGraph/global_record.c
>   +++ b/clang/test/SymbolGraph/global_record.c
>   @@ -4,7 +4,9 @@
>// RUN: %t/reference.output.json
>// RUN: %clang -extract-api -target arm64-apple-macosx \
>// RUN: %t/input.c -o %t/output.json | FileCheck -allow-empty %s
>   -// RUN: sed -e "s@\"generator\": \"clang.*\"@\"generator\": \"clang\"@g" \
>   +
>   +// Generator version is not consisten across test runs, normalize it.
>   +// RUN: sed -e "s@\"generator\": \".*\"@\"generator\": \"?\"@g" \
>// RUN: %t/output.json >> %t/output-normalized.json
>// RUN: diff %t/reference.output.json %t/output-normalized.json
>
>   @@ -32,7 +34,7 @@ char unavailable __attribute__((unavailable));
>  "minor": 5,
>  "patch": 3
>},
>   -"generator": "clang"
>   +"generator": "?"
>  },
>  "module": {
>"name": "",

It passed the test locally on my machine.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119479/new/

https://reviews.llvm.org/D119479

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D119479: [clang][extract-api] Add global record support

2022-03-16 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

We are seeing test failures after this patch is landed:

  Clang :: SymbolGraph/global_record.c
  Script:
  --
  : 'RUN: at line 1';   rm -rf 
/b/s/w/ir/x/w/staging/llvm_build/tools/clang/test/SymbolGraph/Output/global_record.c.tmp
  : 'RUN: at line 2';   split-file 
/b/s/w/ir/x/w/llvm-llvm-project/clang/test/SymbolGraph/global_record.c 
/b/s/w/ir/x/w/staging/llvm_build/tools/clang/test/SymbolGraph/Output/global_record.c.tmp
  : 'RUN: at line 3';   sed -e 
"s@INPUT_DIR@/b/s/w/ir/x/w/staging/llvm_build/tools/clang/test/SymbolGraph/Output/global_record.c.tmp@g"
 
/b/s/w/ir/x/w/staging/llvm_build/tools/clang/test/SymbolGraph/Output/global_record.c.tmp/reference.output.json.in
 >>  
/b/s/w/ir/x/w/staging/llvm_build/tools/clang/test/SymbolGraph/Output/global_record.c.tmp/reference.output.json
  : 'RUN: at line 5';   /b/s/w/ir/x/w/staging/llvm_build/bin/clang -extract-api 
-target arm64-apple-macosx  
/b/s/w/ir/x/w/staging/llvm_build/tools/clang/test/SymbolGraph/Output/global_record.c.tmp/input.c
 -o 
/b/s/w/ir/x/w/staging/llvm_build/tools/clang/test/SymbolGraph/Output/global_record.c.tmp/output.json
 | /b/s/w/ir/x/w/staging/llvm_build/bin/FileCheck -allow-empty 
/b/s/w/ir/x/w/llvm-llvm-project/clang/test/SymbolGraph/global_record.c
  : 'RUN: at line 7';   sed -e "s@\"generator\": \"clang.*\"@\"generator\": 
\"clang\"@g"  
/b/s/w/ir/x/w/staging/llvm_build/tools/clang/test/SymbolGraph/Output/global_record.c.tmp/output.json
 >> 
/b/s/w/ir/x/w/staging/llvm_build/tools/clang/test/SymbolGraph/Output/global_record.c.tmp/output-normalized.json
  : 'RUN: at line 9';   diff 
/b/s/w/ir/x/w/staging/llvm_build/tools/clang/test/SymbolGraph/Output/global_record.c.tmp/reference.output.json
 
/b/s/w/ir/x/w/staging/llvm_build/tools/clang/test/SymbolGraph/Output/global_record.c.tmp/output-normalized.json
  --
  Exit Code: 1
  
  Command Output (stdout):
  --
  8c8
  < "generator": "clang"
  ---
  > "generator": "Fuchsia clang version 15.0.0 
(https://llvm.googlesource.com/a/llvm-project 
a597d6a780b184539f504392168b004bf392a135)"
  
  --

Failed builder task: 
https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8819495289632137105/overview
 . Detailed test outputs: 
https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8819495289632137105/test-results

Could you fix the test please? If it takes a long time to fix, could you revert 
the change first please?
I think you probably shouldn't simply use diff at L9 in 
clang/test/SymbolGraph/global_record.c.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119479/new/

https://reviews.llvm.org/D119479

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D113620: Skip exception cleanups when the innermost scope is EHTerminateScope.

2022-02-04 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

Hi,  we are seeing clang Windows build breakages after this change was relanded 
error message:

  Assertion failed: isa(Val) && "cast() argument of incompatible type!", 
file C:\b\s\w\ir\x\w\llvm-llvm-project\llvm\include\llvm/Support/Casting.h, 
line 262
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ 
and include the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.Program arguments: 
C:\\b\\s\\w\\ir\\x\\w\\staging\\llvm_build\\.\\bin\\clang-cl.exe /nologo -TP 
-DNDEBUG -DUNICODE -D_ALLOW_ITERATOR_DEBUG_LEVEL_MISMATCH 
-D_ALLOW_MSC_VER_MISMATCH -D_CRTBLD -D_CRT_NONSTDC_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS 
-D_CRT_STDIO_ISO_WIDE_SPECIFIERS -D_LIBCPP_BUILDING_LIBRARY 
-D_LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER 
-D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-IC:\\b\\s\\w\\ir\\x\\w\\llvm-llvm-project\\libcxx\\src /DWIN32 /D_WINDOWS 
/Zc:inline /Zc:__cplusplus /Zc:strictStrings /Oi /Zc:rvalueCast /bigobj /W4 
-wd4141 -wd4146 -wd4244 -wd4267 -wd4291 -wd4351 -wd4456 -wd4457 -wd4458 -wd4459 
-wd4503 -wd4624 -wd4722 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510 -wd4702 
-wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 -wd4204 -wd4577 
-wd4091 -wd4592 -wd4319 -wd4709 -wd4324 -w14062 -we4238 /Gw 
-no-canonical-prefixes --target=x86_64-pc-windows-msvc /MD /Zi /O2 /Ob1 
--target=x86_64-pc-windows-msvc -UNDEBUG -W4 -Wextra -W -Wwrite-strings 
-Wno-unused-parameter -Wno-long-long -Werror=return-type -Wextra-semi -Wundef 
-Wformat-nonliteral -Wno-user-defined-literals -Wno-covered-switch-default 
-Wno-suggest-override -Wno-c++98-compat -Wno-c++98-compat-pedantic 
-Wno-c++11-compat -Wno-undef -Wno-reserved-id-macro -Wno-gnu-include-next 
-Wno-gcc-compat -Wno-zero-as-null-pointer-constant 
-Wno-deprecated-dynamic-exception-spec -Wno-sign-conversion -Wno-old-style-cast 
-Wno-deprecated -Wno-shift-sign-overflow -Wno-double-promotion -Wno-error -EHsc 
/IC:/b/s/w/ir/x/w/staging/llvm_build/include/c++/v1 
/IC:/b/s/w/ir/x/w/staging/llvm_build/include/x86_64-pc-windows-msvc/c++/v1 
-std:c++latest /showIncludes 
/Folibcxx\\src\\CMakeFiles\\cxx_static.dir\\future.cpp.obj 
/Fdlibcxx\\src\\CMakeFiles\\cxx_static.dir\\cxx_static.pdb -c 
C:\\b\\s\\w\\ir\\x\\w\\llvm-llvm-project\\libcxx\\src\\future.cpp
  1. parser at end of file
  2.C:\b\s\w\ir\x\w\llvm-llvm-project\libcxx\src\future.cpp:16:1 
: 
LLVM IR generation of declaration 'std'
  3.C:\b\s\w\ir\x\w\llvm-llvm-project\libcxx\src\future.cpp:204:16: 
Generating code for declaration 'std::promise::~promise'
  4.C:\b\s\w\ir\x\w\llvm-llvm-project\libcxx\src\future.cpp:205:1: LLVM IR 
generation of compound statement ('{}')
  5.C:\b\s\w\ir\x\w\llvm-llvm-project\libcxx\src\future.cpp:207:5: LLVM IR 
generation of compound statement ('{}')

We confirmed it by local bisecting. Full build log: 
https://logs.chromium.org/logs/fuchsia/buildbucket/cr-buildbucket/8823297314867545825/+/u/clang/build/stdout
Could you take a look? If it takes time to fix, could you revert the change 
please. Thanks.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113620/new/

https://reviews.llvm.org/D113620

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D112271: [clang][Fuchsia] Add additional unit test for availability attr

2021-10-25 Thread Haowei Wu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG07bed3ae52b0: [clang][Fuchsia] Add additional unit test for 
availability attr (authored by haowei).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112271/new/

https://reviews.llvm.org/D112271

Files:
  clang/test/Sema/attr-availability-fuchsia.c


Index: clang/test/Sema/attr-availability-fuchsia.c
===
--- clang/test/Sema/attr-availability-fuchsia.c
+++ clang/test/Sema/attr-availability-fuchsia.c
@@ -11,17 +11,19 @@
 void f0(int) __attribute__((availability(fuchsia, introduced = 14, deprecated 
= 19)));
 void f1(int) __attribute__((availability(fuchsia, introduced = 16)));
 void f2(int) __attribute__((availability(fuchsia, introduced = 14, deprecated 
= 16))); // expected-note {{'f2' has been explicitly marked deprecated here}}
-void f3(int) __attribute__((availability(fuchsia, introduced = 19)));
+void f3(int) __attribute__((availability(fuchsia, introduced = 19, strict))); 
// expected-note {{'f3' has been explicitly marked unavailable here}}
 void f4(int) __attribute__((availability(fuchsia, introduced = 9, deprecated = 
11, obsoleted = 16), availability(ios, introduced = 2.0, deprecated = 3.0))); 
// expected-note{{explicitly marked unavailable}}
 void f5(int) __attribute__((availability(ios, introduced = 3.2), 
availability(fuchsia, unavailable)));   
// expected-note{{'f5' has been explicitly marked unavailable here}}
 void f6(int) __attribute__((availability(fuchsia, introduced = 16.0)));
  
// expected-warning {{Fuchsia API Level prohibits specifying a minor or 
sub-minor version}}
 void f7(int) __attribute__((availability(fuchsia, introduced = 16.1))); // 
expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor 
version}}
+void f8(int) __attribute__((availability(fuchsia, introduced = 19))); // 
nothing will happen as 'strict' is not specified.
 
 void test() {
   f0(0);
   f1(0);
   f2(0); // expected-warning{{'f2' is deprecated: first deprecated in Fuchsia 
16}}
-  f3(0);
+  f3(0); // expected-error{{'f3' is unavailable: introduced in Fuchsia 19}}
   f4(0); // expected-error{{f4' is unavailable: obsoleted in Fuchsia 16}}
   f5(0); // expected-error{{'f5' is unavailable: not available on Fuchsia}}
+  f8(0);
 }


Index: clang/test/Sema/attr-availability-fuchsia.c
===
--- clang/test/Sema/attr-availability-fuchsia.c
+++ clang/test/Sema/attr-availability-fuchsia.c
@@ -11,17 +11,19 @@
 void f0(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 19)));
 void f1(int) __attribute__((availability(fuchsia, introduced = 16)));
 void f2(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 16))); // expected-note {{'f2' has been explicitly marked deprecated here}}
-void f3(int) __attribute__((availability(fuchsia, introduced = 19)));
+void f3(int) __attribute__((availability(fuchsia, introduced = 19, strict))); // expected-note {{'f3' has been explicitly marked unavailable here}}
 void f4(int) __attribute__((availability(fuchsia, introduced = 9, deprecated = 11, obsoleted = 16), availability(ios, introduced = 2.0, deprecated = 3.0))); // expected-note{{explicitly marked unavailable}}
 void f5(int) __attribute__((availability(ios, introduced = 3.2), availability(fuchsia, unavailable)));   // expected-note{{'f5' has been explicitly marked unavailable here}}
 void f6(int) __attribute__((availability(fuchsia, introduced = 16.0)));  // expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor version}}
 void f7(int) __attribute__((availability(fuchsia, introduced = 16.1))); // expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor version}}
+void f8(int) __attribute__((availability(fuchsia, introduced = 19))); // nothing will happen as 'strict' is not specified.
 
 void test() {
   f0(0);
   f1(0);
   f2(0); // expected-warning{{'f2' is deprecated: first deprecated in Fuchsia 16}}
-  f3(0);
+  f3(0); // expected-error{{'f3' is unavailable: introduced in Fuchsia 19}}
   f4(0); // expected-error{{f4' is unavailable: obsoleted in Fuchsia 16}}
   f5(0); // expected-error{{'f5' is unavailable: not available on Fuchsia}}
+  f8(0);
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D112271: [clang][Fuchsia] Add additional unit test for availability attr

2021-10-21 Thread Haowei Wu via Phabricator via cfe-commits
haowei created this revision.
haowei added reviewers: phosek, leonardchan, gulfem.
Herald added a subscriber: abrachet.
haowei requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This change adds additional unit tests for availability attribute support for 
Fuchsia platform.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D112271

Files:
  clang/test/Sema/attr-availability-fuchsia.c


Index: clang/test/Sema/attr-availability-fuchsia.c
===
--- clang/test/Sema/attr-availability-fuchsia.c
+++ clang/test/Sema/attr-availability-fuchsia.c
@@ -11,17 +11,19 @@
 void f0(int) __attribute__((availability(fuchsia, introduced = 14, deprecated 
= 19)));
 void f1(int) __attribute__((availability(fuchsia, introduced = 16)));
 void f2(int) __attribute__((availability(fuchsia, introduced = 14, deprecated 
= 16))); // expected-note {{'f2' has been explicitly marked deprecated here}}
-void f3(int) __attribute__((availability(fuchsia, introduced = 19)));
+void f3(int) __attribute__((availability(fuchsia, introduced = 19, strict))); 
// expected-note {{'f3' has been explicitly marked unavailable here}}
 void f4(int) __attribute__((availability(fuchsia, introduced = 9, deprecated = 
11, obsoleted = 16), availability(ios, introduced = 2.0, deprecated = 3.0))); 
// expected-note{{explicitly marked unavailable}}
 void f5(int) __attribute__((availability(ios, introduced = 3.2), 
availability(fuchsia, unavailable)));   
// expected-note{{'f5' has been explicitly marked unavailable here}}
 void f6(int) __attribute__((availability(fuchsia, introduced = 16.0)));
  
// expected-warning {{Fuchsia API Level prohibits specifying a minor or 
sub-minor version}}
 void f7(int) __attribute__((availability(fuchsia, introduced = 16.1))); // 
expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor 
version}}
+void f8(int) __attribute__((availability(fuchsia, introduced = 19))); // 
nothing will happen as 'strict' is not specified.
 
 void test() {
   f0(0);
   f1(0);
   f2(0); // expected-warning{{'f2' is deprecated: first deprecated in Fuchsia 
16}}
-  f3(0);
+  f3(0); // expected-error{{'f3' is unavailable: introduced in Fuchsia 19}}
   f4(0); // expected-error{{f4' is unavailable: obsoleted in Fuchsia 16}}
   f5(0); // expected-error{{'f5' is unavailable: not available on Fuchsia}}
+  f8(0);
 }


Index: clang/test/Sema/attr-availability-fuchsia.c
===
--- clang/test/Sema/attr-availability-fuchsia.c
+++ clang/test/Sema/attr-availability-fuchsia.c
@@ -11,17 +11,19 @@
 void f0(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 19)));
 void f1(int) __attribute__((availability(fuchsia, introduced = 16)));
 void f2(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 16))); // expected-note {{'f2' has been explicitly marked deprecated here}}
-void f3(int) __attribute__((availability(fuchsia, introduced = 19)));
+void f3(int) __attribute__((availability(fuchsia, introduced = 19, strict))); // expected-note {{'f3' has been explicitly marked unavailable here}}
 void f4(int) __attribute__((availability(fuchsia, introduced = 9, deprecated = 11, obsoleted = 16), availability(ios, introduced = 2.0, deprecated = 3.0))); // expected-note{{explicitly marked unavailable}}
 void f5(int) __attribute__((availability(ios, introduced = 3.2), availability(fuchsia, unavailable)));   // expected-note{{'f5' has been explicitly marked unavailable here}}
 void f6(int) __attribute__((availability(fuchsia, introduced = 16.0)));  // expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor version}}
 void f7(int) __attribute__((availability(fuchsia, introduced = 16.1))); // expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor version}}
+void f8(int) __attribute__((availability(fuchsia, introduced = 19))); // nothing will happen as 'strict' is not specified.
 
 void test() {
   f0(0);
   f1(0);
   f2(0); // expected-warning{{'f2' is deprecated: first deprecated in Fuchsia 16}}
-  f3(0);
+  f3(0); // expected-error{{'f3' is unavailable: introduced in Fuchsia 19}}
   f4(0); // expected-error{{f4' is unavailable: obsoleted in Fuchsia 16}}
   f5(0); // expected-error{{'f5' is unavailable: not available on Fuchsia}}
+  f8(0);
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D108592: [clang][Fuchsia] Support __attribute__((availability)) on Fuchsia

2021-10-11 Thread Haowei Wu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG1131b1eb3509: [clang][Fuchsia] Support availability attr on 
Fuchsia (authored by haowei).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108592/new/

https://reviews.llvm.org/D108592

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/OSTargets.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Driver/attr-availability-fuchsia.c
  clang/test/Sema/attr-availability-fuchsia.c

Index: clang/test/Sema/attr-availability-fuchsia.c
===
--- /dev/null
+++ clang/test/Sema/attr-availability-fuchsia.c
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 "-triple" "x86_64-unknown-fuchsia" -ffuchsia-api-level=16 -fsyntax-only -verify %s
+// RUN: %clang_cc1 "-triple" "x86_64-unknown-fuchsia" -fsyntax-only %s 2>&1 | FileCheck %s
+
+// If the version is not specified, we should not get any errors since there
+// is no checking (the major version number is zero).
+// CHECK-NOT: error:
+
+void f0(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 19)));
+void f1(int) __attribute__((availability(fuchsia, introduced = 16)));
+void f2(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 16))); // expected-note {{'f2' has been explicitly marked deprecated here}}
+void f3(int) __attribute__((availability(fuchsia, introduced = 19)));
+void f4(int) __attribute__((availability(fuchsia, introduced = 9, deprecated = 11, obsoleted = 16), availability(ios, introduced = 2.0, deprecated = 3.0))); // expected-note{{explicitly marked unavailable}}
+void f5(int) __attribute__((availability(ios, introduced = 3.2), availability(fuchsia, unavailable)));   // expected-note{{'f5' has been explicitly marked unavailable here}}
+void f6(int) __attribute__((availability(fuchsia, introduced = 16.0)));  // expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor version}}
+void f7(int) __attribute__((availability(fuchsia, introduced = 16.1))); // expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor version}}
+
+void test() {
+  f0(0);
+  f1(0);
+  f2(0); // expected-warning{{'f2' is deprecated: first deprecated in Fuchsia 16}}
+  f3(0);
+  f4(0); // expected-error{{f4' is unavailable: obsoleted in Fuchsia 16}}
+  f5(0); // expected-error{{'f5' is unavailable: not available on Fuchsia}}
+}
Index: clang/test/Driver/attr-availability-fuchsia.c
===
--- /dev/null
+++ clang/test/Driver/attr-availability-fuchsia.c
@@ -0,0 +1,45 @@
+// Test that `-ffuchsia-api-level` is propagated to cc1.
+// RUN: %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=16 -c %s -### 2>&1| FileCheck %s
+
+// It should also be exposed to non-fuchsia platforms. This is desireable when
+// using common Fuchsia headers for building host libraries that also depend on
+// the Fuchsia version (such as using a compatible host-side FIDL library that
+// talks with a Fuchsia FIDL library of the same version).
+// RUN: %clang -target x86_64-unknown-linux-gnu -ffuchsia-api-level=16 -c %s -### 2>&1 | FileCheck %s
+
+// Check Fuchsia API level macro.
+// RUN: %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=15 -c %s -o %t
+// RUN: llvm-readobj --symbols %t | FileCheck %s --check-prefix=CHECK-F15
+//
+// RUN: %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=16 -c %s -o %t
+// RUN: llvm-readobj --symbols %t | FileCheck %s --check-prefix=CHECK-F16
+
+// Check using a non-integer Fuchsia API level.
+// RUN: not %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=16.0.0 -c %s  2>&1| FileCheck %s  --check-prefix=CHECK-ERROR
+
+
+// CHECK: "-ffuchsia-api-level=16"
+
+// CHECK-F15:   Name: f15
+
+// CHECK-F16:   Name: f16
+
+// CHECK-ERROR: error: invalid integral value '16.0.0' in '-ffuchsia-api-level=16.0.0'
+
+#if __Fuchsia_API_level__ >= 16
+void f16() {
+
+}
+#else
+void f15() {
+
+}
+#endif
+
+int main(int argc, char* argv[]) {
+#if __Fuchsia_API_level__ >= 16
+f16();
+#else
+f15();
+#endif
+}
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -2496,6 +2496,15 @@
 }
   }
 
+  if (II->isStr("fuchsia")) {
+Optional Min, Sub;
+if ((Min = Introduced.Version.getMinor()) ||
+(Sub = Introduced.Version.getSubminor())) {
+  S.Diag(AL.getLoc(), diag::warn_availability_fuchsia_unavailable_minor);
+  return;
+}
+  }
+
   int PriorityModifier = 

[PATCH] D108592: [clang][Fuchsia] Support __attribute__((availability)) on Fuchsia

2021-10-11 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 378784.
haowei added a comment.

Address review comments.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108592/new/

https://reviews.llvm.org/D108592

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/OSTargets.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Driver/attr-availability-fuchsia.c
  clang/test/Sema/attr-availability-fuchsia.c

Index: clang/test/Sema/attr-availability-fuchsia.c
===
--- /dev/null
+++ clang/test/Sema/attr-availability-fuchsia.c
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 "-triple" "x86_64-unknown-fuchsia" -ffuchsia-api-level=16 -fsyntax-only -verify %s
+// RUN: %clang_cc1 "-triple" "x86_64-unknown-fuchsia" -fsyntax-only %s 2>&1 | FileCheck %s
+
+// If the version is not specified, we should not get any errors since there
+// is no checking (the major version number is zero).
+// CHECK-NOT: error:
+
+void f0(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 19)));
+void f1(int) __attribute__((availability(fuchsia, introduced = 16)));
+void f2(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 16))); // expected-note {{'f2' has been explicitly marked deprecated here}}
+void f3(int) __attribute__((availability(fuchsia, introduced = 19)));
+void f4(int) __attribute__((availability(fuchsia, introduced = 9, deprecated = 11, obsoleted = 16), availability(ios, introduced = 2.0, deprecated = 3.0))); // expected-note{{explicitly marked unavailable}}
+void f5(int) __attribute__((availability(ios, introduced = 3.2), availability(fuchsia, unavailable)));   // expected-note{{'f5' has been explicitly marked unavailable here}}
+void f6(int) __attribute__((availability(fuchsia, introduced = 16.0)));  // expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor version}}
+void f7(int) __attribute__((availability(fuchsia, introduced = 16.1))); // expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor version}}
+
+void test() {
+  f0(0);
+  f1(0);
+  f2(0); // expected-warning{{'f2' is deprecated: first deprecated in Fuchsia 16}}
+  f3(0);
+  f4(0); // expected-error{{f4' is unavailable: obsoleted in Fuchsia 16}}
+  f5(0); // expected-error{{'f5' is unavailable: not available on Fuchsia}}
+}
Index: clang/test/Driver/attr-availability-fuchsia.c
===
--- /dev/null
+++ clang/test/Driver/attr-availability-fuchsia.c
@@ -0,0 +1,45 @@
+// Test that `-ffuchsia-api-level` is propagated to cc1.
+// RUN: %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=16 -c %s -### 2>&1| FileCheck %s
+
+// It should also be exposed to non-fuchsia platforms. This is desireable when
+// using common Fuchsia headers for building host libraries that also depend on
+// the Fuchsia version (such as using a compatible host-side FIDL library that
+// talks with a Fuchsia FIDL library of the same version).
+// RUN: %clang -target x86_64-unknown-linux-gnu -ffuchsia-api-level=16 -c %s -### 2>&1 | FileCheck %s
+
+// Check Fuchsia API level macro.
+// RUN: %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=15 -c %s -o %t
+// RUN: llvm-readobj --symbols %t | FileCheck %s --check-prefix=CHECK-F15
+//
+// RUN: %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=16 -c %s -o %t
+// RUN: llvm-readobj --symbols %t | FileCheck %s --check-prefix=CHECK-F16
+
+// Check using a non-integer Fuchsia API level.
+// RUN: not %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=16.0.0 -c %s  2>&1| FileCheck %s  --check-prefix=CHECK-ERROR
+
+
+// CHECK: "-ffuchsia-api-level=16"
+
+// CHECK-F15:   Name: f15
+
+// CHECK-F16:   Name: f16
+
+// CHECK-ERROR: error: invalid integral value '16.0.0' in '-ffuchsia-api-level=16.0.0'
+
+#if __Fuchsia_API_level__ >= 16
+void f16() {
+
+}
+#else
+void f15() {
+
+}
+#endif
+
+int main(int argc, char* argv[]) {
+#if __Fuchsia_API_level__ >= 16
+f16();
+#else
+f15();
+#endif
+}
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -2496,6 +2496,15 @@
 }
   }
 
+  if (II->isStr("fuchsia")) {
+Optional Min, Sub;
+if ((Min = Introduced.Version.getMinor()) ||
+(Sub = Introduced.Version.getSubminor())) {
+  S.Diag(AL.getLoc(), diag::warn_availability_fuchsia_unavailable_minor);
+  return;
+}
+  }
+
   int PriorityModifier = AL.isPragmaClangAttribute()
  ? Sema::AP_PragmaClangAttribute
  : 

[PATCH] D108592: [clang][Fuchsia] Support __attribute__((availability)) on Fuchsia

2021-10-11 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 378780.
haowei added a comment.

Fix test failures on Windows.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108592/new/

https://reviews.llvm.org/D108592

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/OSTargets.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Driver/attr-availability-fuchsia.c
  clang/test/Sema/attr-availability-fuchsia.c

Index: clang/test/Sema/attr-availability-fuchsia.c
===
--- /dev/null
+++ clang/test/Sema/attr-availability-fuchsia.c
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 "-triple" "x86_64-unknown-fuchsia" -ffuchsia-api-level=16 -fsyntax-only -verify %s
+// RUN: %clang_cc1 "-triple" "x86_64-unknown-fuchsia" -fsyntax-only %s 2>&1 | FileCheck %s
+
+// If the version is not specified, we should not get any errors since there
+// is no checking (the major version number is zero).
+// CHECK-NOT: error:
+
+void f0(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 19)));
+void f1(int) __attribute__((availability(fuchsia, introduced = 16)));
+void f2(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 16))); // expected-note {{'f2' has been explicitly marked deprecated here}}
+void f3(int) __attribute__((availability(fuchsia, introduced = 19)));
+void f4(int) __attribute__((availability(fuchsia, introduced = 9, deprecated = 11, obsoleted = 16), availability(ios, introduced = 2.0, deprecated = 3.0))); // expected-note{{explicitly marked unavailable}}
+void f5(int) __attribute__((availability(ios, introduced = 3.2), availability(fuchsia, unavailable)));   // expected-note{{'f5' has been explicitly marked unavailable here}}
+void f6(int) __attribute__((availability(fuchsia, introduced = 16.0)));  // expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor version}}
+void f7(int) __attribute__((availability(fuchsia, introduced = 16.1))); // expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor version}}
+
+void test() {
+  f0(0);
+  f1(0);
+  f2(0); // expected-warning{{'f2' is deprecated: first deprecated in Fuchsia 16}}
+  f3(0);
+  f4(0); // expected-error{{f4' is unavailable: obsoleted in Fuchsia 16}}
+  f5(0); // expected-error{{'f5' is unavailable: not available on Fuchsia}}
+}
Index: clang/test/Driver/attr-availability-fuchsia.c
===
--- /dev/null
+++ clang/test/Driver/attr-availability-fuchsia.c
@@ -0,0 +1,43 @@
+// Test that `-ffuchsia-api-level` is propagated to cc1.
+// RUN: %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=16 -c %s -### 2>&1| FileCheck %s
+//
+// RUN: not %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=16.0.0 -c %s  2>&1| FileCheck %s  --check-prefix=CHECK-ERROR
+
+// It should also be exposed to non-fuchsia platforms. This is desireable when
+// using common Fuchsia headers for building host libraries that also depend on
+// the Fuchsia version (such as using a compatible host-side FIDL library that
+// talks with a Fuchsia FIDL library of the same version).
+// RUN: %clang -target x86_64-unknown-linux-gnu -ffuchsia-api-level=16 -c %s -### 2>&1 | FileCheck %s
+//
+// Check Fuchsia API Level macro.
+// RUN: %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=15 -c %s -o %t
+// RUN: llvm-readobj --symbols %t | FileCheck %s --check-prefix=CHECK-F15
+
+// RUN: %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=16 -c %s -o %t
+// RUN: llvm-readobj --symbols %t | FileCheck %s --check-prefix=CHECK-F16
+
+// CHECK: "-ffuchsia-api-level=16"
+
+// CHECK-F15:   Name: f15
+
+// CHECK-F16:   Name: f16
+
+// CHECK-ERROR: error: invalid integral value '16.0.0' in '-ffuchsia-api-level=16.0.0'
+
+#if __Fuchsia_API_level__ >= 16
+void f16() {
+
+}
+#else
+void f15() {
+
+}
+#endif
+
+int main(int argc, char* argv[]) {
+#if __Fuchsia_API_level__ >= 16
+f16();
+#else
+f15();
+#endif
+}
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -2496,6 +2496,15 @@
 }
   }
 
+  if (II->isStr("fuchsia")) {
+Optional Min, Sub;
+if ((Min = Introduced.Version.getMinor()) ||
+(Sub = Introduced.Version.getSubminor())) {
+  S.Diag(AL.getLoc(), diag::warn_availability_fuchsia_unavailable_minor);
+  return;
+}
+  }
+
   int PriorityModifier = AL.isPragmaClangAttribute()
  ? Sema::AP_PragmaClangAttribute
  : Sema::AP_Explicit;

[PATCH] D108592: [clang][Fuchsia] Support __attribute__((availability)) on Fuchsia

2021-10-08 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 378324.
haowei added a comment.

Added unit test when "-ffuchsia-api-level" is supplied with a non integer value.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108592/new/

https://reviews.llvm.org/D108592

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/OSTargets.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Driver/attr-availability-fuchsia.c
  clang/test/Sema/attr-availability-fuchsia.c

Index: clang/test/Sema/attr-availability-fuchsia.c
===
--- /dev/null
+++ clang/test/Sema/attr-availability-fuchsia.c
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 "-triple" "x86_64-unknown-fuchsia" -ffuchsia-api-level=16 -fsyntax-only -verify %s
+// RUN: %clang_cc1 "-triple" "x86_64-unknown-fuchsia" -fsyntax-only %s |& FileCheck %s
+
+// If the version is not specified, we should not get any errors since there
+// is no checking (the major version number is zero).
+// CHECK-NOT: error:
+
+void f0(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 19)));
+void f1(int) __attribute__((availability(fuchsia, introduced = 16)));
+void f2(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 16))); // expected-note {{'f2' has been explicitly marked deprecated here}}
+void f3(int) __attribute__((availability(fuchsia, introduced = 19)));
+void f4(int) __attribute__((availability(fuchsia, introduced = 9, deprecated = 11, obsoleted = 16), availability(ios, introduced = 2.0, deprecated = 3.0))); // expected-note{{explicitly marked unavailable}}
+void f5(int) __attribute__((availability(ios, introduced = 3.2), availability(fuchsia, unavailable)));   // expected-note{{'f5' has been explicitly marked unavailable here}}
+void f6(int) __attribute__((availability(fuchsia, introduced = 16.0)));  // expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor version}}
+void f7(int) __attribute__((availability(fuchsia, introduced = 16.1))); // expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor version}}
+
+void test() {
+  f0(0);
+  f1(0);
+  f2(0); // expected-warning{{'f2' is deprecated: first deprecated in Fuchsia 16}}
+  f3(0);
+  f4(0); // expected-error{{f4' is unavailable: obsoleted in Fuchsia 16}}
+  f5(0); // expected-error{{'f5' is unavailable: not available on Fuchsia}}
+}
Index: clang/test/Driver/attr-availability-fuchsia.c
===
--- /dev/null
+++ clang/test/Driver/attr-availability-fuchsia.c
@@ -0,0 +1,43 @@
+// Test that `-ffuchsia-api-level` is propagated to cc1.
+// RUN: %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=16 -c %s -### 2>&1| FileCheck %s
+//
+// RUN: not %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=16.0.0 -c %s  2>&1| FileCheck %s  --check-prefix=CHECK-ERROR
+
+// It should also be exposed to non-fuchsia platforms. This is desireable when
+// using common Fuchsia headers for building host libraries that also depend on
+// the Fuchsia version (such as using a compatible host-side FIDL library that
+// talks with a Fuchsia FIDL library of the same version).
+// RUN: %clang -target x86_64-unknown-linux-gnu -ffuchsia-api-level=16 -c %s -### 2>&1 | FileCheck %s
+//
+// Check Fuchsia API Level macro.
+// RUN: %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=15 -c %s -o %t
+// RUN: llvm-readobj --symbols %t | FileCheck %s --check-prefix=CHECK-F15
+
+// RUN: %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=16 -c %s -o %t
+// RUN: llvm-readobj --symbols %t | FileCheck %s --check-prefix=CHECK-F16
+
+// CHECK: "-ffuchsia-api-level=16"
+
+// CHECK-F15:   Name: f15
+
+// CHECK-F16:   Name: f16
+
+// CHECK-ERROR: error: invalid integral value '16.0.0' in '-ffuchsia-api-level=16.0.0'
+
+#if __Fuchsia_API_level__ >= 16
+void f16() {
+
+}
+#else
+void f15() {
+
+}
+#endif
+
+int main(int argc, char* argv[]) {
+#if __Fuchsia_API_level__ >= 16
+f16();
+#else
+f15();
+#endif
+}
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -2496,6 +2496,15 @@
 }
   }
 
+  if (II->isStr("fuchsia")) {
+Optional Min, Sub;
+if ((Min = Introduced.Version.getMinor()) ||
+(Sub = Introduced.Version.getSubminor())) {
+  S.Diag(AL.getLoc(), diag::warn_availability_fuchsia_unavailable_minor);
+  return;
+}
+  }
+
   int PriorityModifier = AL.isPragmaClangAttribute()
  ? Sema::AP_PragmaClangAttribute

[PATCH] D108592: [clang][Fuchsia] Support __attribute__((availability)) on Fuchsia

2021-10-07 Thread Haowei Wu via Phabricator via cfe-commits
haowei added a comment.

I added unit test for macros. I am still working on adding error checks on 
`--ffuchsia-api-level` flags but the rest is pretty much done.




Comment at: clang/test/Frontend/attr-availability-fuchsia.c:4
+//
+// It should also be exposed to non-fuchsia platforms. This is desireable when
+// using common Fuchsia headers for building host libraries that also depend on

haowei wrote:
> phosek wrote:
> > Would this also set the availability attribute? Can we test it? If not then 
> > this isn't particularly useful.
> Do you mean the macros? I can add one.
@phosek  I added unit test for macros. Could you confirm it is what you 
suggested in the previous comments? Thanks.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108592/new/

https://reviews.llvm.org/D108592

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D108592: [clang][Fuchsia] Support __attribute__((availability)) on Fuchsia

2021-10-07 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 378052.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108592/new/

https://reviews.llvm.org/D108592

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/OSTargets.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Driver/attr-availability-fuchsia.c
  clang/test/Sema/attr-availability-fuchsia.c

Index: clang/test/Sema/attr-availability-fuchsia.c
===
--- /dev/null
+++ clang/test/Sema/attr-availability-fuchsia.c
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 "-triple" "x86_64-unknown-fuchsia" -ffuchsia-api-level=16 -fsyntax-only -verify %s
+// RUN: %clang_cc1 "-triple" "x86_64-unknown-fuchsia" -fsyntax-only %s |& FileCheck %s
+
+// If the version is not specified, we should not get any errors since there
+// is no checking (the major version number is zero).
+// CHECK-NOT: error:
+
+void f0(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 19)));
+void f1(int) __attribute__((availability(fuchsia, introduced = 16)));
+void f2(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 16))); // expected-note {{'f2' has been explicitly marked deprecated here}}
+void f3(int) __attribute__((availability(fuchsia, introduced = 19)));
+void f4(int) __attribute__((availability(fuchsia, introduced = 9, deprecated = 11, obsoleted = 16), availability(ios, introduced = 2.0, deprecated = 3.0))); // expected-note{{explicitly marked unavailable}}
+void f5(int) __attribute__((availability(ios, introduced = 3.2), availability(fuchsia, unavailable)));   // expected-note{{'f5' has been explicitly marked unavailable here}}
+void f6(int) __attribute__((availability(fuchsia, introduced = 16.0)));  // expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor version}}
+void f7(int) __attribute__((availability(fuchsia, introduced = 16.1))); // expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor version}}
+
+void test() {
+  f0(0);
+  f1(0);
+  f2(0); // expected-warning{{'f2' is deprecated: first deprecated in Fuchsia 16}}
+  f3(0);
+  f4(0); // expected-error{{f4' is unavailable: obsoleted in Fuchsia 16}}
+  f5(0); // expected-error{{'f5' is unavailable: not available on Fuchsia}}
+}
Index: clang/test/Driver/attr-availability-fuchsia.c
===
--- /dev/null
+++ clang/test/Driver/attr-availability-fuchsia.c
@@ -0,0 +1,43 @@
+// Test that `-ffuchsia-api-level` is propagated to cc1.
+// RUN: %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=16 -c %s -### 2>&1| FileCheck %s
+//
+// RUN: %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=16.0.0 -c %s -### 2>&1| FileCheck %s  --check-prefix=CHECK-MINOR
+// It should also be exposed to non-fuchsia platforms. This is desireable when
+// using common Fuchsia headers for building host libraries that also depend on
+// the Fuchsia version (such as using a compatible host-side FIDL library that
+// talks with a Fuchsia FIDL library of the same version).
+// RUN: %clang -target x86_64-unknown-linux-gnu -ffuchsia-api-level=16 -c %s -### 2>&1 | FileCheck %s
+//
+// Check Fuchsia API Level macro.
+// RUN: %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=15 -c %s -o %t
+// RUN: llvm-readobj --symbols %t | FileCheck %s --check-prefix=CHECK-F15
+
+// RUN: %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=16 -c %s -o %t
+// RUN: llvm-readobj --symbols %t | FileCheck %s --check-prefix=CHECK-F16
+
+// CHECK: "-ffuchsia-api-level=16"
+
+// CHECK-MINOR: "-ffuchsia-api-level=16.0.0"
+
+// CHECK-F15:   Name: f15
+
+// CHECK-F16:   Name: f16
+
+
+#if __Fuchsia_API_level__ >= 16
+void f16() {
+
+}
+#else
+void f15() {
+
+}
+#endif
+
+int main(int argc, char* argv[]) {
+#if __Fuchsia_API_level__ >= 16
+f16();
+#else
+f15();
+#endif
+}
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -2496,6 +2496,15 @@
 }
   }
 
+  if (II->isStr("fuchsia")) {
+Optional Min, Sub;
+if ((Min = Introduced.Version.getMinor()) ||
+(Sub = Introduced.Version.getSubminor())) {
+  S.Diag(AL.getLoc(), diag::warn_availability_fuchsia_unavailable_minor);
+  return;
+}
+  }
+
   int PriorityModifier = AL.isPragmaClangAttribute()
  ? Sema::AP_PragmaClangAttribute
  : Sema::AP_Explicit;
Index: clang/lib/Driver/ToolChains/Clang.cpp

[PATCH] D108592: [clang][Fuchsia] Support __attribute__((availability)) on Fuchsia

2021-10-06 Thread Haowei Wu via Phabricator via cfe-commits
haowei marked an inline comment as done.
haowei added inline comments.



Comment at: clang/lib/Basic/Targets/OSTargets.h:893
   Builder.defineMacro("_GNU_SOURCE");
+Builder.defineMacro("FUCHSIA_API_LEVEL", Twine(Opts.FuchsiaAPILevel));
+this->PlatformName = "fuchsia";

phosek wrote:
> aaron.ballman wrote:
> > I think this macro should be using a reserved name, as suggested by @phosek.
> @aaron.ballman Do you have any thoughts on the letter case? I think that 
> `__Fuchsia_API_level__` might be a better match for `__Fuchsia__`. Upper case 
> is perhaps more usual, but other platforms like *BSD also use mixed case.
I changed it to "__Fuchsia_API_level__" for now.



Comment at: clang/test/Frontend/attr-availability-fuchsia.c:2
+// Test that `-mfuchsia-version` is propagated to cc1.
+// RUN: %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=16 -c %s 
-### 2>&1| FileCheck %s
+//

aaron.ballman wrote:
> Can you also add a test that shows how we handle `-ffuchsia-api-level=16.0.0`?
I did. But it does not fail. I will look into it to see if I can add the same 
constraint like the attributes tomorrow.



Comment at: clang/test/Frontend/attr-availability-fuchsia.c:4
+//
+// It should also be exposed to non-fuchsia platforms. This is desireable when
+// using common Fuchsia headers for building host libraries that also depend on

phosek wrote:
> Would this also set the availability attribute? Can we test it? If not then 
> this isn't particularly useful.
Do you mean the macros? I can add one.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108592/new/

https://reviews.llvm.org/D108592

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D108592: [clang][Fuchsia] Support __attribute__((availability)) on Fuchsia

2021-10-06 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 377726.
haowei marked an inline comment as done.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108592/new/

https://reviews.llvm.org/D108592

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/OSTargets.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Driver/attr-availability-fuchsia.c
  clang/test/Sema/attr-availability-fuchsia.c

Index: clang/test/Sema/attr-availability-fuchsia.c
===
--- /dev/null
+++ clang/test/Sema/attr-availability-fuchsia.c
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 "-triple" "x86_64-unknown-fuchsia" -ffuchsia-api-level=16 -fsyntax-only -verify %s
+// RUN: %clang_cc1 "-triple" "x86_64-unknown-fuchsia" -fsyntax-only %s |& FileCheck %s
+
+// If the version is not specified, we should not get any errors since there
+// is no checking (the major version number is zero).
+// CHECK-NOT: error:
+
+void f0(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 19)));
+void f1(int) __attribute__((availability(fuchsia, introduced = 16)));
+void f2(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 16))); // expected-note {{'f2' has been explicitly marked deprecated here}}
+void f3(int) __attribute__((availability(fuchsia, introduced = 19)));
+void f4(int) __attribute__((availability(fuchsia, introduced = 9, deprecated = 11, obsoleted = 16), availability(ios, introduced = 2.0, deprecated = 3.0))); // expected-note{{explicitly marked unavailable}}
+void f5(int) __attribute__((availability(ios, introduced = 3.2), availability(fuchsia, unavailable)));   // expected-note{{'f5' has been explicitly marked unavailable here}}
+void f6(int) __attribute__((availability(fuchsia, introduced = 16.0)));  // expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor version}}
+void f7(int) __attribute__((availability(fuchsia, introduced = 16.1))); // expected-warning {{Fuchsia API Level prohibits specifying a minor or sub-minor version}}
+
+void test() {
+  f0(0);
+  f1(0);
+  f2(0); // expected-warning{{'f2' is deprecated: first deprecated in Fuchsia 16}}
+  f3(0);
+  f4(0); // expected-error{{f4' is unavailable: obsoleted in Fuchsia 16}}
+  f5(0); // expected-error{{'f5' is unavailable: not available on Fuchsia}}
+}
Index: clang/test/Driver/attr-availability-fuchsia.c
===
--- /dev/null
+++ clang/test/Driver/attr-availability-fuchsia.c
@@ -0,0 +1,12 @@
+// Test that `-ffuchsia-api-level` is propagated to cc1.
+// RUN: %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=16 -c %s -### 2>&1| FileCheck %s
+//
+// RUN: %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=16.0.0 -c %s -### 2>&1| FileCheck %s  --check-prefix=CHECK-MINOR
+// It should also be exposed to non-fuchsia platforms. This is desireable when
+// using common Fuchsia headers for building host libraries that also depend on
+// the Fuchsia version (such as using a compatible host-side FIDL library that
+// talks with a Fuchsia FIDL library of the same version).
+// RUN: %clang -target x86_64-unknown-linux-gnu -ffuchsia-api-level=16 -c %s -### 2>&1 | FileCheck %s
+//
+// CHECK: "-ffuchsia-api-level=16"
+// CHECK-MINOR: "-ffuchsia-api-level=16.0.0"
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -2496,6 +2496,15 @@
 }
   }
 
+  if (II->isStr("fuchsia")) {
+Optional Min, Sub;
+if ((Min = Introduced.Version.getMinor()) ||
+(Sub = Introduced.Version.getSubminor())) {
+  S.Diag(AL.getLoc(), diag::warn_availability_fuchsia_unavailable_minor);
+  return;
+}
+  }
+
   int PriorityModifier = AL.isPragmaClangAttribute()
  ? Sema::AP_PragmaClangAttribute
  : Sema::AP_Explicit;
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5475,6 +5475,9 @@
   Args.AddLastArg(CmdArgs, options::OPT_fexperimental_relative_cxx_abi_vtables,
   options::OPT_fno_experimental_relative_cxx_abi_vtables);
 
+  if (Arg *A = Args.getLastArg(options::OPT_ffuchsia_api_level_EQ))
+A->render(Args, CmdArgs);
+
   // Handle -{std, ansi, trigraphs} -- take the last of -{std, ansi}
   // (-ansi is equivalent to -std=c89 or -std=c++98).
   //
Index: clang/lib/Basic/Targets/OSTargets.h

[PATCH] D108592: [clang][Fuchsia] Support __attribute__((availability)) on Fuchsia

2021-10-05 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 377389.
haowei edited the summary of this revision.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108592/new/

https://reviews.llvm.org/D108592

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/OSTargets.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Frontend/attr-availability-fuchsia.c
  clang/test/Sema/attr-availability-fuchsia.c

Index: clang/test/Sema/attr-availability-fuchsia.c
===
--- /dev/null
+++ clang/test/Sema/attr-availability-fuchsia.c
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 "-triple" "x86_64-unknown-fuchsia" -ffuchsia-api-level=16 -fsyntax-only -verify %s
+// RUN: %clang_cc1 "-triple" "x86_64-unknown-fuchsia" -fsyntax-only %s |& FileCheck %s
+
+// If the version is not specified, we should not get any errors since there
+// is no checking (the major version number is zero).
+// CHECK-NOT: error:
+
+void f0(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 19)));
+void f1(int) __attribute__((availability(fuchsia, introduced = 16)));
+void f2(int) __attribute__((availability(fuchsia, introduced = 14, deprecated = 16))); // expected-note {{'f2' has been explicitly marked deprecated here}}
+void f3(int) __attribute__((availability(fuchsia, introduced = 19)));
+void f4(int) __attribute__((availability(fuchsia, introduced = 9, deprecated = 11, obsoleted = 16), availability(ios, introduced = 2.0, deprecated = 3.0))); // expected-note{{explicitly marked unavailable}}
+void f5(int) __attribute__((availability(ios, introduced = 3.2), availability(fuchsia, unavailable)));   // expected-note{{'f5' has been explicitly marked unavailable here}}
+void f6(int) __attribute__((availability(fuchsia, introduced = 16.0)));  // expected-warning {{Fuchsia API Level only support 'major', not '.minor[.subminor]}}
+void f7(int) __attribute__((availability(fuchsia, introduced = 16.1))); // expected-warning {{Fuchsia API Level only support 'major', not '.minor[.subminor]}}
+
+void test() {
+  f0(0);
+  f1(0);
+  f2(0); // expected-warning{{'f2' is deprecated: first deprecated in Fuchsia 16}}
+  f3(0);
+  f4(0); // expected-error{{f4' is unavailable: obsoleted in Fuchsia 16}}
+  f5(0); // expected-error{{'f5' is unavailable: not available on Fuchsia}}
+}
Index: clang/test/Frontend/attr-availability-fuchsia.c
===
--- /dev/null
+++ clang/test/Frontend/attr-availability-fuchsia.c
@@ -0,0 +1,10 @@
+// Test that `-mfuchsia-version` is propagated to cc1.
+// RUN: %clang -target x86_64-unknown-fuchsia -ffuchsia-api-level=16 -c %s -### 2>&1| FileCheck %s
+//
+// It should also be exposed to non-fuchsia platforms. This is desireable when
+// using common Fuchsia headers for building host libraries that also depend on
+// the Fuchsia version (such as using a compatible host-side FIDL library that
+// talks with a Fuchsia FIDL library of the same version).
+// RUN: %clang -target x86_64-unknown-linux-gnu -ffuchsia-api-level=16 -c %s -### 2>&1 | FileCheck %s
+//
+// CHECK: "-ffuchsia-api-level=16"
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -2496,6 +2496,15 @@
 }
   }
 
+  if (II->isStr("fuchsia")) {
+Optional Min, Sub;
+if ((Min = Introduced.Version.getMinor()) ||
+(Sub = Introduced.Version.getSubminor())) {
+  S.Diag(AL.getLoc(), diag::warn_availability_fuchsia_unavailable_minor);
+  return;
+}
+  }
+
   int PriorityModifier = AL.isPragmaClangAttribute()
  ? Sema::AP_PragmaClangAttribute
  : Sema::AP_Explicit;
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5475,6 +5475,9 @@
   Args.AddLastArg(CmdArgs, options::OPT_fexperimental_relative_cxx_abi_vtables,
   options::OPT_fno_experimental_relative_cxx_abi_vtables);
 
+  if (Arg *A = Args.getLastArg(options::OPT_ffuchsia_api_level_EQ))
+A->render(Args, CmdArgs);
+
   // Handle -{std, ansi, trigraphs} -- take the last of -{std, ansi}
   // (-ansi is equivalent to -std=c89 or -std=c++98).
   //
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -890,6 +890,9 @@
 // Required by the libc++ locale 

  1   2   >