[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce Realtime Sanitizer (RTSan) backend (PR #92460)
cjappl wrote: > This also breaks building the compiler-rt for older android versions, because > pthread_spinlock_t is only defined when `__ANDROID_API__` >= 24. Thanks for reporting this @glandium ! I am in the process of disabling this for android as we speak. Let me know if you see anything else fishy https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce Realtime Sanitizer (RTSan) backend (PR #92460)
cjappl wrote:
This patch I have a strong hunch fixes issue 1 in my comment above. This patch
compiles and runs on my linux container and my mac, proving it doesn't affect
compilation on those two systems.
```
diff --git a/compiler-rt/lib/rtsan/tests/CMakeLists.txt
b/compiler-rt/lib/rtsan/tests/CMakeLists.txt
index d96e538b255f..e539ebc387e0 100644
--- a/compiler-rt/lib/rtsan/tests/CMakeLists.txt
+++ b/compiler-rt/lib/rtsan/tests/CMakeLists.txt
@@ -60,7 +60,7 @@ foreach(arch ${RTSAN_TEST_ARCH})
# RtsanUnitTests "Rtsan-${arch}-Test" ${arch}
# COMPILE_DEPS ${RTSAN_UNITTEST_HEADERS}
# SOURCES ${RTSAN_INST_TEST_SOURCES} ${COMPILER_RT_GOOGLETEST_SOURCES}
- # DEPS llvm_gtest rtsan
+ # DEPS rtsan
# CFLAGS ${RTSAN_UNITTEST_CFLAGS} -fsanitize=realtime
# LINK_FLAGS ${RTSAN_UNITTEST_LINK_FLAGS} -fsanitize=realtime)
@@ -94,7 +94,6 @@ foreach(arch ${RTSAN_TEST_ARCH})
COMPILE_DEPS ${RTSAN_UNITTEST_HEADERS}
SOURCES ${RTSAN_NOINST_TEST_SOURCES}
${COMPILER_RT_GOOGLETEST_SOURCES}
-DEPS llvm_gtest
CFLAGS ${RTSAN_UNITTEST_CFLAGS}
LINK_FLAGS ${RTSAN_UNITTEST_LINK_FLAGS}
RUNTIME ${RTSAN_TEST_RUNTIME})
```
This also better matches the other sanitizers, llvm_gtest is a dependency in
llvm, anything in compiler-rt using gtest just uses the sources directly as
seen in:
```
SOURCES ${RTSAN_NOINST_TEST_SOURCES}
${COMPILER_RT_GOOGLETEST_SOURCES}
```
https://github.com/llvm/llvm-project/pull/92460
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce Realtime Sanitizer (RTSan) backend (PR #92460)
cjappl wrote: There are 3 errors I see: Mostly it's this `llvm_gtest` issue: ``` ninja: error: 'compiler-rt/lib/rtsan/tests/llvm_gtest', needed by 'compiler-rt/lib/rtsan/tests/RtsanNoInstTestObjects.rtsan_preinit.cpp.x86_64.o', missing and no known rule to make it ``` On fuchsia it is a parameter type issue: ``` /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/compiler-rt/lib/rtsan/rtsan_interceptors.cpp:55:22: error: use of undeclared identifier '__unsanitized_open'; did you mean '__unsanitized_memset'? 55 | const int result = REAL(open)(path, oflag, mode); | ^~ | __unsanitized_memset /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/compiler-rt/lib/rtsan/../interception/interception.h:241:18: note: expanded from macro 'REAL' 241 | # define REAL(x) __unsanitized_##x | ^ :138:1: note: expanded from here 138 | __unsanitized_open | ^ /usr/local/fuchsia/sdk/arch/x64/sysroot/include/zircon/sanitizer.h:34:18: note: '__unsanitized_memset' declared here 34 | __typeof(memset) __unsanitized_memset; | ^ /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/compiler-rt/lib/rtsan/rtsan_interceptors.cpp:55:33: error: cannot initialize a parameter of type 'void *' with an lvalue of type 'const char *' 55 | const int result = REAL(open)(path, oflag, mode); | ^~~~ /usr/local/fuchsia/sdk/arch/x64/sysroot/include/zircon/sanitizer.h:34:18: note: passing argument to parameter here 34 | __typeof(memset) __unsanitized_memset; | ^ /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/compiler-rt/lib/rtsan/rtsan_interceptors.cpp:69:22: error: use of undeclared identifier '__unsanitized_openat' 69 | const int result = REAL(openat)(fd, path, oflag, mode); | ^ /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/compiler-rt/lib/rtsan/../interception/interception.h:241:18: note: expanded from macro 'REAL' 241 | # define REAL(x) __unsanitized_##x | ^ :141:1: note: expanded from here 141 | __unsanitized_openat | ^ /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/compiler-rt/lib/rtsan/rtsan_interceptors.cpp:77:22: error: use of undeclared identifier '__unsanitized_creat' 77 | const int result = REAL(creat)(path, mode); | ^ /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/compiler-rt/lib/rtsan/../interception/interception.h:241:18: note: expanded from macro 'REAL' 241 | # define REAL(x) __unsanitized_##x | ^ :144:1: note: expanded from here 144 | __unsanitized_creat | ^ Step 6 (build) failure: build (failure) ... ``` On windows (which I think we should just disable support for, for now: ``` C:\b\slave\sanitizer-windows\llvm-project\compiler-rt\lib\rtsan\rtsan_context.cpp(19): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory ``` Working to see if I can fix the llvm_gtest issue right now. I would love advice on Fuchsia and disabling rtsan for windows. https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce Realtime Sanitizer (RTSan) backend (PR #92460)
cjappl wrote: > I can reproduce and will debug in an hour. Thanks for the help @vitalybuka , I am looking into this as well, but very grateful for more experienced eyes on the matter too. I'll keep you posted here if I find anything https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce Realtime Sanitizer (RTSan) backend (PR #92460)
cjappl wrote: Also, just as a heads up, neither of the authors have commit access as we are new to LLVM. If this is OK to go in we will need help with that step. https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce Realtime Sanitizer (RTSan) backend (PR #92460)
@@ -0,0 +1,516 @@ +//===--- rtsan_test_interceptors.cpp - Realtime Sanitizer ---*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===--===// cjappl wrote: Seems reasonable to convert these to lit! I propose leaving this for this commit, and we convert them in the near future. Specifically this next commit will introduce the -fsanitize=realtime flag, and come with a bunch of the lit tests that we have written, so it will be easier to convert them once that infrastructure has landed. One clarifying question, for when that work is done: Should we have a lit test for every intereceptor? The reason we did it in gtest unit tests is that adding a new interceptor's test is a few lines, as opposed to a brand new file with the lit boilerplate. This makes it easy to make sure that every interceptor does what we think it does. We worried about the "cost" of the new file for every interceptor. In our demo branch, as we have it laid out, the lit tests test on the full end-to-end system level, while these tests actually hit every interceptor. https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce Realtime Sanitizer (RTSan) backend (PR #92460)
cjappl wrote: Pinging reviewers @vitalybuka @zygoloid State of the review: 1 approval from MaskRay, all open comments have been addressed. Looking for more feedback, or more approval or a merge if this is looking good. Thanks much! :) https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce Realtime Sanitizer (RTSan) backend (PR #92460)
@@ -0,0 +1,67 @@ +import os + +# Setup config name. +config.name = "RTSAN" + config.name_suffix + +# Setup source root. +config.test_source_root = os.path.dirname(__file__) + +# Setup default compiler flags use with -frtsan-instrument option. +clang_rtsan_cflags = ["-frtsan-instrument", config.target_cflags] + +# If libc++ was used to build rtsan libraries, libc++ is needed. Fix applied +# to Linux only since -rpath may not be portable. This can be extended to +# other platforms. +if config.libcxx_used == "1" and config.host_os == "Linux": +clang_rtsan_cflags = clang_rtsan_cflags + ( +["-L%s -lc++ -Wl,-rpath=%s" % (config.llvm_shlib_dir, config.llvm_shlib_dir)] cjappl wrote: Removed! https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce Realtime Sanitizer (RTSan) backend (PR #92460)
cjappl wrote: > clangDriver changes are usually the last. The expectation is that if > -fsanitize=realtime does not return an error, there should be some basic > functionality. Thanks for the feedback @MaskRay . I removed all of the clang components of this review, leaving only the compiler-rt components. We will re-introduce the clang changes in a future review. In the meantime, I commented out compilation of our unit tests that required the -fsanitize flag, let me know if you'd prefer to see them removed until later. These unit tests are paired with the code introduced here, so I think at least by subject it makes sense to introduce them here, even if they are briefly not being compiled. https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce Realtime Sanitizer (RTSan) backend (PR #92460)
cjappl wrote: Pinging reviewers @vitalybuka @MaskRay @zygoloid All the comments on this PR have been addressed, looking for more feedback, or approval/merge if we are getting close! Thanks in advance :) https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce Realtime Sanitizer (RTSan) backend (PR #92460)
cjappl wrote: Bumped the branch to resolve the conflict in config-ix.cmake https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce Realtime Sanitizer (RTSan) backend (PR #92460)
cjappl wrote: Pinging reviewers, after we had more conversations on the overall structure and usefulness of RTSan, and it was approved. @zygoloid @vitalybuka @MaskRay Details of the aforementioned discussion are around here in the discourse thread: https://discourse.llvm.org/t/rfc-nolock-and-noalloc-attributes/76837/82 https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce Realtime Sanitizer (RTSan) backend (PR #92460)
@@ -1509,6 +1511,11 @@ void DarwinClang::AddLinkRuntimeLibArgs(const ArgList , AddLinkSanitizerLibArgs(Args, CmdArgs, "asan"); } cjappl wrote: Thanks for catching this! Added a few basic ones that test that the flag is supported, and that some known sanitizer incompatibilities are blocked https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lldb] [llvm] Remove some `try_compile` CMake checks for compiler flags (PR #92953)
cjappl wrote: Thanks for your help! You were correct that cc was pointing to gcc. This is fixed when I updated my machine to use my known clang as the default compiler. For future archeologists, this meant (from [this answer](https://askubuntu.com/questions/1198087/how-to-set-clang-9-as-the-default-c-compiler-on-ubuntu-19-10)) ``` sudo update-alternatives --install /usr/bin/c++ c++ /usr/bin/clang++ 60 sudo update-alternatives --install /usr/bin/cc cc /usr/bin/clang 60 ``` https://github.com/llvm/llvm-project/pull/92953 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lldb] [llvm] Remove some `try_compile` CMake checks for compiler flags (PR #92953)
cjappl wrote: Hi @Endilll I did a git bisect that pointed to this change as the one blocking my compilation on an Ubuntu docker image with clang 14.0 The error I see: ``` CMake Error at /test_radsan/llvm-project/compiler-rt/cmake/Modules/CheckSectionExists.cmake:72 (message): cc: error: unrecognized command-line option '-Wcovered-switch-default'; did you mean '-Wno-switch-default'? cc: error: unrecognized command-line option '-Wstring-conversion'; did you mean '-Wsign-conversion'? Call Stack (most recent call first): /test_radsan/llvm-project/compiler-rt/lib/builtins/CMakeLists.txt:923 (check_section_exists) ``` My compiler info, printed from CMake: ``` CMAKE_CXX_COMPILER_VERSION: 14.0.0 CMAKE_CXX_COMPILER_ID: Clang ``` More info from the command line: ``` $ clang --version Ubuntu clang version 14.0.0-1ubuntu1.1 Target: aarch64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin $ uname -a Linux 18728bf50582 6.5.11-linuxkit #1 SMP PREEMPT Mon Dec 4 11:30:00 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux $ cmake --version cmake version 3.22.1 ``` Let me know what other information may be helpful, or if this is user error. It seems from your godbolt links above, clang 5.0 and higher should work, so I'm surprised that 14.0 is dying in this environment https://github.com/llvm/llvm-project/pull/92953 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce Realtime Sanitizer (RTSan) backend (PR #92460)
https://github.com/cjappl edited https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce Realtime Sanitizer (RTSan) backend (PR #92460)
https://github.com/cjappl edited https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce RADSan backend (PR #92460)
https://github.com/cjappl edited https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce RADSan backend (PR #92460)
cjappl wrote: Ping @yln @vitalybuka @Sirraide @AaronBallman @zygoloid @compnerd @petrhosek @isanbard @MaskRay https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce RADSan backend (PR #92460)
cjappl wrote: Weekly ping of reviewers @yln @vitalybuka @Sirraide @AaronBallman @zygoloid @compnerd @petrhosek @isanbard Looking for weighing in on any of the code as it stands now, or the naming question posed by MaskRay [here](https://discourse.llvm.org/t/rfc-nolock-and-noalloc-attributes/76837/75), so far there seems to be support for rtsan over radsan :) https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce RADSan backend (PR #92460)
@@ -1382,6 +1382,10 @@ collectSanitizerRuntimes(const ToolChain , const
ArgList ,
StaticRuntimes.push_back("asan_cxx");
}
+ if (!SanArgs.needsSharedRt() && SanArgs.needsRadsanRt()) {
+StaticRuntimes.push_back("radsan");
+ }
cjappl wrote:
Ok, if I can summarize the important bits in my own words:
Different platforms have different defaults they use for the sanitizers, some
(Darwin, for example) use shared, others (clang on Linux) use static.
A user can specify and override the default with the flags
`-[shared|static]-libsan`.
To support the most possible configurations, do you think we should add back in
the ability to link the shared library in this file? In Darwin.cpp we already
show the ability to link the shared runtime, so it seemingly would be as simple
as adding in a:
```
if (SanArgs.needsRadsanRt())
SharedRuntimes.push_back("radsan");
```
To the block above. Any advice?
https://github.com/llvm/llvm-project/pull/92460
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce RADSan backend (PR #92460)
@@ -0,0 +1,106 @@
+//===--- radsan_context.cpp - Realtime Sanitizer --*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+//===--===//
+
+#include
+
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+using namespace __sanitizer;
+
+namespace detail {
+
+static pthread_key_t Key;
cjappl wrote:
I pushed the change for all non-lambda variable names, happy to change the
lambdas too based on your feedback.
https://github.com/llvm/llvm-project/pull/92460
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce RADSan backend (PR #92460)
@@ -0,0 +1,106 @@
+//===--- radsan_context.cpp - Realtime Sanitizer --*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+//===--===//
+
+#include
+
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+using namespace __sanitizer;
+
+namespace detail {
+
+static pthread_key_t Key;
cjappl wrote:
No apology necessary! Happy to do this right the first time.
Does this also apply to lambdas?
```
auto Func = []() { vec.push_back(0.4f); };
```
Should this become:
```
auto func = []() { vec.push_back(0.4f); };
```
Or remain "function case"?
https://github.com/llvm/llvm-project/pull/92460
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce RADSan backend (PR #92460)
@@ -0,0 +1,106 @@
+//===--- radsan_context.cpp - Realtime Sanitizer --*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+//===--===//
+
+#include
+
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+using namespace __sanitizer;
+
+namespace detail {
+
+static pthread_key_t Key;
cjappl wrote:
Great thanks!! Before I go through and edit these, `snake_case` is preferred
for variables in all contexts?
Really appreciate the review. Pushing up most of your requested changes now.
https://github.com/llvm/llvm-project/pull/92460
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce RADSan backend (PR #92460)
@@ -0,0 +1,71 @@ +# -*- Python -*- + +import os + +# Setup config name. +config.name = "RADSAN" + config.name_suffix + +# Setup source root. +config.test_source_root = os.path.dirname(__file__) cjappl wrote: Yes, the lit tests may be placed directly in `compiler-rt/test/radsan/` and they run as intended. Just checked on our branch that has them implemented. https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce RADSan backend (PR #92460)
https://github.com/cjappl edited https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] Realtime Sanitizer: Introduce RADSan backend (PR #92460)
https://github.com/cjappl reopened https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] Realtime Sanitizer: Introduce RADSan backend (PR #92460)
https://github.com/cjappl closed https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] Realtime Sanitizer: Introduce RADSan backend (PR #92460)
cjappl wrote: Pinging possibly interested parties for review. @yln @vitalybuka @Sirraide @AaronBallman @dougsonos @davidtrevelyan Please feel free to add more, we don't know who all may be interested. Thanks in advance https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] Realtime Sanitizer: Introduce RADSan backend (PR #92460)
@@ -32,6 +32,9 @@ set(ALL_ASAN_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32}
${ARM64} ${RISCV64}
${LOONGARCH64})
set(ALL_ASAN_ABI_SUPPORTED_ARCH ${X86_64} ${ARM64} ${ARM64_32})
set(ALL_DFSAN_SUPPORTED_ARCH ${X86_64} ${MIPS64} ${ARM64} ${LOONGARCH64})
+set(ALL_RADSAN_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64} ${RISCV64}
+${MIPS32} ${MIPS64} ${PPC64} ${S390X} ${SPARC} ${SPARCV9} ${HEXAGON}
+${LOONGARCH64})
cjappl wrote:
This was copied from ASAN, is this acceptable? We don't have all architectures
to test, although we think that our interceptors are simple enough to work on
any machine (no platform specific assembly in our code, for example)
https://github.com/llvm/llvm-project/pull/92460
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] Realtime Sanitizer: Introduce RADSan backend (PR #92460)
@@ -1382,6 +1382,10 @@ collectSanitizerRuntimes(const ToolChain , const
ArgList ,
StaticRuntimes.push_back("asan_cxx");
}
+ if (!SanArgs.needsSharedRt() && SanArgs.needsRadsanRt()) {
+StaticRuntimes.push_back("radsan");
+ }
cjappl wrote:
One question we have here: What is the SharedRuntimes vs StaticRuntimes? Why
would we need to support both? This is one change we "eyeballed" based on the
other sanitizers.
https://github.com/llvm/llvm-project/pull/92460
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] Realtime Sanitizer: Introduce RADSan backend (PR #92460)
https://github.com/cjappl edited https://github.com/llvm/llvm-project/pull/92460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] PREVIEW: Introduce realtime sanitizer backend (PR #91529)
https://github.com/cjappl edited https://github.com/llvm/llvm-project/pull/91529 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] PREVIEW: Introduce realtime sanitizer backend (PR #91529)
cjappl wrote: Sorry, premature!! https://github.com/llvm/llvm-project/pull/91529 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] PREVIEW: Introduce realtime sanitizer backend (PR #91529)
https://github.com/cjappl closed https://github.com/llvm/llvm-project/pull/91529 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)
@@ -18347,7 +18347,7 @@ void Sema::SetFunctionBodyKind(Decl *D, SourceLocation Loc, FnBodyKind BodyKind, } } -bool Sema::CheckOverridingFunctionAttributes(const CXXMethodDecl *New, +bool Sema::CheckOverridingFunctionAttributes(CXXMethodDecl *New, cjappl wrote: Works for me! https://github.com/llvm/llvm-project/pull/84983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)
@@ -0,0 +1,124 @@
+// RUN: %clang_cc1 %s -ast-dump -fblocks | FileCheck %s
+
+// Make sure that the attribute gets parsed and attached to the correct AST
elements.
+
+#pragma clang diagnostic ignored "-Wunused-variable"
+
+//
=
+// Square brackets, true
+
+namespace square_brackets {
+
+// On the type of the FunctionDecl
+void nl_function() [[clang::nonblocking]];
+// CHECK: FunctionDecl {{.*}} nl_function 'void ()
__attribute__((clang_nonblocking))'
+
+// On the type of the VarDecl holding a function pointer
+void (*nl_func_a)() [[clang::nonblocking]];
+// CHECK: VarDecl {{.*}} nl_func_a 'void (*)()
__attribute__((clang_nonblocking))'
+
+// On the type of the ParmVarDecl of a function parameter
+static void nlReceiver(void (*nl_func)() [[clang::nonblocking]]);
+// CHECK: ParmVarDecl {{.*}} nl_func 'void (*)()
__attribute__((clang_nonblocking))'
+
+// As an AttributedType within the nested types of a typedef
+typedef void (*nl_fp_type)() [[clang::nonblocking]];
+// CHECK: TypedefDecl {{.*}} nl_fp_type 'void (*)()
__attribute__((clang_nonblocking))'
+using nl_fp_talias = void (*)() [[clang::nonblocking]];
+// CHECK: TypeAliasDecl {{.*}} nl_fp_talias 'void (*)()
__attribute__((clang_nonblocking))'
+
+// From a typedef or typealias, on a VarDecl
+nl_fp_type nl_fp_var1;
+// CHECK: VarDecl {{.*}} nl_fp_var1 'nl_fp_type':'void (*)()
__attribute__((clang_nonblocking))'
+nl_fp_talias nl_fp_var2;
+// CHECK: VarDecl {{.*}} nl_fp_var2 'nl_fp_talias':'void (*)()
__attribute__((clang_nonblocking))'
+
+// On type of a FieldDecl
+struct Struct {
+ void (*nl_func_field)() [[clang::nonblocking]];
+// CHECK: FieldDecl {{.*}} nl_func_field 'void (*)()
__attribute__((clang_nonblocking))'
+};
+
+// nonallocating should NOT be subsumed into nonblocking
+void nl1() [[clang::nonblocking]] [[clang::nonallocating]];
+// CHECK: FunctionDecl {{.*}} nl1 'void () __attribute__((clang_nonblocking))
__attribute__((clang_nonallocating))'
+
+void nl2() [[clang::nonallocating]] [[clang::nonblocking]];
+// CHECK: FunctionDecl {{.*}} nl2 'void () __attribute__((clang_nonblocking))
__attribute__((clang_nonallocating))'
+
+decltype(nl1) nl3;
+// CHECK: FunctionDecl {{.*}} nl3 'decltype(nl1)':'void ()
__attribute__((clang_nonblocking)) __attribute__((clang_nonallocating))'
+
+// Attribute propagates from base class virtual method to overrides.
+struct Base {
+ virtual void nb_method() [[clang::nonblocking]];
+};
+struct Derived : public Base {
+ void nb_method() override;
+ // CHECK: CXXMethodDecl {{.*}} nb_method 'void ()
__attribute__((clang_nonblocking))'
+};
+
+// Dependent expression
+template
+struct Dependent {
+ void nb_method2() [[clang::nonblocking(V)]];
+ // CHECK: CXXMethodDecl {{.*}} nb_method2 'void ()
__attribute__((clang_nonblocking(V)))'
+};
+
+// --- Blocks ---
+
+// On the type of the VarDecl holding a BlockDecl
+void (^nl_block1)() [[clang::nonblocking]] = ^() [[clang::nonblocking]] {};
+// CHECK: VarDecl {{.*}} nl_block1 'void (^)()
__attribute__((clang_nonblocking))'
+
+int (^nl_block2)() [[clang::nonblocking]] = ^() [[clang::nonblocking]] {
return 0; };
+// CHECK: VarDecl {{.*}} nl_block2 'int (^)()
__attribute__((clang_nonblocking))'
+
+// The operand of the CallExpr is an ImplicitCastExpr of a DeclRefExpr ->
nl_block which hold the attribute
+static void blockCaller() { nl_block1(); }
+// CHECK: DeclRefExpr {{.*}} 'nl_block1' 'void (^)()
__attribute__((clang_nonblocking))'
+
+// --- Lambdas ---
+
+// On the operator() of a lambda's CXXMethodDecl
+auto nl_lambda = []() [[clang::nonblocking]] {};
+// CHECK: CXXMethodDecl {{.*}} operator() 'void () const
__attribute__((clang_nonblocking))' inline
+
+//
=
+// Square brackets, false
+
+void nl_func_false() [[clang::blocking]];
+// CHECK: FunctionDecl {{.*}} nl_func_false 'void ()
__attribute__((clang_blocking))'
+
+// TODO: This exposes a bug where a type attribute is lost when inferring a
lambda's
+// return type.
+auto nl_lambda_false = []() [[clang::blocking]] {};
+
+} // namespace square_brackets
+
+//
=
+// GNU-style attribute, true
+
+// TODO: Duplicate more of the above for GNU-style attribute
+
+namespace gnu_style {
+
+// On the type of the FunctionDecl
+void nl_function() __attribute__((clang_nonblocking));
+// CHECK: FunctionDecl {{.*}} nl_function 'void ()
__attribute__((clang_nonblocking))'
+
+// Alternate placement on the FunctionDecl
+__attribute__((clang_nonblocking)) void nl_function();
+// CHECK: FunctionDecl {{.*}} nl_function 'void ()
__attribute__((clang_nonblocking))'
+
+// On the type of the VarDecl holding a function pointer
+void (*nl_func_a)() __attribute__((clang_nonblocking));
+// CHECK: VarDecl {{.*}}
[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)
https://github.com/cjappl edited https://github.com/llvm/llvm-project/pull/84983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)
@@ -7963,6 +7967,148 @@ static Attr *getCCTypeAttr(ASTContext , ParsedAttr
) {
llvm_unreachable("unexpected attribute kind!");
}
+ExprResult Sema::ActOnEffectExpression(Expr *CondExpr, FunctionEffectMode
,
+ bool RequireConstexpr) {
+ // see checkFunctionConditionAttr, Sema::CheckCXXBooleanCondition
+ if (RequireConstexpr || !CondExpr->isTypeDependent()) {
+ExprResult E = PerformContextuallyConvertToBool(CondExpr);
+if (E.isInvalid())
+ return E;
+CondExpr = E.get();
+if (RequireConstexpr || !CondExpr->isValueDependent()) {
+ llvm::APSInt CondInt;
+ E = VerifyIntegerConstantExpression(
+ E.get(), ,
+ // TODO: have our own diagnostic
+ diag::err_constexpr_if_condition_expression_is_not_constant);
+ if (E.isInvalid()) {
cjappl wrote:
Minor funky 4 spacing for the first few lines here
https://github.com/llvm/llvm-project/pull/84983
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)
https://github.com/cjappl commented: Just doing a first pass review. The guts of this are above my paygrade, but after playing with this functionally for a few days it seems to behave as intended from the realtime sanitizer team! :) https://github.com/llvm/llvm-project/pull/84983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)
@@ -7963,6 +7967,148 @@ static Attr *getCCTypeAttr(ASTContext , ParsedAttr
) {
llvm_unreachable("unexpected attribute kind!");
}
+ExprResult Sema::ActOnEffectExpression(Expr *CondExpr, FunctionEffectMode
,
+ bool RequireConstexpr) {
+ // see checkFunctionConditionAttr, Sema::CheckCXXBooleanCondition
+ if (RequireConstexpr || !CondExpr->isTypeDependent()) {
+ExprResult E = PerformContextuallyConvertToBool(CondExpr);
+if (E.isInvalid())
+ return E;
+CondExpr = E.get();
+if (RequireConstexpr || !CondExpr->isValueDependent()) {
+ llvm::APSInt CondInt;
+ E = VerifyIntegerConstantExpression(
+ E.get(), ,
+ // TODO: have our own diagnostic
+ diag::err_constexpr_if_condition_expression_is_not_constant);
+ if (E.isInvalid()) {
+return E;
+ }
+ Mode =
+ (CondInt != 0) ? FunctionEffectMode::True :
FunctionEffectMode::False;
+} else {
+ Mode = FunctionEffectMode::Dependent;
+}
+ } else {
+Mode = FunctionEffectMode::Dependent;
+ }
+ return CondExpr;
+}
+
+static bool
+handleNonBlockingNonAllocatingTypeAttr(TypeProcessingState ,
+ ParsedAttr , QualType ,
+ FunctionTypeUnwrapper ) {
+ // Delay if this is not a function type.
+ if (!Unwrapped.isFunctionType())
+return false;
+
+ // Require FunctionProtoType
+ auto *FPT = Unwrapped.get()->getAs();
+ if (FPT == nullptr) {
+// TODO: special diagnostic?
+return false;
+ }
+
+ // Parse the new attribute.
+ // non/blocking or non/allocating? Or conditional (computed)?
+ const bool isNonBlocking = PAttr.getKind() == ParsedAttr::AT_NonBlocking ||
+ PAttr.getKind() == ParsedAttr::AT_Blocking;
+ Sema = TPState.getSema();
+
+ FunctionEffectMode NewMode = FunctionEffectMode::None;
+ Expr *CondExpr = nullptr; // only valid if dependent
+
+ if (PAttr.getKind() == ParsedAttr::AT_NonBlocking ||
+ PAttr.getKind() == ParsedAttr::AT_NonAllocating) {
+if (!PAttr.checkAtMostNumArgs(S, 1)) {
+ PAttr.setInvalid();
+ return true;
+}
+
+// Parse the conditional expression, if any
+if (PAttr.getNumArgs() == 1) {
+ CondExpr = PAttr.getArgAsExpr(0);
+ ExprResult E = S.ActOnEffectExpression(CondExpr, NewMode);
+ if (E.isInvalid())
+return false;
+ CondExpr = NewMode == FunctionEffectMode::Dependent ? E.get() : nullptr;
+} else {
+ NewMode = FunctionEffectMode::True;
+}
+ } else {
+// This is the `blocking` or `allocating` attribute.
+if (S.CheckAttrNoArgs(PAttr))
+ return true;
+NewMode = FunctionEffectMode::False;
+ }
+
+ const FunctionEffect::Kind FEKind =
+ (NewMode == FunctionEffectMode::False)
+ ? (isNonBlocking ? FunctionEffect::Kind::Blocking
+ : FunctionEffect::Kind::Allocating)
+ : (isNonBlocking ? FunctionEffect::Kind::NonBlocking
+ : FunctionEffect::Kind::NonAllocating);
+ const FunctionEffectWithCondition NewEC{FunctionEffect(FEKind),
+ FunctionEffectCondition(CondExpr)};
+
+ // Diagnose the newly provided attribute as incompatible with a previous one.
+ auto incompatible = [&](const FunctionEffectWithCondition ) {
+S.Diag(PAttr.getLoc(), diag::err_attributes_are_not_compatible)
+<< ("'" + NewEC.description() + "'")
+<< ("'" + PrevEC.description() + "'") << false;
+// we don't necessarily have the location of the previous attribute,
+// so no note.
+PAttr.setInvalid();
+return true;
+ };
+
+ // Find previous attributes
+ std::optional PrevNonBlocking;
+ std::optional PrevNonAllocating;
+
+ for (const FunctionEffectWithCondition : FPT->getFunctionEffects()) {
+if (PrevEC.Effect.kind() == FEKind ||
+PrevEC.Effect.oppositeKind() == FEKind)
+ return incompatible(PrevEC);
+switch (PrevEC.Effect.kind()) {
+case FunctionEffect::Kind::Blocking:
+case FunctionEffect::Kind::NonBlocking:
+ PrevNonBlocking = PrevEC;
+ break;
+case FunctionEffect::Kind::Allocating:
+case FunctionEffect::Kind::NonAllocating:
+ PrevNonAllocating = PrevEC;
+ break;
+default:
+ break;
+}
+ }
+
+ if (isNonBlocking) {
cjappl wrote:
minor: only var I've seen so far not UpperCamelCase
https://github.com/llvm/llvm-project/pull/84983
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)
@@ -18347,7 +18347,7 @@ void Sema::SetFunctionBodyKind(Decl *D, SourceLocation Loc, FnBodyKind BodyKind, } } -bool Sema::CheckOverridingFunctionAttributes(const CXXMethodDecl *New, +bool Sema::CheckOverridingFunctionAttributes(CXXMethodDecl *New, cjappl wrote: It seems possibly strange to me that a function called "Check" would mutate a value passed into it. I would expect it to be passive. Can the mutation come later, or in a different function, or perhaps this should be renamed? https://github.com/llvm/llvm-project/pull/84983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)
@@ -1870,6 +1870,28 @@ bool Sema::IsFunctionConversion(QualType FromType, QualType ToType, FromFn = QT->getAs(); Changed = true; } + +// For C, when called from checkPointerTypesForAssignment, +// we need not to alter FromFn, or else even an innocuous cast +// like dropping effects will fail. In C++ however we do want to +// alter FromFn. TODO: Is this correct? cjappl wrote: Did you ever get clarity on if this was correct? Calling it out as I peruse this PR, I don't have the answer but it's hidden in here so wanted to bring attention to it. https://github.com/llvm/llvm-project/pull/84983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)
cjappl wrote:
Possibly another bug here (or user error).
I am trying to see the warnings show up for a simple test program. The clang
used in this example is the tip of your branch at time of writing
b95964c2570c11d1d80ae6874be5e400f7b504ad
```cpp
#include
#include
int* process () [[clang::nonblocking]]
{
// THIS MALLOC SHOULD WARN, RIGHT?
int* malloced_data = (int*)std::malloc(sizeof(int));
malloced_data[0] = 7;
return malloced_data;
}
int main()
{
int* y = process();
printf("y[0] = %d\n", y[0]);
return (int)y[0];
}
```
When I run compile and run this code, it runs, with the proper "7" exit code,
but does not give me any warnings on compilation.
```
> /Users/topher/code/radsan_cjappl/build/bin/clang++ main.cpp -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk
> -Wfunction-effects -Werror
> ./a.out
y[0] = 7
> echo $?
7
```
I highly suspect I'm doing something wrong, but can't figure out what it might
be.
https://github.com/llvm/llvm-project/pull/84983
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)
cjappl wrote: I can confirm that now if I try to use any argument with `blocking` I get: ``` /Users/topher/Desktop/test_radsan/main.cpp:25:40: error: 'blocking' attribute takes no arguments 25 | float process (float* data) noexcept [[clang::blocking(false)]] ``` Great! https://github.com/llvm/llvm-project/pull/84983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)
cjappl wrote: Ah! Nice, that is a totally valid solution as well. The only argument for the parameter that I can think of is symmetry. I just noticed it _could_ accept a parameter, so I expected the behavior above. Absolutely good by me to strike it from being possible. https://github.com/llvm/llvm-project/pull/84983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)
cjappl wrote:
Hi @dougsonos,
Just starting to integrate our two changes and noticing a possible bug here.
Issue: `blocking(false)` does not seem to resolve to `nonblocking`
## Streps to repro:
1. Have an example like
```
int main() [[clang::blocking(false)]]
{
return 0;
}
```
2. (optional, if you can't get diagnostics another way) Apply this patch to
llvm, and recompile clang
```
diff --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index 69548902dc43..3047ed1e1887 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -2404,6 +2404,15 @@ void CodeGenModule::ConstructAttributeList(StringRef
Name,
FuncAttrs.addAttribute(llvm::Attribute::NoReturn);
NBA = Fn->getAttr();
}
+
+ llvm::raw_fd_ostream stream(1, true);
+ const auto effects = Fn->getFunctionEffects();
+ if (not effects.empty())
+ {
+stream << "Function: " << Fn->getNameAsString().c_str() << "\n";
+Fn->getFunctionEffects().dump(stream);
+stream << "\n";
+ }
}
if (isa(TargetDecl) || isa(TargetDecl)) {
```
3. Compile aforementioned main file with the new perf-constraints clang
## Observed
`blocking(false)` incorrectly resolves to `blocking`, when it should be
`nonblocking`
```
> ninja
[1/2] Building CXX object CMakeFiles/MyExecutable.dir/main.cpp.o
Function: main
Effects{blocking}
...
```
All the other (non)blocking conditionals seem to work as intended.
1. `nonblocking(true)` -- should resolve to nonblocking ✅
```
Function: main
Effects{nonblocking}
```
2. `nonblocking(false)` -- should resolve to blocking ✅
```
Function: main
Effects{blocking}
```
3. `blocking(true)` -- should resolve to blocking ✅
```
Function: main
Effects{blocking}
```
https://github.com/llvm/llvm-project/pull/84983
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)
@@ -8057,3 +8057,70 @@ requirement:
}
}];
}
+
+def DocCatNonBlockingNonAllocating : DocumentationCategory<"Performance
Constraint Attributes"> {
+ let Content = [{
cjappl wrote:
It may be good to mention what the flag is that you use to enable these
warnings.
https://github.com/llvm/llvm-project/pull/84983
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)
@@ -27,6 +27,8 @@ #include "clang/AST/StmtObjC.h" #include "clang/AST/StmtVisitor.h" #include "clang/AST/Type.h" +#include "clang/ASTMatchers/ASTMatchFinder.h" cjappl wrote: To be less prescriptive with the solution: I was getting linker errors saying that the symbols found in the ASTMatchers headers (used later in this file) were missing. I fixed it with this CMake change. Let me know if anyone needs more info and I'll re-generate the error. https://github.com/llvm/llvm-project/pull/84983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)
@@ -27,6 +27,8 @@ #include "clang/AST/StmtObjC.h" #include "clang/AST/StmtVisitor.h" #include "clang/AST/Type.h" +#include "clang/ASTMatchers/ASTMatchFinder.h" cjappl wrote: FYI, these two headers require a cmake change: ``` diff --git a/clang/lib/Sema/CMakeLists.txt b/clang/lib/Sema/CMakeLists.txt index a96439df6642..278c7c7394ab 100644 --- a/clang/lib/Sema/CMakeLists.txt +++ b/clang/lib/Sema/CMakeLists.txt @@ -80,6 +80,7 @@ add_clang_library(clangSema LINK_LIBS clangAPINotes clangAST + clangASTMatchers clangAnalysis clangBasic clangEdit ``` With this small change I was able to build the branch of your work merged with ours, no other adaptations necessary :) https://github.com/llvm/llvm-project/pull/84983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] Add ability to pass in a clang-tidy config file to clang-tidy-diff (PR #75721)
cjappl wrote: This is almost exactly the same as #75457 , just with the release notes. I'm going to close this for now and re-open it if that one gets stale. https://github.com/llvm/llvm-project/pull/75721 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] Add ability to pass in a clang-tidy config file to clang-tidy-diff (PR #75721)
https://github.com/cjappl closed https://github.com/llvm/llvm-project/pull/75721 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] Allow to pass config file to clang-tidy-diff (PR #75457)
cjappl wrote: @MichaelLettrich I just realized I submitted basically the same PR as you! Great minds think alike. I found yours when I searched. https://github.com/llvm/llvm-project/pull/75721 In this PR I added to the release notes, feel free to steal them if you want. I would love this feature in `main` https://github.com/llvm/llvm-project/pull/75457 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] Add ability to pass in a clang-tidy config file to clang-tidy-diff (PR #75721)
https://github.com/cjappl updated
https://github.com/llvm/llvm-project/pull/75721
>From 433f4ac919a6967c278e56a19b5824e474ebd907 Mon Sep 17 00:00:00 2001
From: Chris Apple <14171107+cja...@users.noreply.github.com>
Date: Sat, 16 Dec 2023 15:53:56 -0800
Subject: [PATCH 1/3] Add ability to pass in a clang-tidy config file to
clang-tidy-diff
---
clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py | 8
1 file changed, 8 insertions(+)
diff --git a/clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
b/clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
index 8817e2914f6e25..fdaf1a4330e060 100755
--- a/clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
+++ b/clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
@@ -223,6 +223,12 @@ def main():
default=[],
help="Load the specified plugin in clang-tidy.",
)
+parser.add_argument(
+"-config",
+dest="config",
+default=None,
+help="Specifies a clang-tidy config file"
+)
clang_tidy_args = []
argv = sys.argv[1:]
@@ -309,6 +315,8 @@ def main():
# Form the common args list.
common_clang_tidy_args = []
+if args.config is not None:
+common_clang_tidy_args.append("--config-file=" + args.config)
if args.fix:
common_clang_tidy_args.append("-fix")
if args.checks != "":
>From ff3e289814d8af2c3c8eea12e3ee3c48959aa79a Mon Sep 17 00:00:00 2001
From: Chris Apple <14171107+cja...@users.noreply.github.com>
Date: Sat, 16 Dec 2023 16:42:28 -0800
Subject: [PATCH 2/3] Fix style
---
clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
b/clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
index fdaf1a4330e060..e20b7a2cda2dde 100755
--- a/clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
+++ b/clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
@@ -227,7 +227,7 @@ def main():
"-config",
dest="config",
default=None,
-help="Specifies a clang-tidy config file"
+help="Specifies a clang-tidy config file",
)
clang_tidy_args = []
>From 05ae28f6705a7bccf36bbb3a84a17c3597b44c09 Mon Sep 17 00:00:00 2001
From: Chris Apple <14171107+cja...@users.noreply.github.com>
Date: Sat, 16 Dec 2023 16:51:41 -0800
Subject: [PATCH 3/3] Update ReleaseNotes
---
clang-tools-extra/docs/ReleaseNotes.rst | 4
1 file changed, 4 insertions(+)
diff --git a/clang-tools-extra/docs/ReleaseNotes.rst
b/clang-tools-extra/docs/ReleaseNotes.rst
index 6d91748e4cef18..0e2679e4fafb0e 100644
--- a/clang-tools-extra/docs/ReleaseNotes.rst
+++ b/clang-tools-extra/docs/ReleaseNotes.rst
@@ -124,6 +124,10 @@ Improvements to clang-tidy
exporting fixes fails. It now accepts a directory as a value for
`-export-fixes` to export individual yaml files for each compilation unit.
+- Improved :program:`clang-tidy-diff.py` script. It now accepts a `-config`
option
+ to pass in a configuration file to :program:`clang-tidy`. This option
corresponds
+ to the `--config-file` option in :program:`clang-tidy`.
+
- Improved :program:`run-clang-tidy.py` script. It now accepts a directory
as a value for `-export-fixes` to export individual yaml files for each
compilation unit.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] Add ability to pass in a clang-tidy config file to clang-tidy-diff (PR #75721)
https://github.com/cjappl updated
https://github.com/llvm/llvm-project/pull/75721
>From 433f4ac919a6967c278e56a19b5824e474ebd907 Mon Sep 17 00:00:00 2001
From: Chris Apple <14171107+cja...@users.noreply.github.com>
Date: Sat, 16 Dec 2023 15:53:56 -0800
Subject: [PATCH 1/2] Add ability to pass in a clang-tidy config file to
clang-tidy-diff
---
clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py | 8
1 file changed, 8 insertions(+)
diff --git a/clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
b/clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
index 8817e2914f6e25..fdaf1a4330e060 100755
--- a/clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
+++ b/clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
@@ -223,6 +223,12 @@ def main():
default=[],
help="Load the specified plugin in clang-tidy.",
)
+parser.add_argument(
+"-config",
+dest="config",
+default=None,
+help="Specifies a clang-tidy config file"
+)
clang_tidy_args = []
argv = sys.argv[1:]
@@ -309,6 +315,8 @@ def main():
# Form the common args list.
common_clang_tidy_args = []
+if args.config is not None:
+common_clang_tidy_args.append("--config-file=" + args.config)
if args.fix:
common_clang_tidy_args.append("-fix")
if args.checks != "":
>From ff3e289814d8af2c3c8eea12e3ee3c48959aa79a Mon Sep 17 00:00:00 2001
From: Chris Apple <14171107+cja...@users.noreply.github.com>
Date: Sat, 16 Dec 2023 16:42:28 -0800
Subject: [PATCH 2/2] Fix style
---
clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
b/clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
index fdaf1a4330e060..e20b7a2cda2dde 100755
--- a/clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
+++ b/clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
@@ -227,7 +227,7 @@ def main():
"-config",
dest="config",
default=None,
-help="Specifies a clang-tidy config file"
+help="Specifies a clang-tidy config file",
)
clang_tidy_args = []
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] Add ability to pass in a clang-tidy config file to clang-tidy-diff (PR #75721)
cjappl wrote: @njames93 friendly ping for a review on this PR. Thank you in advance! https://github.com/llvm/llvm-project/pull/75721 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] Add ability to pass in a clang-tidy config file to clang-tidy-diff (PR #75721)
https://github.com/cjappl created
https://github.com/llvm/llvm-project/pull/75721
I found this handy for situations where you want to pass in a config file and
not rely on a default `.clang-tidy` file.
The new option is `-config` and will expect something that can be passed into
the `--config-file=` parameter of `clang-tidy`
>From 433f4ac919a6967c278e56a19b5824e474ebd907 Mon Sep 17 00:00:00 2001
From: Chris Apple <14171107+cja...@users.noreply.github.com>
Date: Sat, 16 Dec 2023 15:53:56 -0800
Subject: [PATCH] Add ability to pass in a clang-tidy config file to
clang-tidy-diff
---
clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py | 8
1 file changed, 8 insertions(+)
diff --git a/clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
b/clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
index 8817e2914f6e25..fdaf1a4330e060 100755
--- a/clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
+++ b/clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
@@ -223,6 +223,12 @@ def main():
default=[],
help="Load the specified plugin in clang-tidy.",
)
+parser.add_argument(
+"-config",
+dest="config",
+default=None,
+help="Specifies a clang-tidy config file"
+)
clang_tidy_args = []
argv = sys.argv[1:]
@@ -309,6 +315,8 @@ def main():
# Form the common args list.
common_clang_tidy_args = []
+if args.config is not None:
+common_clang_tidy_args.append("--config-file=" + args.config)
if args.fix:
common_clang_tidy_args.append("-fix")
if args.checks != "":
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
