from:"Haowei Wu via Phabricator via cfe\-commits"

[PATCH] D34489: [scan-build-py] Patch to fix "-analyzer-config" option

2017-06-21 Thread Haowei Wu via Phabricator via cfe-commits

haowei created this revision.
Herald added a subscriber: whisperity.

I noticed that when I use "-analyze-config" option in scan-build-py, it behaves 
differently from original perl based scan-build.

For example, command:

$ scan-build -analyzer-config ipa=basic-inlining make

Will work without any issues on perl version of scan-build. But on 
scan-build-py it will throw an error message "error reading 
'ipa=basic-inlining'". 
After debugging, it turns out that the scan-build-py does not put 
"-analyzer-config" flag in front of the analyzer config flags (in this case is 
the "ipa=basic-inlining") in the final clang command line. This patch fixes 
this issue.


https://reviews.llvm.org/D34489

Files:
  tools/scan-build-py/libscanbuild/analyze.py


Index: tools/scan-build-py/libscanbuild/analyze.py
===
--- tools/scan-build-py/libscanbuild/analyze.py
+++ tools/scan-build-py/libscanbuild/analyze.py
@@ -249,7 +249,7 @@
 if args.output_format:
 result.append('-analyzer-output={0}'.format(args.output_format))
 if args.analyzer_config:
-result.append(args.analyzer_config)
+result.extend(['-analyzer-config', args.analyzer_config])
 if args.verbose >= 4:
 result.append('-analyzer-display-progress')
 if args.plugins:


Index: tools/scan-build-py/libscanbuild/analyze.py
===
--- tools/scan-build-py/libscanbuild/analyze.py
+++ tools/scan-build-py/libscanbuild/analyze.py
@@ -249,7 +249,7 @@
 if args.output_format:
 result.append('-analyzer-output={0}'.format(args.output_format))
 if args.analyzer_config:
-result.append(args.analyzer_config)
+result.extend(['-analyzer-config', args.analyzer_config])
 if args.verbose >= 4:
 result.append('-analyzer-display-progress')
 if args.plugins:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100139: [ifs][elfabi] Merge llvm-ifs/elfabi tools

2021-07-19 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 rG6103fdfab4e2: [ifs][elfabi] Merge llvm-ifs/elfabi tools 
(authored by haowei).

Changed prior to commit:
  https://reviews.llvm.org/D100139?vs=353507&id=359856#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100139

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  clang/lib/Driver/ToolChains/InterfaceStubs.cpp
  clang/test/InterfaceStubs/driver-test.c
  llvm/include/llvm/InterfaceStub/ELFObjHandler.h
  llvm/include/llvm/InterfaceStub/IFSHandler.h
  llvm/include/llvm/InterfaceStub/IFSStub.h
  llvm/lib/InterfaceStub/ELFObjHandler.cpp
  llvm/lib/InterfaceStub/IFSHandler.cpp
  llvm/lib/InterfaceStub/IFSStub.cpp
  llvm/test/CMakeLists.txt
  llvm/test/tools/llvm-ifs/binary-read-add-soname.test
  llvm/test/tools/llvm-ifs/binary-read-arch.test
  llvm/test/tools/llvm-ifs/binary-read-bad-soname.test
  llvm/test/tools/llvm-ifs/binary-read-bad-vaddr.test
  llvm/test/tools/llvm-ifs/binary-read-neededlibs-bad-offset.test
  llvm/test/tools/llvm-ifs/binary-read-neededlibs.test
  llvm/test/tools/llvm-ifs/binary-read-no-dt-strsz.test
  llvm/test/tools/llvm-ifs/binary-read-no-dt-strtab.test
  llvm/test/tools/llvm-ifs/binary-read-no-dynamic.test
  llvm/test/tools/llvm-ifs/binary-read-replace-soname.test
  llvm/test/tools/llvm-ifs/binary-read-soname-no-null.test
  llvm/test/tools/llvm-ifs/binary-read-soname.test
  llvm/test/tools/llvm-ifs/binary-read-syms-gnu-hash.test
  llvm/test/tools/llvm-ifs/binary-read-syms-sysv-hash.test
  llvm/test/tools/llvm-ifs/conflict-header-triple.ifs
  llvm/test/tools/llvm-ifs/conflict-header-version.ifs
  llvm/test/tools/llvm-ifs/conflict-size.ifs
  llvm/test/tools/llvm-ifs/conflict-type.ifs
  llvm/test/tools/llvm-ifs/conflict-weak.ifs
  llvm/test/tools/llvm-ifs/default-empty.ifs
  llvm/test/tools/llvm-ifs/empty1.ifs
  llvm/test/tools/llvm-ifs/empty2.ifs
  llvm/test/tools/llvm-ifs/fail-file-open.test
  llvm/test/tools/llvm-ifs/fail-file-write-windows.test
  llvm/test/tools/llvm-ifs/fail-file-write.test
  llvm/test/tools/llvm-ifs/func.ifs
  llvm/test/tools/llvm-ifs/ifs-emits-current-version.test
  llvm/test/tools/llvm-ifs/ifs-read-basic.test
  llvm/test/tools/llvm-ifs/ios-tbd.ifs
  llvm/test/tools/llvm-ifs/macos-tbd.ifs
  llvm/test/tools/llvm-ifs/object-function-size-weak-combo.ifs
  llvm/test/tools/llvm-ifs/object.ifs
  llvm/test/tools/llvm-ifs/output-target-error.test
  llvm/test/tools/llvm-ifs/preserve-dates-ifs.test
  llvm/test/tools/llvm-ifs/preserve-dates-stub.test
  llvm/test/tools/llvm-ifs/read-elf-dynsym.test
  llvm/test/tools/llvm-ifs/read-ifs-as-elf.test
  llvm/test/tools/llvm-ifs/read-ifs-as-ifs.test
  llvm/test/tools/llvm-ifs/read-ifs-with-bad-bitwidth.test
  llvm/test/tools/llvm-ifs/read-ifs-with-bad-endianness.test
  llvm/test/tools/llvm-ifs/read-unsupported-file.test
  llvm/test/tools/llvm-ifs/strip-target.test
  llvm/test/tools/llvm-ifs/strong.ifs
  llvm/test/tools/llvm-ifs/tvos-tbd.ifs
  llvm/test/tools/llvm-ifs/version-ok.ifs
  llvm/test/tools/llvm-ifs/watchos-tbd.ifs
  llvm/test/tools/llvm-ifs/weak-mismatch.ifs
  llvm/test/tools/llvm-ifs/weak.ifs
  llvm/test/tools/llvm-ifs/write-stub-no-nonlocal-symbol.test
  llvm/test/tools/llvm-ifs/write-stub.test
  llvm/tools/llvm-elfabi/CMakeLists.txt
  llvm/tools/llvm-elfabi/ErrorCollector.cpp
  llvm/tools/llvm-elfabi/ErrorCollector.h
  llvm/tools/llvm-elfabi/llvm-elfabi.cpp
  llvm/tools/llvm-ifs/CMakeLists.txt
  llvm/tools/llvm-ifs/ErrorCollector.cpp
  llvm/tools/llvm-ifs/ErrorCollector.h
  llvm/tools/llvm-ifs/llvm-ifs.cpp
  llvm/unittests/InterfaceStub/ELFYAMLTest.cpp
  llvm/utils/gn/secondary/llvm/test/BUILD.gn
  llvm/utils/gn/secondary/llvm/tools/llvm-elfabi/BUILD.gn

Index: llvm/utils/gn/secondary/llvm/tools/llvm-elfabi/BUILD.gn
===
--- llvm/utils/gn/secondary/llvm/tools/llvm-elfabi/BUILD.gn
+++ /dev/null
@@ -1,12 +0,0 @@
-executable("llvm-elfabi") {
-  deps = [
-"//llvm/lib/InterfaceStub",
-"//llvm/lib/Object",
-"//llvm/lib/Support",
-"//llvm/lib/TextAPI",
-  ]
-  sources = [
-"ErrorCollector.cpp",
-"llvm-elfabi.cpp",
-  ]
-}
Index: llvm/utils/gn/secondary/llvm/test/BUILD.gn
===
--- llvm/utils/gn/secondary/llvm/test/BUILD.gn
+++ llvm/utils/gn/secondary/llvm/test/BUILD.gn
@@ -246,7 +246,6 @@
 "//llvm/tools/llvm-dis",
 "//llvm/tools/llvm-dwarfdump",
 "//llvm/tools/llvm-dwp",
-"//llvm/tools/llvm-elfabi",
 "//llvm/tools/llvm-exegesis",
 "//llvm/tools/llvm-extract",
 "//llvm/tools/llvm-gsymutil:llvm-gsymutil",
Index: llvm/unittests/InterfaceStub/ELFYAMLTest.cpp
===
--- llvm/unittests/InterfaceStub/ELFYAMLTest.cpp
+++ llvm/unittests/InterfaceStub/ELFYAMLTest.cpp
@@

[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] 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] 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] D36022: [analyzer] Add handle misuse analysis to MagentaHandleChecker

2017-07-28 Thread Haowei Wu via Phabricator via cfe-commits

haowei created this revision.
Herald added a subscriber: xazax.hun.

This commits add actual code for analyzing magenta handle misuse issues to 
MagentaHandleChecker, which is introduced in https://reviews.llvm.org/D35968. 
It supports magenta syscalls that acquires/release/use handle through pointers 
or values but not through arrays. The support for arrays will be added in a 
follow up commit.


https://reviews.llvm.org/D36022

Files:
  lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
  test/Analysis/mxhandle.c

Index: test/Analysis/mxhandle.c
===
--- /dev/null
+++ test/Analysis/mxhandle.c
@@ -0,0 +1,192 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=alpha.magenta.MagentaHandleChecker -analyzer-store=region -verify %s
+
+typedef __typeof__(sizeof(int)) size_t;
+typedef int mx_status_t;
+typedef __typeof__(sizeof(int)) mx_handle_t;
+typedef unsigned int uint32_t;
+#define NULL ((void *)0)
+
+#if defined(__clang__)
+#define MX_SYSCALL_PARAM_ATTR(x)   __attribute__((annotate("mx_" #x)))
+#else
+#define MX_SYSCALL_PARAM_ATTR(x)   // no-op
+#endif
+
+extern mx_status_t mx_channel_create(
+uint32_t options,
+MX_SYSCALL_PARAM_ATTR(handle_acquire) mx_handle_t* out0,
+MX_SYSCALL_PARAM_ATTR(handle_acquire) mx_handle_t* out1);
+
+extern mx_status_t mx_handle_close(
+MX_SYSCALL_PARAM_ATTR(handle_release_always) mx_handle_t handle);
+
+// Escape is the default behavior for any function take a handle as parameter
+// It should work with/without explicit annotations
+void escapeMethod01(mx_handle_t *in);
+
+void escapeMethod02(
+MX_SYSCALL_PARAM_ATTR(handle_escape)  mx_handle_t *in);
+
+void escapeMethod03(mx_handle_t in);
+
+void escapeMethod04(
+MX_SYSCALL_PARAM_ATTR(handle_escape)  mx_handle_t in);
+
+// Handle should not escape when mx_handle_use is present. It should work
+// for both value type and pointer type arguments.
+void useHandle01(
+MX_SYSCALL_PARAM_ATTR(handle_use) mx_handle_t handle);
+
+void useHandle02(
+MX_SYSCALL_PARAM_ATTR(handle_use) mx_handle_t *handle);
+
+// End of declaration
+
+void checkNoLeak01() {
+  mx_handle_t sa, sb;
+  mx_channel_create(0, &sa, &sb);
+  mx_handle_close(sa);
+  mx_handle_close(sb);
+}
+
+void checkNoLeak02() {
+  mx_handle_t ay[2];
+  mx_channel_create(0, &ay[0], &ay[1]);
+  mx_handle_close(ay[0]);
+  mx_handle_close(ay[1]);
+}
+
+void checkNoLeak03() {
+  mx_handle_t ay[2];
+  mx_channel_create(0, &ay[0], &ay[1]);
+  for (int i = 0; i < 2; i++) {
+mx_handle_close(ay[i]);
+  }
+}
+
+mx_handle_t checkNoLeak04() {
+  mx_handle_t sa, sb;
+  mx_channel_create(0, &sa, &sb);
+  mx_handle_close(sa);
+  return sb; // no warning
+}
+
+mx_handle_t checkNoLeak05(mx_handle_t *out1) {
+  mx_handle_t sa, sb;
+  mx_channel_create(0, &sa, &sb);
+  *out1 = sa;
+  return sb; // no warning
+}
+
+void checkNoLeak10() {
+  mx_handle_t sa, sb;
+  if (mx_channel_create(0, &sa, &sb) < 0) {
+return;
+  }
+  mx_handle_close(sa);
+  mx_handle_close(sb);
+}
+
+void checkNoLeak12(int tag) {
+  mx_handle_t sa, sb;
+  if (mx_channel_create(0, &sa, &sb) < 0) {
+return;
+  }
+  if (tag) {
+escapeMethod01(&sa);
+escapeMethod01(&sb);
+  }
+  mx_handle_close(sa);
+  mx_handle_close(sb);
+}
+
+void checkNoLeak13(int tag) {
+  mx_handle_t sa, sb;
+  if (mx_channel_create(0, &sa, &sb) < 0) {
+return;
+  }
+  if (tag) {
+escapeMethod02(&sa);
+escapeMethod02(&sb);
+  }
+  mx_handle_close(sa);
+  mx_handle_close(sb);
+}
+
+void checkNoLeak14(int tag) {
+  mx_handle_t sa, sb;
+  if (mx_channel_create(0, &sa, &sb) < 0) {
+return;
+  }
+  if (tag) {
+escapeMethod03(sa);
+escapeMethod03(sb);
+  }
+  mx_handle_close(sa);
+  mx_handle_close(sb);
+}
+
+void checkNoLeak15(int tag) {
+  mx_handle_t sa, sb;
+  if (mx_channel_create(0, &sa, &sb) < 0) {
+return;
+  }
+  if (tag) {
+escapeMethod04(sa);
+escapeMethod04(sb);
+  }
+  mx_handle_close(sa);
+  mx_handle_close(sb);
+}
+
+void checkLeak01() {
+  mx_handle_t sa, sb;
+  mx_channel_create(0, &sa, &sb);
+} // expected-warning {{Potential leak of handle}}
+
+
+void checkLeak02(int tag) {
+  mx_handle_t sa, sb;
+  mx_channel_create(0, &sa, &sb);
+  if (tag) {
+mx_handle_close(sa);
+  }
+  mx_handle_close(sb); // expected-warning {{Potential leak of handle}}
+}
+
+void checkLeak07() {
+  mx_handle_t sa, sb;
+  mx_channel_create(0, &sa, &sb);
+
+  useHandle01(sa);
+  mx_handle_close(sb); // expected-warning {{Potential leak of handle}}
+}
+
+void checkLeak08() {
+  mx_handle_t sa, sb;
+  mx_channel_create(0, &sa, &sb);
+
+  useHandle02(&sa);
+  mx_handle_close(sb); // expected-warning {{Potential leak of handle}}
+}
+
+void checkDoubleRelease01(int tag) {
+  mx_handle_t sa, sb;
+  mx_channel_create(0, &sa, &sb);
+  if (tag) {
+mx_handle_close(sa);
+  }
+  mx_handle_close(sa); // expected-warning {{Releasing a previously released handle}}
+  mx_handle_close(sb);
+}
+
+void checkUseAfterFree01(int tag) {
+  mx_handle_t sa, sb;
+  mx_c

[PATCH] D36023: [analyzer] Add array support for MagentaHandleChecker

2017-07-28 Thread Haowei Wu via Phabricator via cfe-commits

haowei created this revision.
Herald added a subscriber: xazax.hun.

This commit adds support for syscalls that acquire/release handles in an array 
for MagentaHandleChecker introduced in https://reviews.llvm.org/D35968 and 
https://reviews.llvm.org/D36022.

Most magenta handle related syscalls will take a pointer to a local mx_handle_t 
variable for handle acquisition and take a value of a local mx_handle variable 
for handle release. A good example would be:

  mx_status_t mx_channel_create(uint32_t options,
mx_handle_t* out0, mx_handle_t* out1);

and

  mx_status_t mx_handle_close(mx_handle_t handle);

However, there are two exceptions, syscall

  mx_status_t mx_channel_read(mx_handle_t handle, uint32_t options,
  void* bytes, mx_handle_t* handles,
  uint32_t num_bytes, uint32_t num_handles,
  uint32_t* actual_bytes, uint32_t* actual_handles);

Will read(acquire) "num_handles" of  handles and save them to the array pointed 
to by "handles". The actual number of acquired handles will be saved to the 
variable pointed to by "actual_handles".

And syscall

  mx_status_t mx_channel_write(mx_handle_t handle, uint32_t options,
   void* bytes, uint32_t num_bytes,
   mx_handle_t* handles, uint32_t num_handles)

Will release "num_handles" of handles in array "handles".

This patch adds support to handle acquire/release through arrays so these two 
syscalls can be processed by this checker.


https://reviews.llvm.org/D36023

Files:
  lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
  test/Analysis/mxhandle.c

Index: test/Analysis/mxhandle.c
===
--- test/Analysis/mxhandle.c
+++ test/Analysis/mxhandle.c
@@ -20,6 +20,24 @@
 extern mx_status_t mx_handle_close(
 MX_SYSCALL_PARAM_ATTR(handle_release_always) mx_handle_t handle);
 
+extern mx_status_t mx_channel_read(
+MX_SYSCALL_PARAM_ATTR(handle_use) mx_handle_t handle,
+uint32_t options,
+void* bytes,
+mx_handle_t* handles,
+uint32_t num_bytes,
+uint32_t num_handles,
+uint32_t* actual_bytes,
+uint32_t* actual_handles);
+
+extern mx_status_t mx_channel_write(
+MX_SYSCALL_PARAM_ATTR(handle_use) mx_handle_t handle,
+uint32_t options,
+const void* bytes,
+uint32_t num_bytes,
+const mx_handle_t* handles,
+uint32_t num_handles);
+
 // Escape is the default behavior for any function take a handle as parameter
 // It should work with/without explicit annotations
 void escapeMethod01(mx_handle_t *in);
@@ -78,6 +96,44 @@
   return sb; // no warning
 }
 
+void checkNoLeak06(mx_handle_t handle) {
+  mx_handle_t handlebuf[4];
+  uint32_t hcount;
+  mx_channel_read(handle, 0, NULL, handlebuf, 0, 4, 0, &hcount);
+  for (int i = 0; i < hcount; i++) {
+mx_handle_close(handlebuf[i]);
+  }
+}
+
+void checkNoLeak07(mx_handle_t handle, uint32_t hcount) {
+  mx_handle_t handlebuf[6];
+  mx_channel_read(handle, 0, NULL, handlebuf, 0, hcount, 0, &hcount);
+  for (int i = 0; i < hcount; i++) {
+mx_handle_close(handlebuf[i]);
+  }
+}
+
+void checkNoLeak08(mx_handle_t handle) {
+  mx_handle_t handlebuf[4];
+  uint32_t hcount;
+  mx_channel_read(handle, 0, NULL, handlebuf, 0, 4, 0, &hcount);
+  if (mx_channel_write(handle, 0, NULL, 0, handlebuf, hcount) < 0) {
+for (int i = 0; i < hcount; i++) {
+  mx_handle_close(handlebuf[i]);
+}
+  }
+}
+
+void checkNoLeak09(mx_handle_t handle, uint32_t hcount) {
+  mx_handle_t handlebuf[6];
+  mx_channel_read(handle, 0, NULL, handlebuf, 0, hcount, 0, &hcount);
+  if (mx_channel_write(handle, 0, NULL, 0, handlebuf, hcount) < 0) {
+for (int i = 0; i < hcount; i++) {
+  mx_handle_close(handlebuf[i]);
+}
+  }
+}
+
 void checkNoLeak10() {
   mx_handle_t sa, sb;
   if (mx_channel_create(0, &sa, &sb) < 0) {
@@ -87,6 +143,18 @@
   mx_handle_close(sb);
 }
 
+void checkNoLeak11(mx_handle_t handle, uint32_t hcount) {
+  mx_handle_t handlebuf[6];
+  mx_status_t r = mx_channel_read(handle, 0, NULL,
+  handlebuf, 0, hcount, 0, &hcount);
+  if (r < 0) {
+return;
+  }
+  for (int i = 0; i < hcount; i++) {
+mx_handle_close(handlebuf[i]);
+  }
+}
+
 void checkNoLeak12(int tag) {
   mx_handle_t sa, sb;
   if (mx_channel_create(0, &sa, &sb) < 0) {
@@ -154,6 +222,52 @@
   mx_handle_close(sb); // expected-warning {{Potential leak of handle}}
 }
 
+void checkLeak03(mx_handle_t handle) {
+  mx_handle_t handlebuf[4];
+  uint32_t hcount;
+  mx_status_t r = mx_channel_read(handle, 0, NULL, handlebuf, 0, 4, 0, &hcount);
+  if (r < 0) {
+return;
+  }
+  for (int i = 0; i < hcount -1; i++) {
+mx_handle_close(handlebuf[i]);
+  }
+} // expected-warning {{Potential leak of handle}}
+
+void checkLeak04(mx_handle_t handle) {
+  mx_handle_t handlebuf[3];
+  uint32_t hcount;
+  mx_status_t r = mx_channel_read(handle, 0, NULL, handleb

[PATCH] D36024: [analyzer] Improved bug reporting in MagentaHandleChecker

2017-07-28 Thread Haowei Wu via Phabricator via cfe-commits

haowei created this revision.
Herald added a subscriber: xazax.hun.

This commit improves the bug reporting of MagentaHandleChecker introduced in 
https://reviews.llvm.org/D35968 , https://reviews.llvm.org/D36022 and 
https://reviews.llvm.org/D36023.

After this commit, the allocation and release sites of the handle that causes a 
bug will be marked in the generated bug report.  If the handle is declared as a 
local variable, the naming of the handle will also be marked in the generated 
bug report as well.


https://reviews.llvm.org/D36024

Files:
  lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
  test/Analysis/mxhandle.c

Index: test/Analysis/mxhandle.c
===
--- test/Analysis/mxhandle.c
+++ test/Analysis/mxhandle.c
@@ -210,16 +210,16 @@
 void checkLeak01() {
   mx_handle_t sa, sb;
   mx_channel_create(0, &sa, &sb);
-} // expected-warning {{Potential leak of handle}}
+} // expected-warning 2 {{Potential leak of handle pointed to by}}
 
 
 void checkLeak02(int tag) {
   mx_handle_t sa, sb;
   mx_channel_create(0, &sa, &sb);
   if (tag) {
 mx_handle_close(sa);
   }
-  mx_handle_close(sb); // expected-warning {{Potential leak of handle}}
+  mx_handle_close(sb); // expected-warning {{Potential leak of handle pointed to by 'sa'}}
 }
 
 void checkLeak03(mx_handle_t handle) {
@@ -273,24 +273,24 @@
   mx_channel_create(0, &sa, &sb);
 
   useHandle01(sa);
-  mx_handle_close(sb); // expected-warning {{Potential leak of handle}}
+  mx_handle_close(sb); // expected-warning {{Potential leak of handle pointed to by 'sa'}}
 }
 
 void checkLeak08() {
   mx_handle_t sa, sb;
   mx_channel_create(0, &sa, &sb);
 
   useHandle02(&sa);
-  mx_handle_close(sb); // expected-warning {{Potential leak of handle}}
+  mx_handle_close(sb); // expected-warning {{Potential leak of handle pointed to by 'sa'}}
 }
 
 void checkDoubleRelease01(int tag) {
   mx_handle_t sa, sb;
   mx_channel_create(0, &sa, &sb);
   if (tag) {
 mx_handle_close(sa);
   }
-  mx_handle_close(sa); // expected-warning {{Releasing a previously released handle}}
+  mx_handle_close(sa); // expected-warning {{Releasing a previously released handle pointed to by 'sa'}}
   mx_handle_close(sb);
 }
 
@@ -300,7 +300,27 @@
   if (tag) {
 mx_handle_close(sa);
   }
-  useHandle01(sa); // expected-warning {{Using a previously released handle}}
+  useHandle01(sa); // expected-warning {{Using a previously released handle pointed to by 'sa'}}
   mx_handle_close(sa);
   mx_handle_close(sb);
 }
+
+void checkSuppressWarning01() MX_SYSCALL_PARAM_ATTR(suppress_warning) {
+  mx_handle_t sa, sb;
+  if (mx_channel_create(0, &sa, &sb) < 0) {
+return;
+  }
+  mx_handle_close(sa); // Should not report any bugs here
+}
+
+void checkSuppressWarning02() {
+  mx_handle_t sa, sb;
+  if (mx_channel_create(0, &sa, &sb) < 0) {
+return;
+  }
+  mx_handle_close(sa); // Should not report any bugs here
+}
+
+void checkSuppressWarning03() MX_SYSCALL_PARAM_ATTR(suppress_warning) {
+  checkSuppressWarning02();
+}
Index: lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
+++ lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
@@ -235,6 +235,7 @@
 static const char *HANDLE_TYPE_NAME = "mx_handle_t";
 static const char *SYSCALL_RETURN_TYPE_NAME = "mx_status_t";
 static const int MAX_HANDLE_IN_ARRAY = 64;
+typedef std::pair AllocInfo;
 
 class MagentaHandleChecker
 : public Checker &Type,
  StringRef Msg) const;
   // Utility functions
+  AllocInfo getAllocationSite(const ExplodedNode *N, SymbolRef Sym,
+  CheckerContext &Ctx) const;
   // Generate function spec info based on inline annotations in declaration
   bool generateSpecForFuncionDecl(const FunctionDecl *FuncDecl) const;
   // Extract magenta related annotation string from declarations
@@ -331,12 +334,70 @@
 }
 return false;
   }
+
+  bool shouldReport(CheckerContext &Ctx) const;
+};
+
+class MagentaBugVisitor : public BugReporterVisitorImpl {
+private:
+  SymbolRef Sym;
+
+public:
+  MagentaBugVisitor(SymbolRef sym) : Sym(sym) {}
+  void Profile(llvm::FoldingSetNodeID &ID) const { ID.AddPointer(Sym); }
+  std::shared_ptr VisitNode(const ExplodedNode *N,
+ const ExplodedNode *PrevN,
+ BugReporterContext &BRC,
+ BugReport &BR);
 };
 } // end anonymous namespace
 
 // Handle -> HandleState map
 REGISTER_MAP_WITH_PROGRAMSTATE(HStateMap, SymbolRef, HandleState)
 
+std::shared_ptr
+MagentaBugVisitor::VisitNode(const ExplodedNode *N, const ExplodedNode *PrevN,
+ BugReporterContext &BRC, BugReport &BR) {
+  ProgramStateRef State = N->getState();
+  ProgramStateRef StatePref = PrevN->getState();
+  const HandleState *HSCur

[PATCH] D36022: [analyzer] Add handle misuse analysis to MagentaHandleChecker

2017-08-01 Thread Haowei Wu via Phabricator via cfe-commits

haowei updated this revision to Diff 109237.
haowei added a comment.

Add 1 line fix for the constraint on allocated handle in function 
allocateSingleHandle at line 647


https://reviews.llvm.org/D36022

Files:
  lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
  test/Analysis/mxhandle.c

Index: test/Analysis/mxhandle.c
===
--- /dev/null
+++ test/Analysis/mxhandle.c
@@ -0,0 +1,192 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=alpha.magenta.MagentaHandleChecker -analyzer-store=region -verify %s
+
+typedef __typeof__(sizeof(int)) size_t;
+typedef int mx_status_t;
+typedef __typeof__(sizeof(int)) mx_handle_t;
+typedef unsigned int uint32_t;
+#define NULL ((void *)0)
+
+#if defined(__clang__)
+#define MX_SYSCALL_PARAM_ATTR(x)   __attribute__((annotate("mx_" #x)))
+#else
+#define MX_SYSCALL_PARAM_ATTR(x)   // no-op
+#endif
+
+extern mx_status_t mx_channel_create(
+uint32_t options,
+MX_SYSCALL_PARAM_ATTR(handle_acquire) mx_handle_t* out0,
+MX_SYSCALL_PARAM_ATTR(handle_acquire) mx_handle_t* out1);
+
+extern mx_status_t mx_handle_close(
+MX_SYSCALL_PARAM_ATTR(handle_release_always) mx_handle_t handle);
+
+// Escape is the default behavior for any function take a handle as parameter
+// It should work with/without explicit annotations
+void escapeMethod01(mx_handle_t *in);
+
+void escapeMethod02(
+MX_SYSCALL_PARAM_ATTR(handle_escape)  mx_handle_t *in);
+
+void escapeMethod03(mx_handle_t in);
+
+void escapeMethod04(
+MX_SYSCALL_PARAM_ATTR(handle_escape)  mx_handle_t in);
+
+// Handle should not escape when mx_handle_use is present. It should work
+// for both value type and pointer type arguments.
+void useHandle01(
+MX_SYSCALL_PARAM_ATTR(handle_use) mx_handle_t handle);
+
+void useHandle02(
+MX_SYSCALL_PARAM_ATTR(handle_use) mx_handle_t *handle);
+
+// End of declaration
+
+void checkNoLeak01() {
+  mx_handle_t sa, sb;
+  mx_channel_create(0, &sa, &sb);
+  mx_handle_close(sa);
+  mx_handle_close(sb);
+}
+
+void checkNoLeak02() {
+  mx_handle_t ay[2];
+  mx_channel_create(0, &ay[0], &ay[1]);
+  mx_handle_close(ay[0]);
+  mx_handle_close(ay[1]);
+}
+
+void checkNoLeak03() {
+  mx_handle_t ay[2];
+  mx_channel_create(0, &ay[0], &ay[1]);
+  for (int i = 0; i < 2; i++) {
+mx_handle_close(ay[i]);
+  }
+}
+
+mx_handle_t checkNoLeak04() {
+  mx_handle_t sa, sb;
+  mx_channel_create(0, &sa, &sb);
+  mx_handle_close(sa);
+  return sb; // no warning
+}
+
+mx_handle_t checkNoLeak05(mx_handle_t *out1) {
+  mx_handle_t sa, sb;
+  mx_channel_create(0, &sa, &sb);
+  *out1 = sa;
+  return sb; // no warning
+}
+
+void checkNoLeak10() {
+  mx_handle_t sa, sb;
+  if (mx_channel_create(0, &sa, &sb) < 0) {
+return;
+  }
+  mx_handle_close(sa);
+  mx_handle_close(sb);
+}
+
+void checkNoLeak12(int tag) {
+  mx_handle_t sa, sb;
+  if (mx_channel_create(0, &sa, &sb) < 0) {
+return;
+  }
+  if (tag) {
+escapeMethod01(&sa);
+escapeMethod01(&sb);
+  }
+  mx_handle_close(sa);
+  mx_handle_close(sb);
+}
+
+void checkNoLeak13(int tag) {
+  mx_handle_t sa, sb;
+  if (mx_channel_create(0, &sa, &sb) < 0) {
+return;
+  }
+  if (tag) {
+escapeMethod02(&sa);
+escapeMethod02(&sb);
+  }
+  mx_handle_close(sa);
+  mx_handle_close(sb);
+}
+
+void checkNoLeak14(int tag) {
+  mx_handle_t sa, sb;
+  if (mx_channel_create(0, &sa, &sb) < 0) {
+return;
+  }
+  if (tag) {
+escapeMethod03(sa);
+escapeMethod03(sb);
+  }
+  mx_handle_close(sa);
+  mx_handle_close(sb);
+}
+
+void checkNoLeak15(int tag) {
+  mx_handle_t sa, sb;
+  if (mx_channel_create(0, &sa, &sb) < 0) {
+return;
+  }
+  if (tag) {
+escapeMethod04(sa);
+escapeMethod04(sb);
+  }
+  mx_handle_close(sa);
+  mx_handle_close(sb);
+}
+
+void checkLeak01() {
+  mx_handle_t sa, sb;
+  mx_channel_create(0, &sa, &sb);
+} // expected-warning {{Potential leak of handle}}
+
+
+void checkLeak02(int tag) {
+  mx_handle_t sa, sb;
+  mx_channel_create(0, &sa, &sb);
+  if (tag) {
+mx_handle_close(sa);
+  }
+  mx_handle_close(sb); // expected-warning {{Potential leak of handle}}
+}
+
+void checkLeak07() {
+  mx_handle_t sa, sb;
+  mx_channel_create(0, &sa, &sb);
+
+  useHandle01(sa);
+  mx_handle_close(sb); // expected-warning {{Potential leak of handle}}
+}
+
+void checkLeak08() {
+  mx_handle_t sa, sb;
+  mx_channel_create(0, &sa, &sb);
+
+  useHandle02(&sa);
+  mx_handle_close(sb); // expected-warning {{Potential leak of handle}}
+}
+
+void checkDoubleRelease01(int tag) {
+  mx_handle_t sa, sb;
+  mx_channel_create(0, &sa, &sb);
+  if (tag) {
+mx_handle_close(sa);
+  }
+  mx_handle_close(sa); // expected-warning {{Releasing a previously released handle}}
+  mx_handle_close(sb);
+}
+
+void checkUseAfterFree01(int tag) {
+  mx_handle_t sa, sb;
+  mx_channel_create(0, &sa, &sb);
+  if (tag) {
+mx_handle_close(sa);
+  }
+  useHandle01(sa); // expected-warning {{Using a previously released handle}}
+  mx_handle_close(sa);
+  mx_handle_close(sb);
+}
Index: lib/StaticAnalyzer/

[PATCH] D36251: [analyzer] Suppress warning when bug path contains noreturn function or return from main in MagentaHandleChecker

2017-08-02 Thread Haowei Wu via Phabricator via cfe-commits

haowei created this revision.
Herald added a subscriber: xazax.hun.

This patch will suppress handle leak warnings if the path of a bug reported by 
MagentaHandleChecker will reach a no return function or will reach the end of 
main function. As these two scenarios mean program crash and the leaked handle 
will be recycled by OS, there is no point to report these bugs.


https://reviews.llvm.org/D36251

Files:
  lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
  test/Analysis/mxhandle.c


Index: test/Analysis/mxhandle.c
===
--- test/Analysis/mxhandle.c
+++ test/Analysis/mxhandle.c
@@ -58,7 +58,20 @@
 void useHandle02(
 MX_SYSCALL_PARAM_ATTR(handle_use) mx_handle_t *handle);
 
+void noReturnFunc() __attribute__((__noreturn__));
+
+int leakingFunc(int argc, char* argv[]) {
+  mx_handle_t sa, sb;
+  mx_channel_create(0, &sa, &sb);
+  return 1;
+}
+
 // End of declaration
+int main(int argc, char* argv[]) {
+  if (argc == 2)
+return leakingFunc(argc, argv); // Should not report any bugs here
+  return 0;
+}
 
 void checkNoLeak01() {
   mx_handle_t sa, sb;
@@ -207,6 +220,14 @@
   mx_handle_close(sb);
 }
 
+void checkNoLeak16() {
+  mx_handle_t sa, sb;
+  if (mx_channel_create(0, &sa, &sb) < 0) {
+return;
+  }
+  noReturnFunc(); // Should not report any bugs here
+}
+
 void checkLeak01() {
   mx_handle_t sa, sb;
   mx_channel_create(0, &sa, &sb);
Index: lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
+++ lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
@@ -239,7 +239,7 @@
 
 class MagentaHandleChecker
 : public Checker {
+ check::PostCall, check::PreStmt> {
   std::unique_ptr LeakBugType;
   std::unique_ptr DoubleReleaseBugType;
   std::unique_ptr UseAfterFreeBugType;
@@ -255,6 +255,7 @@
   void checkPostCall(const CallEvent &Call, CheckerContext &Ctx) const;
   void checkDeadSymbols(SymbolReaper &SymReaper, CheckerContext &Ctx) const;
   bool evalCall(const CallExpr *CE, CheckerContext &Ctx) const;
+  void checkPreStmt(const ReturnStmt *RS, CheckerContext &Ctx) const;
   ProgramStateRef checkPointerEscape(ProgramStateRef State,
  const InvalidatedSymbols &Escaped,
  const CallEvent *Call,
@@ -402,6 +403,7 @@
   // Initialize the bug types.
   LeakBugType.reset(
   new BugType(this, "MX handle leak", "Magenta Handle Error"));
+  LeakBugType->setSuppressOnSink(true);
   DoubleReleaseBugType.reset(
   new BugType(this, "MX handle double release", "Magenta Handle Error"));
   UseAfterFreeBugType.reset(
@@ -478,6 +480,23 @@
   }
 }
 
+void MagentaHandleChecker::checkPreStmt(const ReturnStmt *RS,
+CheckerContext &Ctx) const {
+  ProgramStateRef State = Ctx.getState();
+  const StackFrameContext *SFCtx = Ctx.getStackFrame();
+  if (!SFCtx || !SFCtx->inTopFrame())
+return;
+  const FunctionDecl *FD = dyn_cast_or_null(SFCtx->getDecl());
+  if (!FD)
+return;
+  const IdentifierInfo *II = FD->getIdentifier();
+  if (!II)
+return;
+
+  if (II->isStr("main"))
+Ctx.generateSink(State, Ctx.getPredecessor());
+}
+
 ProgramStateRef MagentaHandleChecker::checkPointerEscape(
 ProgramStateRef State, const InvalidatedSymbols &Escaped,
 const CallEvent *Call, PointerEscapeKind Kind) const {


Index: test/Analysis/mxhandle.c
===
--- test/Analysis/mxhandle.c
+++ test/Analysis/mxhandle.c
@@ -58,7 +58,20 @@
 void useHandle02(
 MX_SYSCALL_PARAM_ATTR(handle_use) mx_handle_t *handle);
 
+void noReturnFunc() __attribute__((__noreturn__));
+
+int leakingFunc(int argc, char* argv[]) {
+  mx_handle_t sa, sb;
+  mx_channel_create(0, &sa, &sb);
+  return 1;
+}
+
 // End of declaration
+int main(int argc, char* argv[]) {
+  if (argc == 2)
+return leakingFunc(argc, argv); // Should not report any bugs here
+  return 0;
+}
 
 void checkNoLeak01() {
   mx_handle_t sa, sb;
@@ -207,6 +220,14 @@
   mx_handle_close(sb);
 }
 
+void checkNoLeak16() {
+  mx_handle_t sa, sb;
+  if (mx_channel_create(0, &sa, &sb) < 0) {
+return;
+  }
+  noReturnFunc(); // Should not report any bugs here
+}
+
 void checkLeak01() {
   mx_handle_t sa, sb;
   mx_channel_create(0, &sa, &sb);
Index: lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
+++ lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
@@ -239,7 +239,7 @@
 
 class MagentaHandleChecker
 : public Checker {
+ check::PostCall, check::PreStmt> {
   std::unique_ptr LeakBugType;
   std::unique_ptr DoubleReleaseBugType;
   std::unique_ptr UseAfterFreeBugType;
@@ -255,6 +255,7 @@
   void checkPostCall(const CallEvent &Call, Checke

[PATCH] D36475: [analyzer] Add "create_sink" annotation support to MagentaHandleChecker

2017-08-08 Thread Haowei Wu via Phabricator via cfe-commits

haowei created this revision.
Herald added a subscriber: xazax.hun.

This patch adds "mx_create_sink" annotation support to MagentaHandleChecker to 
address the false positives found in Magenta unit tests. After this patch, when 
a call to a function contains this annotation, MagentaHandleChecker will create 
a sink node which will suppress the handle leaks warnings if the leak is 
post-dominated by this function (similar to a noreturn function).

The target problem it tries to solve can be illustrated in following example:

  static bool handle_info_test(void) {
  BEGIN_TEST;
  
  mx_handle_t event;
  ASSERT_EQ(mx_event_create(0u, &event), 0, "");
  mx_handle_t duped;
  mx_status_t status = mx_handle_duplicate(event, MX_RIGHT_SAME_RIGHTS, 
&duped);
  ASSERT_EQ(status, MX_OK, "");
  // 
  }

Unlike the "assert" keyword in C++, the ASSERT_EQ macro will not terminate the 
execution of the unit test program (in other words, it will not invoke a 
noreturn function), instead it will return false and the error will be recorded 
by the unit test runner. Therefore, before this patch, the MagentaHandleChecker 
will report handle leaks on these assertion failures as the function reaches 
return and symbol that contains the acquired handles are acquired. These 
reports are not helpful as assertion failures in unit tests mean test failures. 
With the help of this patch, we add a call to a function with "mx_create_sink" 
annotation in the failure branch in definition "ASSERT_EQ". In this case, the 
MagentaHandleChecker will create a sink node in each assertion failure and 
suppress the warnings if the leaks are post-dominated by assertion failures.


https://reviews.llvm.org/D36475

Files:
  lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
  test/Analysis/mxhandle.c

Index: test/Analysis/mxhandle.c
===
--- test/Analysis/mxhandle.c
+++ test/Analysis/mxhandle.c
@@ -60,6 +60,8 @@
 
 void noReturnFunc() __attribute__((__noreturn__));
 
+void sinkFunc() MX_SYSCALL_PARAM_ATTR(create_sink);
+
 int leakingFunc(int argc, char* argv[]) {
   mx_handle_t sa, sb;
   mx_channel_create(0, &sa, &sb);
@@ -228,6 +230,14 @@
   noReturnFunc(); // Should not report any bugs here
 }
 
+void checkNoLeak17() {
+  mx_handle_t sa, sb;
+  if (mx_channel_create(0, &sa, &sb) < 0) {
+return;
+  }
+  sinkFunc(); // Should not report any bugs here
+}
+
 void checkLeak01() {
   mx_handle_t sa, sb;
   mx_channel_create(0, &sa, &sb);
Index: lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
+++ lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
@@ -123,7 +123,9 @@
   UNPROCESSED_FUNC,
   // When a bug is found in function with this flag, do not report this bug
   // Used to suppress known false positives.
-  DONOTREPORT_FUNC
+  DONOTREPORT_FUNC,
+  // When a function has 'create_sink' annotation , create a sink node.
+  SINK_FUNC
 };
 
 enum AnnotationFlag {
@@ -144,7 +146,8 @@
   // This value is not describing the possible return value of a annotated
   // function. It basically tell the checker do not report any bugs found in
   // this function. Used to suppress false positive reports.
-  DONOTREPORT
+  DONOTREPORT,
+  CREATE_SINK
 };
 
 struct ArgSpec {
@@ -416,7 +419,8 @@
{"handle_escape", ESCAPE},
{"handle_use", NOESCAPE},
{"may_fail", BIFURCATE},
-   {"suppress_warning", DONOTREPORT}};
+   {"suppress_warning", DONOTREPORT},
+   {"create_sink", CREATE_SINK}};
 
   // Hard coded FuncSpec for mx_channel_read and mx_channel_write
   // We currently don't have a clean way to annotate handles passed through
@@ -455,6 +459,10 @@
 FuncKindMap[FuncDecl] == UNPROCESSED_FUNC ||
 FuncKindMap[FuncDecl] == DONOTREPORT_FUNC)
   return false;
+if (FuncKindMap[FuncDecl] == SINK_FUNC) {
+  C.generateSink(C.getState(), C.getPredecessor());
+  return true;
+}
   }
   // Check if the function has annotation and has already been processed before
   if (FuncDeclMap.count(FuncDecl))
@@ -545,6 +553,11 @@
 FuncKindMap[FD] = DONOTREPORT_FUNC;
 return false;
   }
+  if (FS.RetAction == CREATE_SINK) {
+FuncKindMap[FD] = SINK_FUNC;
+Ctx.generateSink(Ctx.getState(), Ctx.getPredecessor());
+return true;
+  }
   SmallVector invalidateSVal;
   ProgramStateRef State = Ctx.getState();
   ASTContext &ASTCtx = State->getStateManager().getContext();
@@ -1035,13 +1048,14 @@
 HasValidAnnotation = true;
   }
   // Return type is not mx_status_t but has annotation other than
-  // SYMBOLIC|DONOTREPORT Consider it as an error
+  // SYMBOLIC|DONOTREPORT|CREATE_SINK Consider it as an error
   if (RetType.getAsString().find(SYSCALL_RETURN_TYPE_NAME) &&
-  (FS.RetAction != SYMBOLIC && FS.RetActi

[PATCH] D36251: [analyzer] Suppress warning when bug path contains noreturn function or return from main in MagentaHandleChecker

2017-08-10 Thread Haowei Wu via Phabricator via cfe-commits

haowei added inline comments.



Comment at: lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp:483-498
+void MagentaHandleChecker::checkPreStmt(const ReturnStmt *RS,
+CheckerContext &Ctx) const {
+  ProgramStateRef State = Ctx.getState();
+  const StackFrameContext *SFCtx = Ctx.getStackFrame();
+  if (!SFCtx || !SFCtx->inTopFrame())
+return;
+  const FunctionDecl *FD = dyn_cast_or_null(SFCtx->getDecl());

NoQ wrote:
> xazax.hun wrote:
> > NoQ wrote:
> > > I think the analyzer core should do this. This code already has a global 
> > > effect on the analysis - it's enough for one checker to generate the 
> > > sink. Additionally, there's also the CFG-based variant of 
> > > suppress-on-sink, which would need to be extended to support this as well 
> > > - this other variant kicks in when the analysis was interrupted before 
> > > reaching the sink (see D35673 and D35674).
> > Do we want to do this unconditionally? Are all of the resources cleaned up 
> > on all of the supported OSes, or maybe for some leak issues it still makes 
> > sense to warn in these cases? Or we simply favor false negatives over false 
> > positives in this case (might make sense)? 
> We could add a flag to `setSuppressOnSink()` as an orthogonal change if it 
> turns out that we need it; i'm not aware of any stuff that badly needs to be 
> cleaned up before normal program termination in the existing checkers.
I also think this should be done in a separate checker like 
NoReturnFunctionChecker or within the analyzer as some other resource leak 
checkers might need this. I am also thinking D36475 should be in a separate 
checker as well. That annotation support really helps us a lot in analyzing 
unit test code and it might be useful for others if someone run into similar 
situation like us. But I cannot decide if we should use the annotate attribute 
or define a new attribute just for the analyzer.


https://reviews.llvm.org/D36251



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

[PATCH] D90275: [clang][IR] Add support for leaf attribute

2020-12-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 rG7c0e3a77bc43: [clang][IR] Add support for leaf attribute 
(authored by gulfem, committed by haowei).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90275

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/attr-leaf.c
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Sema/attr-leaf.c
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/Attributes.td
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/AsmParser/LLToken.h
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Transforms/Utils/CodeExtractor.cpp
  llvm/test/Bitcode/attributes.ll

Index: llvm/test/Bitcode/attributes.ll
===
--- llvm/test/Bitcode/attributes.ll
+++ llvm/test/Bitcode/attributes.ll
@@ -404,6 +404,12 @@
   ret void
 }
 
+; CHECK; define void @f69() #43
+define void @f70() nocallback
+{
+  ret void
+}
+
 ; CHECK: attributes #0 = { noreturn }
 ; CHECK: attributes #1 = { nounwind }
 ; CHECK: attributes #2 = { readnone }
@@ -446,4 +452,5 @@
 ; CHECK: attributes #39 = { sanitize_memtag }
 ; CHECK: attributes #40 = { null_pointer_is_valid }
 ; CHECK: attributes #41 = { mustprogress }
+; CHECK: attributes #42 = { nocallback }
 ; CHECK: attributes #[[NOBUILTIN]] = { nobuiltin }
Index: llvm/lib/Transforms/Utils/CodeExtractor.cpp
===
--- llvm/lib/Transforms/Utils/CodeExtractor.cpp
+++ llvm/lib/Transforms/Utils/CodeExtractor.cpp
@@ -946,6 +946,7 @@
   case Attribute::NoRecurse:
   case Attribute::InlineHint:
   case Attribute::MinSize:
+  case Attribute::NoCallback:
   case Attribute::NoDuplicate:
   case Attribute::NoFree:
   case Attribute::NoImplicitFloat:
Index: llvm/lib/IR/Verifier.cpp
===
--- llvm/lib/IR/Verifier.cpp
+++ llvm/lib/IR/Verifier.cpp
@@ -1597,6 +1597,7 @@
   case Attribute::NoReturn:
   case Attribute::NoSync:
   case Attribute::WillReturn:
+  case Attribute::NoCallback:
   case Attribute::NoCfCheck:
   case Attribute::NoUnwind:
   case Attribute::NoInline:
Index: llvm/lib/IR/Attributes.cpp
===
--- llvm/lib/IR/Attributes.cpp
+++ llvm/lib/IR/Attributes.cpp
@@ -371,6 +371,8 @@
 return "noalias";
   if (hasAttribute(Attribute::NoBuiltin))
 return "nobuiltin";
+  if (hasAttribute(Attribute::NoCallback))
+return "nocallback";
   if (hasAttribute(Attribute::NoCapture))
 return "nocapture";
   if (hasAttribute(Attribute::NoDuplicate))
Index: llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
===
--- llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
+++ llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
@@ -646,6 +646,8 @@
 return bitc::ATTR_KIND_NO_ALIAS;
   case Attribute::NoBuiltin:
 return bitc::ATTR_KIND_NO_BUILTIN;
+  case Attribute::NoCallback:
+return bitc::ATTR_KIND_NO_CALLBACK;
   case Attribute::NoCapture:
 return bitc::ATTR_KIND_NO_CAPTURE;
   case Attribute::NoDuplicate:
Index: llvm/lib/Bitcode/Reader/BitcodeReader.cpp
===
--- llvm/lib/Bitcode/Reader/BitcodeReader.cpp
+++ llvm/lib/Bitcode/Reader/BitcodeReader.cpp
@@ -1433,6 +1433,8 @@
 return Attribute::NoAlias;
   case bitc::ATTR_KIND_NO_BUILTIN:
 return Attribute::NoBuiltin;
+  case bitc::ATTR_KIND_NO_CALLBACK:
+return Attribute::NoCallback;
   case bitc::ATTR_KIND_NO_CAPTURE:
 return Attribute::NoCapture;
   case bitc::ATTR_KIND_NO_DUPLICATE:
Index: llvm/lib/AsmParser/LLToken.h
===
--- llvm/lib/AsmParser/LLToken.h
+++ llvm/lib/AsmParser/LLToken.h
@@ -200,6 +200,7 @@
   kw_noalias,
   kw_noundef,
   kw_nobuiltin,
+  kw_nocallback,
   kw_nocapture,
   kw_noduplicate,
   kw_nofree,
Index: llvm/lib/AsmParser/LLParser.cpp
===
--- llvm/lib/AsmParser/LLParser.cpp
+++ llvm/lib/AsmParser/LLParser.cpp
@@ -1353,6 +1353,9 @@
   break;
 case lltok::kw_naked: B.addAttribute(Attribute::Naked); break;
 case lltok::kw_nobuiltin: B.addAttribute(Attribute::NoBuiltin); break;
+case lltok::kw_nocallback:
+  B.addAttribute(Attribute::NoCallback);
+  break;
 case lltok::kw_noduplicate: B.addAttribute(Attribute::NoDuplicate); break;
 case lltok::kw_nofree: B.addAttribute(Attribute::NoFree); break;

[PATCH] D90362: scan-build supprot relative 'file' in cdb.

2020-11-11 Thread Haowei Wu via Phabricator via cfe-commits

haowei closed this revision.
haowei added a comment.

Landed in 
https://github.com/llvm/llvm-project/commit/d93287cac89fd50a105ac4a59c079884b8e53e49


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90362

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

[PATCH] D66324: clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM

2020-11-13 Thread Haowei Wu via Phabricator via cfe-commits

haowei added a comment.

In D66324#2394687 , @lebedev.ri wrote:

> In D66324#2336555 , @lebedev.ri 
> wrote:
>
>> In D66324#2336186 , @phosek wrote:
>>
>>> I apologize for the late response, I somehow missed the earlier responses. 
>>> We have successfully used this feature in Fuchsia and found it useful, but 
>>> I agree that the issues raised need to be addressed. Unfortunately 
>>> @paulkirth is no longer working on this project. I hope that someone from 
>>> our team can take a look but it might take a few weeks. If you prefer, we 
>>> could revert this change and then reland an improved version in the future?
>>
>> I would very much prefer *NOT* not revert if someone is going to step up to 
>> work on these problems soon (within next 4 weeks?).
>>
>> That being said, in light of that bug, my original doubts about the 
>> underlying data type (a novel `MD_misexpect`,
>> with structure different from `MD_prof`) have reappeared with double 
>> strength. I really think they should share underlying type.
>
> I'll be posting a revert soon.

Sorry for the late reply. Since @paulkirth is no longer working on this 
project. I can take over it and start working on it full time beginning next 
week. It would take me some time to get familiar with the code and work on the 
fix though. If you still prefer reverting this change, we can work on an 
improved version and reland it in the future.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D66324

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

[PATCH] D91223: Support struct annotations in FuchsiaHandleChecker.

2020-11-21 Thread Haowei Wu via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG914f6c4ff8a4: [StaticAnalyzer] Support struct annotations in 
FuchsiaHandleChecker (authored by haowei).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D91223?vs=306778&id=306890#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91223

Files:
  clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
  clang/test/Analysis/fuchsia_handle.cpp

Index: clang/test/Analysis/fuchsia_handle.cpp
===
--- clang/test/Analysis/fuchsia_handle.cpp
+++ clang/test/Analysis/fuchsia_handle.cpp
@@ -9,9 +9,9 @@
 #define ZX_HANDLE_INVALID 0
 
 #if defined(__clang__)
-#define ZX_HANDLE_ACQUIRE  __attribute__((acquire_handle("Fuchsia")))
-#define ZX_HANDLE_RELEASE  __attribute__((release_handle("Fuchsia")))
-#define ZX_HANDLE_USE  __attribute__((use_handle("Fuchsia")))
+#define ZX_HANDLE_ACQUIRE __attribute__((acquire_handle("Fuchsia")))
+#define ZX_HANDLE_RELEASE __attribute__((release_handle("Fuchsia")))
+#define ZX_HANDLE_USE __attribute__((use_handle("Fuchsia")))
 #else
 #define ZX_HANDLE_ACQUIRE
 #define ZX_HANDLE_RELEASE
@@ -31,7 +31,7 @@
 
 void escape1(zx_handle_t *in);
 void escape2(zx_handle_t in);
-void (*escape3)(zx_handle_t) = escape2; 
+void (*escape3)(zx_handle_t) = escape2;
 
 void use1(const zx_handle_t *in ZX_HANDLE_USE);
 void use2(zx_handle_t in ZX_HANDLE_USE);
@@ -82,8 +82,8 @@
   // expected-note-re@-3 {{Handle allocated through {{(2nd|3rd)}} parameter}}
   if (status == 0) { // expected-note {{Assuming 'status' is equal to 0}}
  // expected-note@-1 {{Taking true branch}}
-return; // expected-warning {{Potential leak of handle}}
-// expected-note@-1 {{Potential leak of handle}}
+return;  // expected-warning {{Potential leak of handle}}
+ // expected-note@-1 {{Potential leak of handle}}
   }
   __builtin_trap();
 }
@@ -138,7 +138,7 @@
 return;
   zx_handle_close(sa);
   zx_handle_close(sb);
-} 
+}
 
 void checkLeak01(int tag) {
   zx_handle_t sa, sb;
@@ -158,7 +158,7 @@
   zx_handle_t sa = return_handle(); // expected-note {{Function 'return_handle' returns an open handle}}
   (void)sa;
 } // expected-note {{Potential leak of handle}}
-  // expected-warning@-1 {{Potential leak of handle}}
+// expected-warning@-1 {{Potential leak of handle}}
 
 void checkReportLeakOnOnePath(int tag) {
   zx_handle_t sa, sb;
@@ -166,26 +166,26 @@
 return;   // expected-note@-1 {{Assuming the condition is false}}
   // expected-note@-2 {{Taking false branch}}
   zx_handle_close(sb);
-  switch(tag) { // expected-note {{Control jumps to the 'default' case at line}} 
-case 0:
-  use2(sa);
-  return;
-case 1:
-  use2(sa);
-  return;
-case 2:
-  use2(sa);
-  return;
-case 3:
-  use2(sa);
-  return;
-case 4:
-  use2(sa);
-  return;
-default:
-  use2(sa);
-  return; // expected-warning {{Potential leak of handle}}
-  // expected-note@-1 {{Potential leak of handle}}
+  switch (tag) { // expected-note {{Control jumps to the 'default' case at line}}
+  case 0:
+use2(sa);
+return;
+  case 1:
+use2(sa);
+return;
+  case 2:
+use2(sa);
+return;
+  case 3:
+use2(sa);
+return;
+  case 4:
+use2(sa);
+return;
+  default:
+use2(sa);
+return; // expected-warning {{Potential leak of handle}}
+// expected-note@-1 {{Potential leak of handle}}
   }
 }
 
@@ -193,7 +193,7 @@
   zx_handle_t sa, sb;
   zx_channel_create(0, &sa, &sb);
   // expected-note@-1 {{Handle allocated through 2nd parameter}}
-  if (tag) // expected-note {{Assuming 'tag' is not equal to 0}}
+  if (tag)   // expected-note {{Assuming 'tag' is not equal to 0}}
 zx_handle_close(sa); // expected-note {{Handle released through 1st parameter}}
   // expected-note@-2 {{Taking true branch}}
   zx_handle_close(sa); // expected-warning {{Releasing a previously released handle}}
@@ -211,12 +211,12 @@
   if (tag) {
 // expected-note@-1 {{Assuming 'tag' is not equal to 0}}
 zx_handle_close(sa); // expected-note {{Handle released through 1st parameter}}
-use1(&sa); // expected-warning {{Using a previously released handle}}
+use1(&sa);   // expected-warning {{Using a previously released handle}}
 // expected-note@-1 {{Using a previously released handle}}
   }
   // expected-note@-6 {{Assuming 'tag' is 0}}
   zx_handle_close(sb); // expected-note {{Handle released through 1st parameter}}
-  use2(sb); // expected-warning {{Using a previously released handle}}
+  use2(sb);// expected-warning {{Using a previously released handle}}
   // expected-note@-1 {{Us

[PATCH] D91223: Support struct annotations in FuchsiaHandleChecker.

2020-11-24 Thread Haowei Wu via Phabricator via cfe-commits

haowei added a comment.

In D91223#2415137 , @MaskRay wrote:

> @haowei https://llvm.org/docs/DeveloperPolicy.html#commit-messages Please use 
> git commit --amend --author for future patches where the majority of the work 
> is done by others.

Thanks for your remind.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91223

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

[PATCH] D92444: [CMake][Fuchsia] Install llvm-elfabi

2020-12-01 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


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92444

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

[PATCH] D91902: [analyzer] Ignore annotations if func is inlined.

2020-12-07 Thread Haowei Wu via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG3ce78f54edcf: [analyzer] Ignore annotations if func is 
inlined. (authored by aabbaabb, committed by haowei).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D91902?vs=309122&id=309968#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91902

Files:
  clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
  clang/test/Analysis/fuchsia_handle.cpp


Index: clang/test/Analysis/fuchsia_handle.cpp
===
--- clang/test/Analysis/fuchsia_handle.cpp
+++ clang/test/Analysis/fuchsia_handle.cpp
@@ -315,6 +315,45 @@
   // expected-note@-1 {{Potential leak of handle}}
 }
 
+// Assume this function's declaration that has the release annotation is in one
+// header file while its implementation is in another file. We have to annotate
+// the declaration because it might be used outside the TU.
+// We also want to make sure it is okay to call the function within the same 
TU.
+zx_status_t test_release_handle(zx_handle_t handle ZX_HANDLE_RELEASE) {
+  return zx_handle_close(handle);
+}
+
+void checkReleaseImplementedFunc() {
+  zx_handle_t a, b;
+  zx_channel_create(0, &a, &b);
+  zx_handle_close(a);
+  test_release_handle(b);
+}
+
+void use_handle(zx_handle_t handle) {
+  // Do nothing.
+}
+
+void test_call_by_value() {
+  zx_handle_t a, b;
+  zx_channel_create(0, &a, &b);
+  zx_handle_close(a);
+  use_handle(b);
+  zx_handle_close(b);
+}
+
+void test_call_by_value_leak() {
+  zx_handle_t a, b;
+  zx_channel_create(0, &a, &b); // expected-note {{Handle allocated through 
3rd parameter}}
+  zx_handle_close(a);
+  // Here we are passing handle b as integer value to a function that could be
+  // analyzed by the analyzer, thus the handle should not be considered 
escaped.
+  // After the function 'use_handle', handle b is still tracked and should be
+  // reported leaked.
+  use_handle(b);
+} // expected-warning {{Potential leak of handle}}
+// expected-note@-1 {{Potential leak of handle}}
+
 // RAII
 
 template 
Index: clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
@@ -331,11 +331,6 @@
   return;
 }
   }
-  if (!hasFuchsiaAttr(PVD) &&
-  PVD->getType()->isIntegerType()) {
-// Working around integer by-value escapes.
-State = State->set(Handle, HandleState::getEscaped());
-  }
 }
   }
   C.addTransition(State);
@@ -347,6 +342,10 @@
   if (!FuncDecl)
 return;
 
+  // If we analyzed the function body, then ignore the annotations.
+  if (C.wasInlined)
+return;
+
   ProgramStateRef State = C.getState();
 
   std::vector> Notes;
@@ -417,6 +416,14 @@
 });
 State = State->set(
 Handle, HandleState::getMaybeAllocated(ResultSymbol));
+  } else if (!hasFuchsiaAttr(PVD) &&
+ PVD->getType()->isIntegerType()) {
+// Working around integer by-value escapes.
+// The by-value escape would not be captured in checkPointerEscape.
+// If the function was not analyzed (otherwise wasInlined should be
+// true) and there is no annotation on the handle, we assume the handle
+// is escaped.
+State = State->set(Handle, HandleState::getEscaped());
   }
 }
   }


Index: clang/test/Analysis/fuchsia_handle.cpp
===
--- clang/test/Analysis/fuchsia_handle.cpp
+++ clang/test/Analysis/fuchsia_handle.cpp
@@ -315,6 +315,45 @@
   // expected-note@-1 {{Potential leak of handle}}
 }
 
+// Assume this function's declaration that has the release annotation is in one
+// header file while its implementation is in another file. We have to annotate
+// the declaration because it might be used outside the TU.
+// We also want to make sure it is okay to call the function within the same TU.
+zx_status_t test_release_handle(zx_handle_t handle ZX_HANDLE_RELEASE) {
+  return zx_handle_close(handle);
+}
+
+void checkReleaseImplementedFunc() {
+  zx_handle_t a, b;
+  zx_channel_create(0, &a, &b);
+  zx_handle_close(a);
+  test_release_handle(b);
+}
+
+void use_handle(zx_handle_t handle) {
+  // Do nothing.
+}
+
+void test_call_by_value() {
+  zx_handle_t a, b;
+  zx_channel_create(0, &a, &b);
+  zx_handle_close(a);
+  use_handle(b);
+  zx_handle_close(b);
+}
+
+void test_call_by_value_leak() {
+  zx_handle_t a, b;
+  zx_channel_create(0, &a, &b); // expected-note {{Handle allocated through 3rd parameter}}
+  zx_handle_close(a);
+  // Here we are passing handle b as integer value to a function that could be
+  // analyzed by the analyz

[PATCH] D102693: Do not create LLVM IR `constant`s for objects with dynamic initialisation

2021-05-24 Thread Haowei Wu via Phabricator via cfe-commits

haowei added a comment.

This CL breaks our mac builders as well. Could you either fix the test or 
revert the change please?

Error message:

   TEST 'Clang :: CodeGenCXX/const-dynamic-init.cpp' FAILED 

  Script:
  --
  : 'RUN: at line 1';   /opt/staging/llvm_build/bin/clang -cc1 
-internal-isystem /opt/staging/llvm_build/lib/clang/13.0.0/include 
-nostdsysteminc -triple x86_64-apple-darwin19.6.0 -emit-llvm -o - 
/opt/llvm-project/clang/test/CodeGenCXX/const-dynamic-init.cpp | 
/opt/staging/llvm_build/bin/FileCheck 
/opt/llvm-project/clang/test/CodeGenCXX/const-dynamic-init.cpp
  --
  Exit Code: 2
  
  Command Output (stderr):
  --
  /opt/llvm-project/clang/test/CodeGenCXX/const-dynamic-init.cpp:3:24: error: 
argument to 'section' attribute is not valid for this target: mach-o section 
specifier requires a segment and section separated by a comma
  __attribute__((section("A")))
 ^
  /opt/llvm-project/clang/test/CodeGenCXX/const-dynamic-init.cpp:9:24: error: 
argument to 'section' attribute is not valid for this target: mach-o section 
specifier requires a segment and section separated by a comma
  __attribute__((section("B")))
 ^
  /opt/llvm-project/clang/test/CodeGenCXX/const-dynamic-init.cpp:15:24: error: 
argument to 'section' attribute is not valid for this target: mach-o section 
specifier requires a segment and section separated by a comma
  __attribute__((section("C")))
 ^
  /opt/llvm-project/clang/test/CodeGenCXX/const-dynamic-init.cpp:19:24: error: 
argument to 'section' attribute is not valid for this target: mach-o section 
specifier requires a segment and section separated by a comma
  __attribute__((section("D")))
 ^
  /opt/llvm-project/clang/test/CodeGenCXX/const-dynamic-init.cpp:23:24: error: 
argument to 'section' attribute is not valid for this target: mach-o section 
specifier requires a segment and section separated by a comma
  __attribute__((section("E")))
 ^
  5 errors generated.
  FileCheck error: '' is empty.
  FileCheck command line:  /opt/staging/llvm_build/bin/FileCheck 
/opt/llvm-project/clang/test/CodeGenCXX/const-dynamic-init.cpp
  
  --
  
  


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102693

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

[PATCH] D103218: [Fuchsia][CMake] Add missing include path.

2021-05-26 Thread Haowei Wu via Phabricator via cfe-commits

haowei created this revision.
haowei added reviewers: phosek, mcgrathr, leonardchan, gulfem.
Herald added subscribers: cryptoad, mgorny.
haowei requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch adds include path for missing header files from "sync". This patch 
also fixes the build failures caused by scudo introduced in D103200 
.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D103218

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
@@ -145,7 +145,7 @@
   set(FUCHSIA_x86_64-unknown-fuchsia_NAME x64)
   set(FUCHSIA_riscv64-unknown-fuchsia_NAME riscv64)
   foreach(target 
i386-unknown-fuchsia;x86_64-unknown-fuchsia;aarch64-unknown-fuchsia;riscv64-unknown-fuchsia)
-set(FUCHSIA_${target}_COMPILER_FLAGS "--target=${target} 
-I${FUCHSIA_SDK}/pkg/fdio/include")
+set(FUCHSIA_${target}_COMPILER_FLAGS "--target=${target} 
-I${FUCHSIA_SDK}/pkg/sync/include -I${FUCHSIA_SDK}/pkg/fdio/include")
 set(FUCHSIA_${target}_LINKER_FLAGS 
"-L${FUCHSIA_SDK}/arch/${FUCHSIA_${target}_NAME}/lib")
 set(FUCHSIA_${target}_SYSROOT 
"${FUCHSIA_SDK}/arch/${FUCHSIA_${target}_NAME}/sysroot")
   endforeach()


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -145,7 +145,7 @@
   set(FUCHSIA_x86_64-unknown-fuchsia_NAME x64)
   set(FUCHSIA_riscv64-unknown-fuchsia_NAME riscv64)
   foreach(target i386-unknown-fuchsia;x86_64-unknown-fuchsia;aarch64-unknown-fuchsia;riscv64-unknown-fuchsia)
-set(FUCHSIA_${target}_COMPILER_FLAGS "--target=${target} -I${FUCHSIA_SDK}/pkg/fdio/include")
+set(FUCHSIA_${target}_COMPILER_FLAGS "--target=${target} -I${FUCHSIA_SDK}/pkg/sync/include -I${FUCHSIA_SDK}/pkg/fdio/include")
 set(FUCHSIA_${target}_LINKER_FLAGS "-L${FUCHSIA_SDK}/arch/${FUCHSIA_${target}_NAME}/lib")
 set(FUCHSIA_${target}_SYSROOT "${FUCHSIA_SDK}/arch/${FUCHSIA_${target}_NAME}/sysroot")
   endforeach()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103218: [Fuchsia][CMake] Add missing include path.

2021-05-26 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 rG0ce58c52d50b: [Fuchsia][CMake] Add missing include path. 
(authored by haowei).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103218

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
@@ -145,7 +145,7 @@
   set(FUCHSIA_x86_64-unknown-fuchsia_NAME x64)
   set(FUCHSIA_riscv64-unknown-fuchsia_NAME riscv64)
   foreach(target 
i386-unknown-fuchsia;x86_64-unknown-fuchsia;aarch64-unknown-fuchsia;riscv64-unknown-fuchsia)
-set(FUCHSIA_${target}_COMPILER_FLAGS "--target=${target} 
-I${FUCHSIA_SDK}/pkg/fdio/include")
+set(FUCHSIA_${target}_COMPILER_FLAGS "--target=${target} 
-I${FUCHSIA_SDK}/pkg/sync/include -I${FUCHSIA_SDK}/pkg/fdio/include")
 set(FUCHSIA_${target}_LINKER_FLAGS 
"-L${FUCHSIA_SDK}/arch/${FUCHSIA_${target}_NAME}/lib")
 set(FUCHSIA_${target}_SYSROOT 
"${FUCHSIA_SDK}/arch/${FUCHSIA_${target}_NAME}/sysroot")
   endforeach()


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -145,7 +145,7 @@
   set(FUCHSIA_x86_64-unknown-fuchsia_NAME x64)
   set(FUCHSIA_riscv64-unknown-fuchsia_NAME riscv64)
   foreach(target i386-unknown-fuchsia;x86_64-unknown-fuchsia;aarch64-unknown-fuchsia;riscv64-unknown-fuchsia)
-set(FUCHSIA_${target}_COMPILER_FLAGS "--target=${target} -I${FUCHSIA_SDK}/pkg/fdio/include")
+set(FUCHSIA_${target}_COMPILER_FLAGS "--target=${target} -I${FUCHSIA_SDK}/pkg/sync/include -I${FUCHSIA_SDK}/pkg/fdio/include")
 set(FUCHSIA_${target}_LINKER_FLAGS "-L${FUCHSIA_SDK}/arch/${FUCHSIA_${target}_NAME}/lib")
 set(FUCHSIA_${target}_SYSROOT "${FUCHSIA_SDK}/arch/${FUCHSIA_${target}_NAME}/sysroot")
   endforeach()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D94251: [scan-build-py] Update scan-build-py to allow outputing as SARIF.

2021-02-07 Thread Haowei Wu via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGd72859ffa237: [scan-build-py] Update scan-build-py to allow 
outputing as SARIF (authored by Daniel Hwang , 
committed by haowei).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94251

Files:
  clang/tools/scan-build-py/libscanbuild/analyze.py
  clang/tools/scan-build-py/libscanbuild/arguments.py
  clang/tools/scan-build-py/libscanbuild/report.py
  clang/tools/scan-build-py/tests/unit/test_analyze.py
  clang/tools/scan-build-py/tests/unit/test_report.py

Index: clang/tools/scan-build-py/tests/unit/test_report.py
===
--- clang/tools/scan-build-py/tests/unit/test_report.py
+++ clang/tools/scan-build-py/tests/unit/test_report.py
@@ -3,6 +3,7 @@
 # See https://llvm.org/LICENSE.txt for license information.
 # SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 
+import json
 import libear
 import libscanbuild.report as sut
 import unittest
@@ -145,3 +146,516 @@
 def test_empty(self):
 self.assertEqual(
 sut.commonprefix([]), '')
+
+class MergeSarifTest(unittest.TestCase):
+
+def test_merging_sarif(self):
+sarif1 = {
+'$schema': 'https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.json',
+'runs': [
+{
+'artifacts': [
+{
+'length': 100,
+'location': {
+'uri': '//clang/tools/scan-build-py/tests/unit/test_report.py'
+},
+'mimeType': 'text/plain',
+'roles': [
+'resultFile'
+]
+}
+],
+'columnKind': 'unicodeCodePoints',
+'results': [
+{
+'codeFlows': [
+{
+'threadFlows': [
+{
+'locations': [
+{
+'importance': 'important',
+'location': {
+'message': {
+'text': 'test message 1'
+},
+'physicalLocation': {
+'artifactLocation': {
+'index': 0,
+'uri': '//clang/tools/scan-build-py/tests/unit/test_report.py'
+},
+'region': {
+'endColumn': 5,
+'startColumn': 1,
+'startLine': 2
+}
+}
+}
+}
+]
+}
+]
+}
+]
+},
+{
+'codeFlows': [
+{
+'threadFlows': [
+{
+'locations': [
+{
+'importance': 'important',
+'location': {
+'message': {
+'text': 'test message 2'
+},
+'physicalLocation': {
+'artifactLocation': {
+'index': 0,
+

[PATCH] D110668: [clang-cl] Accept `#pragma warning(disable : N)` for some N

2021-09-29 Thread Haowei Wu via Phabricator via cfe-commits

haowei added a comment.

We are seeing a series of weird errors in our windows clang builder after this 
patch landed:

  [1/828] Building CXX object 
compiler-rt\lib\sanitizer_common\CMakeFiles\RTSanitizerCommonNoTermination.x86_64.dir\sanitizer_solaris.cpp.obj
  FAILED: 
compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.x86_64.dir/sanitizer_solaris.cpp.obj
 
  C:\b\s\w\ir\x\w\staging\llvm_build\.\bin\clang-cl.exe  /nologo -TP 
-DHAVE_RPC_XDR_H=0 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS 
-D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-D__func__=__FUNCTION__ 
-IC:\b\s\w\ir\x\w\llvm-project\compiler-rt\lib\sanitizer_common\.. /DWIN32 
/D_WINDOWS   /Zc:inline /Zc:__cplusplus /Zc:strictStrings /Oi /Zc:rvalueCast 
/Brepro /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 /MD /Z7 /O2 /Ob1/Zc:threadSafeInit- -Wthread-safety 
-Wthread-safety-reference -Wthread-safety-beta /Z7 -UNDEBUG /showIncludes 
/Focompiler-rt\lib\sanitizer_common\CMakeFiles\RTSanitizerCommonNoTermination.x86_64.dir\sanitizer_solaris.cpp.obj
 
/Fdcompiler-rt\lib\sanitizer_common\CMakeFiles\RTSanitizerCommonNoTermination.x86_64.dir\
 -c 
C:\b\s\w\ir\x\w\llvm-project\compiler-rt\lib\sanitizer_common\sanitizer_solaris.cpp
  error: unknown argument: '-wd4141'
  error: unknown argument: '-wd4146'
  error: unknown argument: '-wd4244'
  error: unknown argument: '-wd4267'
  error: unknown argument: '-wd4291'
  error: unknown argument: '-wd4351'
  error: unknown argument: '-wd4456'
  error: unknown argument: '-wd4457'
  error: unknown argument: '-wd4458'
  error: unknown argument: '-wd4459'
  error: unknown argument: '-wd4503'
  error: unknown argument: '-wd4624'
  error: unknown argument: '-wd4722'
  error: unknown argument: '-wd4127'
  error: unknown argument: '-wd4512'
  error: unknown argument: '-wd4505'
  error: unknown argument: '-wd4610'
  error: unknown argument: '-wd4510'
  error: unknown argument: '-wd4702'
  fatal error: too many errors emitted, stopping now [-ferror-limit=]

Failed build task is 
https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-windows-x64/b8834735134024529217/overview
 . The error disappeared when I revert this change on our builder. Do you have 
an idea why this change caused the build issue?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110668

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

[PATCH] D96389: [analyzer] Update static analyzer to be support sarif-html

2021-02-10 Thread Haowei Wu via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG2407eb08a574: [analyzer] Update static analyzer to be 
support sarif-html (authored by Daniel Hwang , 
committed by haowei).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96389

Files:
  clang/include/clang/Driver/Options.td
  clang/include/clang/StaticAnalyzer/Core/Analyses.def
  clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp


Index: clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
===
--- clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
+++ clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
@@ -176,6 +176,16 @@
   CTU);
 }
 
+void ento::createSarifHTMLDiagnosticConsumer(
+  PathDiagnosticConsumerOptions DiagOpts, PathDiagnosticConsumers &C,
+const std::string &sarif_file, const Preprocessor &PP,
+const cross_tu::CrossTranslationUnitContext &CTU) {
+  createHTMLDiagnosticConsumer(DiagOpts, C, 
std::string(llvm::sys::path::parent_path(sarif_file)), PP, CTU);
+  createSarifDiagnosticConsumer(DiagOpts, C, sarif_file, PP, CTU);
+  createTextMinimalPathDiagnosticConsumer(std::move(DiagOpts), C, sarif_file, 
PP,
+  CTU);
+}
+
 
//===--===//
 // Report processing.
 
//===--===//
Index: clang/include/clang/StaticAnalyzer/Core/Analyses.def
===
--- clang/include/clang/StaticAnalyzer/Core/Analyses.def
+++ clang/include/clang/StaticAnalyzer/Core/Analyses.def
@@ -52,9 +52,14 @@
  "Output analysis results using HTML wrapped with Plists",
  createPlistHTMLDiagnosticConsumer)
 
-ANALYSIS_DIAGNOSTICS(SARIF, "sarif", "Output analysis results in a SARIF file",
+ANALYSIS_DIAGNOSTICS(SARIF, "sarif", "Output analysis results using SARIF",
  createSarifDiagnosticConsumer)
 
+ANALYSIS_DIAGNOSTICS(SARIF_HTML, "sarif-html",
+ "Output analysis results using both SARIF and HTML "
+ "output files",
+ createSarifHTMLDiagnosticConsumer)
+
 ANALYSIS_DIAGNOSTICS(TEXT, "text", "Text output of analysis results to stderr",
  createTextPathDiagnosticConsumer)
 
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -3667,7 +3667,7 @@
 def _all_warnings : Flag<["--"], "all-warnings">, Alias;
 def _analyzer_no_default_checks : Flag<["--"], "analyzer-no-default-checks">, 
Flags<[NoXarchOption]>;
 def _analyzer_output : JoinedOrSeparate<["--"], "analyzer-output">, 
Flags<[NoXarchOption]>,
-  HelpText<"Static analyzer report output format 
(html|plist|plist-multi-file|plist-html|sarif|text).">;
+  HelpText<"Static analyzer report output format 
(html|plist|plist-multi-file|plist-html|sarif|sarif-html|text).">;
 def _analyze : Flag<["--"], "analyze">, Flags<[NoXarchOption, CoreOption]>,
   HelpText<"Run the static analyzer">;
 def _assemble : Flag<["--"], "assemble">, Alias;


Index: clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
===
--- clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
+++ clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
@@ -176,6 +176,16 @@
   CTU);
 }
 
+void ento::createSarifHTMLDiagnosticConsumer(
+  PathDiagnosticConsumerOptions DiagOpts, PathDiagnosticConsumers &C,
+const std::string &sarif_file, const Preprocessor &PP,
+const cross_tu::CrossTranslationUnitContext &CTU) {
+  createHTMLDiagnosticConsumer(DiagOpts, C, std::string(llvm::sys::path::parent_path(sarif_file)), PP, CTU);
+  createSarifDiagnosticConsumer(DiagOpts, C, sarif_file, PP, CTU);
+  createTextMinimalPathDiagnosticConsumer(std::move(DiagOpts), C, sarif_file, PP,
+  CTU);
+}
+
 //===--===//
 // Report processing.
 //===--===//
Index: clang/include/clang/StaticAnalyzer/Core/Analyses.def
===
--- clang/include/clang/StaticAnalyzer/Core/Analyses.def
+++ clang/include/clang/StaticAnalyzer/Core/Analyses.def
@@ -52,9 +52,14 @@
  "Output analysis results using HTML wrapped with Plists",
  createPlistHTMLDiagnosticConsumer)
 
-ANALYSIS_DIAGNOSTICS(SARIF, "sarif", "Output analysis results

[PATCH] D99810: [ifs] Prepare llvm-ifs for elfabi/ifs merging.

2021-06-17 Thread Haowei Wu via Phabricator via cfe-commits

haowei marked an inline comment as done.
haowei added inline comments.



Comment at: llvm/include/llvm/InterfaceStub/ELFObjHandler.h:25
 
 namespace elfabi {
 

phosek wrote:
> Shouldn't this be in namespace `ifs`?
This was renamed to ifs in D100139.  Rename it here will need some changes in 
elfabi code, which is unnecessary (and will be deleted in D100139)



Comment at: llvm/lib/InterfaceStub/IFSStub.cpp:65
+uint8_t elfabi::convertIFSBitWidthToELF(IFSBitWidthType BitWidth) {
+  return BitWidth == IFSBitWidthType::IFS32 ? ELF::ELFCLASS32 : 
ELF::ELFCLASS64;
+}

phosek wrote:
> I'd consider using `switch` here so if someone adds a new entry to the 
> `IFSBitWidthType` enum, it gets caught by the compiler.
I changed it to switch and I added `llvm_unreachable("unkown bitwidth");` to 
cases where an unknown bitwidth or endianness is used. Please let me know if it 
is OK to do so.

The Unknown enum is reserved for ifs file that has unknown bitwidth or 
endianness field and will trigger ifs tool's early termination. So it shouldn't 
be seen when IFS library is writing an ELF file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99810

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

[PATCH] D100139: [ifs][elfabi] Merge llvm-ifs/elfabi tools

2021-06-21 Thread Haowei Wu via Phabricator via cfe-commits

haowei updated this revision to Diff 353507.
haowei marked 3 inline comments as done.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100139

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  clang/lib/Driver/ToolChains/InterfaceStubs.cpp
  clang/test/InterfaceStubs/driver-test.c
  llvm/include/llvm/InterfaceStub/ELFObjHandler.h
  llvm/include/llvm/InterfaceStub/IFSHandler.h
  llvm/include/llvm/InterfaceStub/IFSStub.h
  llvm/lib/InterfaceStub/ELFObjHandler.cpp
  llvm/lib/InterfaceStub/IFSHandler.cpp
  llvm/lib/InterfaceStub/IFSStub.cpp
  llvm/test/CMakeLists.txt
  llvm/test/tools/llvm-ifs/binary-read-add-soname.test
  llvm/test/tools/llvm-ifs/binary-read-arch.test
  llvm/test/tools/llvm-ifs/binary-read-bad-soname.test
  llvm/test/tools/llvm-ifs/binary-read-bad-vaddr.test
  llvm/test/tools/llvm-ifs/binary-read-neededlibs-bad-offset.test
  llvm/test/tools/llvm-ifs/binary-read-neededlibs.test
  llvm/test/tools/llvm-ifs/binary-read-no-dt-strsz.test
  llvm/test/tools/llvm-ifs/binary-read-no-dt-strtab.test
  llvm/test/tools/llvm-ifs/binary-read-no-dynamic.test
  llvm/test/tools/llvm-ifs/binary-read-replace-soname.test
  llvm/test/tools/llvm-ifs/binary-read-soname-no-null.test
  llvm/test/tools/llvm-ifs/binary-read-soname.test
  llvm/test/tools/llvm-ifs/binary-read-syms-gnu-hash.test
  llvm/test/tools/llvm-ifs/binary-read-syms-sysv-hash.test
  llvm/test/tools/llvm-ifs/conflict-header-triple.ifs
  llvm/test/tools/llvm-ifs/conflict-header-version.ifs
  llvm/test/tools/llvm-ifs/conflict-size.ifs
  llvm/test/tools/llvm-ifs/conflict-type.ifs
  llvm/test/tools/llvm-ifs/conflict-weak.ifs
  llvm/test/tools/llvm-ifs/default-empty.ifs
  llvm/test/tools/llvm-ifs/empty1.ifs
  llvm/test/tools/llvm-ifs/empty2.ifs
  llvm/test/tools/llvm-ifs/fail-file-open.test
  llvm/test/tools/llvm-ifs/fail-file-write-windows.test
  llvm/test/tools/llvm-ifs/fail-file-write.test
  llvm/test/tools/llvm-ifs/func.ifs
  llvm/test/tools/llvm-ifs/ifs-emits-current-version.test
  llvm/test/tools/llvm-ifs/ifs-read-basic.test
  llvm/test/tools/llvm-ifs/ios-tbd.ifs
  llvm/test/tools/llvm-ifs/macos-tbd.ifs
  llvm/test/tools/llvm-ifs/object-function-size-weak-combo.ifs
  llvm/test/tools/llvm-ifs/object.ifs
  llvm/test/tools/llvm-ifs/output-target-error.test
  llvm/test/tools/llvm-ifs/preserve-dates-ifs.test
  llvm/test/tools/llvm-ifs/preserve-dates-stub.test
  llvm/test/tools/llvm-ifs/read-elf-dynsym.test
  llvm/test/tools/llvm-ifs/read-ifs-as-elf.test
  llvm/test/tools/llvm-ifs/read-ifs-as-ifs.test
  llvm/test/tools/llvm-ifs/read-ifs-with-bad-bitwidth.test
  llvm/test/tools/llvm-ifs/read-ifs-with-bad-endianness.test
  llvm/test/tools/llvm-ifs/read-unsupported-file.test
  llvm/test/tools/llvm-ifs/strip-target.test
  llvm/test/tools/llvm-ifs/strong.ifs
  llvm/test/tools/llvm-ifs/tvos-tbd.ifs
  llvm/test/tools/llvm-ifs/version-ok.ifs
  llvm/test/tools/llvm-ifs/watchos-tbd.ifs
  llvm/test/tools/llvm-ifs/weak-mismatch.ifs
  llvm/test/tools/llvm-ifs/weak.ifs
  llvm/test/tools/llvm-ifs/write-stub-no-nonlocal-symbol.test
  llvm/test/tools/llvm-ifs/write-stub.test
  llvm/tools/llvm-elfabi/CMakeLists.txt
  llvm/tools/llvm-elfabi/ErrorCollector.cpp
  llvm/tools/llvm-elfabi/ErrorCollector.h
  llvm/tools/llvm-elfabi/llvm-elfabi.cpp
  llvm/tools/llvm-ifs/CMakeLists.txt
  llvm/tools/llvm-ifs/ErrorCollector.cpp
  llvm/tools/llvm-ifs/ErrorCollector.h
  llvm/tools/llvm-ifs/llvm-ifs.cpp
  llvm/unittests/InterfaceStub/ELFYAMLTest.cpp
  llvm/utils/gn/secondary/llvm/test/BUILD.gn
  llvm/utils/gn/secondary/llvm/tools/llvm-elfabi/BUILD.gn

Index: llvm/utils/gn/secondary/llvm/tools/llvm-elfabi/BUILD.gn
===
--- llvm/utils/gn/secondary/llvm/tools/llvm-elfabi/BUILD.gn
+++ /dev/null
@@ -1,12 +0,0 @@
-executable("llvm-elfabi") {
-  deps = [
-"//llvm/lib/InterfaceStub",
-"//llvm/lib/Object",
-"//llvm/lib/Support",
-"//llvm/lib/TextAPI",
-  ]
-  sources = [
-"ErrorCollector.cpp",
-"llvm-elfabi.cpp",
-  ]
-}
Index: llvm/utils/gn/secondary/llvm/test/BUILD.gn
===
--- llvm/utils/gn/secondary/llvm/test/BUILD.gn
+++ llvm/utils/gn/secondary/llvm/test/BUILD.gn
@@ -239,7 +239,6 @@
 "//llvm/tools/llvm-dis",
 "//llvm/tools/llvm-dwarfdump",
 "//llvm/tools/llvm-dwp",
-"//llvm/tools/llvm-elfabi",
 "//llvm/tools/llvm-exegesis",
 "//llvm/tools/llvm-extract",
 "//llvm/tools/llvm-gsymutil:llvm-gsymutil",
Index: llvm/unittests/InterfaceStub/ELFYAMLTest.cpp
===
--- llvm/unittests/InterfaceStub/ELFYAMLTest.cpp
+++ llvm/unittests/InterfaceStub/ELFYAMLTest.cpp
@@ -17,7 +17,7 @@
 
 using namespace llvm;
 using namespace llvm::ELF;
-using namespace llvm::elfabi;
+using namespace llvm::ifs;
 
 void compareByLine(StringRef LHS, StringRef RHS) {
   StringRef Line1;
Index: llvm/tools/llvm-if

[PATCH] D74436: Change clang option -ffp-model=precise to select ffp-contract=on

2021-07-30 Thread Haowei Wu via Phabricator via cfe-commits

haowei added a comment.

We are seeing float related unit tests failing in Fuchsia after this patch. 
What flags should we add to our build to match llvm's previous float point 
behavior?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74436

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

[PATCH] D74436: Change clang option -ffp-model=precise to select ffp-contract=on

2021-08-03 Thread Haowei Wu via Phabricator via cfe-commits

haowei added a comment.

Can we revert this patch please? If I understood correctly, this patch changed 
the default behavior of clang when generating code for float point arithmetic. 
After this patch `-ffp-contract` was set to on if this flag was not specified. 
In theory this makes clang use FMA instructions that should be slightly more 
efficient, but there are cases in the field that certain programs relies on the 
stable rounding behavior of float point arithmetic, and this patch broke that. 
And in fact we already seen breakages in Fuchsia, Chromium and SPEC benchmark 
suite and there might be other people seeing the same breakages but still 
working on bisecting this breaking change.

Even if this breaking change is reasonable to proceed and receive condense from 
major clang users, this patch lacks enough test coverage for codegen of float 
point arithmetic on major CPU platforms without related flag specified. Nobody 
will discover this is a default behavior breaking patch by just reading this 
patch. This should be reverted and reworked.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74436

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

[PATCH] D74436: Change clang option -ffp-model=precise to select ffp-contract=on

2021-08-04 Thread Haowei Wu via Phabricator via cfe-commits

haowei added a comment.

In D74436#2926385 , @tstellar wrote:

> Can someone file a bug for this and put release-13.0.0 in the blocks field so 
> we can track it?

Filed https://bugs.llvm.org/show_bug.cgi?id=51346 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74436

___
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] 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] 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] 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] 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-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 &F) {
   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 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] 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] 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] 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] 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] 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-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 op

[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-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-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-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 &Path) 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, sys::path::Sty

[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 &Path) 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(Wo

[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 &Path) 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 (getExist

[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 &Path) 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-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: llvm/lib/Support/VirtualFileSyste

[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-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 RUNTIME_TARGETS

[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-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] 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] 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] 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] 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&id=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: [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] 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] 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&id=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 "")
+  set(BUILTINS_${target}_CMA

[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 "-DCMAKE_OSX_DEPLOYMENT_TARGET=10.13;-DCMAKE_OSX_ARCHITE

[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: 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 
aarch64-unknow

[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-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 "")
+set(RUNTIMES

[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: llvm/cmake

[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-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&id=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 "")
+  set(RUNTIMES_${target}_CMAKE_MODULE_LINK

[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] 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 | 
/opt/s/w/ir/x/w/stagi

[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] 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.

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 
--check-prefixes=NOMCU

[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.

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] 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] 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] 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.

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] 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] 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] 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] 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] 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] 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] 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] 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 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 STRI

[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] 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] 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] 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] 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

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] 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 
-ffile-prefix-map=/b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-armv7-unknown-linux-gnueabihf-bins=

[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] 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] 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

1 2 >

1 - 100 of 151 matches

Mail list logo