Re: clang: compile static analyzer
Joerg Sonnenberger wrote in
:
|Am Fri, Jan 21, 2022 at 12:45:56AM +0100 schrieb Steffen Nurpmeso:
|> Fwiw, i have been astonished by this thread. I found scan-build
|> to generate a lot of false warnings, so much indeed that i stopped
|> using it .. in summer 2017.
|
|I've spend time on the static analyzer output in NetBSD and I wouldn't
|say so much that it creates too many false warnings, but that the pure
Surely i talk only small things.
|text version is not helpful. The HTML output at least explains the
Yes i like that from Coverity you get a text email (or at least
last i used it, development branch in work for two years and that
not yet, and master mostly stable; and the others never, hmm) with
at least the points of interest of all new defects. Most of the
time that is all i need!
|reasoning. From those pre-conditions, it is often easy to deduce why it
|is a false positive from *other* conditions in the program. Properly
|asserting those would certainly improve code.
Like is said somewhen in this thread, you are forced to instrument
code like grazy. And that sucks like grazy; just one or two days
ago, for example, i finally decided to do a FALLTHRU macro and
replace all /* FALLTHRU */ comments with it. One should think
this is a matured thing covered by unit tests on the compiler
front, but i am conservative and just enable it with the compiler
versions i have at hand (working around specific compiler bugs
/ on particular OSs is one of the things), but you stumble
whenever you go! So for gcc 11.2.0 i now have made this
"UNUSED(0);__attribute__ ((fallthrough));" because without the
UNUSED(0); like for clang gcc complains "a label can only be part
of a statement and a declaration is not a statement" in a very
very normal case: fallthrough condition (but only one of the many,
mind you! iirc). Or is "case A:\nFALLTHRU\ncase B:.." forbidden
now too? Honestly i find all these things very much annoying and
not helpful at all. I'd rather have some more keywords like
"unroll" before loop keywords or whatever, so that i have the
control rather than the compiler (i had just read "Who's afraid of
a big bad optimizing compiler?" of LWN some hm week ago).
So this is all theory. Or take this
// xxx clang 5.0.1 BUG: needed this-> to find superclass field
gview(void) {this->csdv_parent = NIL; this->csdv_node = NIL;}
Only there of the many. And whatever. Nono.
|The biggest advantage in coverity is the logic they have for preserving
|the state of analysis across code changes, e.g. once you tag a reported
|issue as analyzed and not a problem, it tries very hard to not show it
|again.
Yes! Even without instrumentation that is.
I mean, hey!, this is _very_ complicated stuff. It is just that
i _never_ had luck with scan-build, really. And the example
i posted last here... Shit always happens, but if you _can_
analyze code execution paths through all units involved in the
run, i would have expected that this condition cannot produce
a false positive, because it cannot. If NIL it jumps away never
to come back. It cannot be NIL in the code that follows, period.
-Weverything is pretty exhaustive, i try to write new code so it
passes this.
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: clang: compile static analyzer
Am Fri, Jan 21, 2022 at 12:45:56AM +0100 schrieb Steffen Nurpmeso: > Fwiw, i have been astonished by this thread. I found scan-build > to generate a lot of false warnings, so much indeed that i stopped > using it .. in summer 2017. I've spend time on the static analyzer output in NetBSD and I wouldn't say so much that it creates too many false warnings, but that the pure text version is not helpful. The HTML output at least explains the reasoning. From those pre-conditions, it is often easy to deduce why it is a false positive from *other* conditions in the program. Properly asserting those would certainly improve code. The biggest advantage in coverity is the logic they have for preserving the state of analysis across code changes, e.g. once you tag a reported issue as analyzed and not a problem, it tries very hard to not show it again. Joerg
Re: clang: compile static analyzer
Hello. Steffen Nurpmeso wrote in <20220121154612.frou2%stef...@sdaoden.eu>: |Andre Smagin wrote in | <20220120231806.0463e0c792db3e3e5fc07...@smagin.com>: ||On Fri, 21 Jan 2022 00:45:56 +0100 ||Steffen Nurpmeso wrote: ||> I found scan-build to generate a lot of false warnings, so much indeed ||> that i stopped using it .. in summer 2017. || ||You, and most others, (no sarcasm at all here) are much better ||at C than I will ever be. I am not even at "amateur" level - more like ||a part-time hobby. I mostly fiddle with text data compression for fun. || ||For me, clang analyzer is more than helpful. It detects errors that ||most of you, professional programmers, would never make. You probably ||don't even realize the power of it, since you never make such ||embarrassing mistakes while coding as I do. For me, every time there was No no all that not true you know. ||a warning from clang, it was fully warranted. Took me couple days in Yes. Use -Weverything and it can help you quite a lot (if the masses of warnings from the standard libraries do not make you run away). ||some cases to figure out why, but it was always justified and I learned ||a lot from it. But scan-build is just an *annoyance*. ||I install clang from ports solely for the analyzer part. It would be ||nice if it was included in base installation - some of us just want a ||basic idiot-check tool available when trying to program things. But ||ports installation works as well too. So for example, because it really bothered me when i tried it "against better knowledge". See for example this "simple" control flow (p is a union of a void* and a char* pointer, for easy casting): 1499 1500 p.c = NIL; ← Null pointer value stored to 'p.c' → ..nothing with p.c here, only to be able to jump in case of error and have no munmap(2) happen.. 1505 else if((p.v = mmap(NIL, S(uz,st.st_size), PROT_READ, MAP_SHARED, i, 0)) == NIL) ... 1511 if((mbase = p.v) == NIL) ← Assuming the condition is false ... So no error, no jump to error return next. p.[vc] is not NIL. It is not here nor will anything but auto-increment happen to it any more. Now a simple loop over the memory mmap(2)ed into p.[vc]. ... Loop condition is true. Entering loop body ... → 1523if(*p.c != '\n') ← Dereference of null pointer (loaded from field 'c') You know. But how this. How can -Weverything go down a complicated code flow and get things right that you (me! that is.) simply does not see, but scan-build bails on such a simple first-level-cannot-happen flow analysis error? And such things happen all the time. And from my experience Coverity does not have such problems, but especially not with such a frequency. Only false positives with this run. But -Weverything is really a good thing, i would only wish gcc had it too, because i am such an idiot with all the many options. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: clang: compile static analyzer
Andre Smagin wrote in <20220120231806.0463e0c792db3e3e5fc07...@smagin.com>: |On Fri, 21 Jan 2022 00:45:56 +0100 |Steffen Nurpmeso wrote: | |> I found scan-build to generate a lot of false warnings, so much indeed |> that i stopped using it .. in summer 2017. | |You, and most others, (no sarcasm at all here) are much better |at C than I will ever be. I am not even at "amateur" level - more like |a part-time hobby. I mostly fiddle with text data compression for fun. | |For me, clang analyzer is more than helpful. It detects errors that |most of you, professional programmers, would never make. You probably |don't even realize the power of it, since you never make such |embarrassing mistakes while coding as I do. For me, every time there was |a warning from clang, it was fully warranted. Took me couple days in |some cases to figure out why, but it was always justified and I learned |a lot from it. | |I install clang from ports solely for the analyzer part. It would be |nice if it was included in base installation - some of us just want a |basic idiot-check tool available when trying to program things. But |ports installation works as well too. I nonetheless think of overlaying to get rid of it again here. This is hobby here .. they prefer that instead of cryptomining, maybe. I am pretty sure noone here uses all the utilities. I personally enable a lot of compiler warnings, 'am not there with clang's -Weverything, but lots of others. Not much remains to do if that works. I find that Coverity that you scratched from my message does a really good job out of the box, maybe scan-build is better if you instrument the code like grazy, you know, all the attributes that can be attached to lots of places to make the code like C# or Rust. Or so. 'Got the ashes to prove it. (P.S.: my try was before the FreeBSD commit series with dead assignments, 2022-01-14 22:18:04.) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: clang: compile static analyzer
On Fri, 21 Jan 2022 00:45:56 +0100 Steffen Nurpmeso wrote: > I found scan-build to generate a lot of false warnings, so much indeed > that i stopped using it .. in summer 2017. You, and most others, (no sarcasm at all here) are much better at C than I will ever be. I am not even at "amateur" level - more like a part-time hobby. I mostly fiddle with text data compression for fun. For me, clang analyzer is more than helpful. It detects errors that most of you, professional programmers, would never make. You probably don't even realize the power of it, since you never make such embarrassing mistakes while coding as I do. For me, every time there was a warning from clang, it was fully warranted. Took me couple days in some cases to figure out why, but it was always justified and I learned a lot from it. I install clang from ports solely for the analyzer part. It would be nice if it was included in base installation - some of us just want a basic idiot-check tool available when trying to program things. But ports installation works as well too. -- Andre
Re: clang: compile static analyzer
Alexander Bluhm wrote in
:
|On Fri, Jan 14, 2022 at 05:59:24PM +0100, Claudio Jeker wrote:
|> On Fri, Jan 14, 2022 at 04:44:49PM +, Stuart Henderson wrote:
|>> On 2022/01/14 16:52, Rafael Sadowski wrote:
|>>> On Fri Jan 14, 2022 at 03:17:21PM +0100, Tobias Heider wrote:
| clang ships with a pretty useful static analyzer to find all kinds \
| of bugs
| in C and C++ code:
|
| https://clang-analyzer.llvm.org/
|
| I use it regularly to check my own diffs and found plenty of bugs \
| I could
| have missed otherwise. While we have the code in base we don't \
| actually
| build it into our libclang currently, so the only ways to use it are
| manually modifying the Makefiles or installing llvm from ports.
|
| I was wondering if anyone else uses this and if there was any \
| interest to
| have this in our base clang?
Fwiw, i have been astonished by this thread. I found scan-build
to generate a lot of false warnings, so much indeed that i stopped
using it .. in summer 2017.
So i tried again and except for a lot of "dead assignments",
which, well, are dead assignments but then again it is my style of
coding since on x86 there is a return register and so i am used to
write it like this, just in case, you know, and then "self" aka
*this is ready to go, there were mostly false warnings.
Coverity.com on the other hand always surprises me over and over
again with what it finds, .. and i do not even get paid for that.
'Only sayin' because clang here is sheer unbelievable almost 800MB
installed, and i wonder what for, even if (!) compared to gcc.
I do not use clang-format (though this might be an error of mine).
But mind you, i do not instrument my code for lint and successors
(except FALLTHRU, and that luckily now that compilers start
screaming for such cases, heck i am not autopilot driving). Now
that i am on github (again, mostly to ease people's burden with my
bug reports) i think i will not even download the newest Coverity
software but start using github's coverity hook.
You know, i struggle here because of
mv clang-tools-extra-$version.src clang-$version.src/tools/extra
cmake -S $name-$version.src -B build -G Ninja \
-D CMAKE_INSTALL_PREFIX=/usr \
-D CMAKE_INSTALL_LIBEXECDIR=lib/clang \
-D CMAKE_BUILD_TYPE=Release \
-D CMAKE_C_FLAGS_RELEASE="$CFLAGS" \
-D CMAKE_CXX_FLAGS_RELEASE="$CXXFLAGS" \
-D LLVM_EXTERNAL_LIT=/usr/bin/lit \
-D LLVM_PARALLEL_COMPILE_JOBS="${JOBS:-1}" \
-Wno-dev
cmake --build build
That is, i have to have it all or put more effort in maintaining
my system. I hate it. :)
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: clang: compile static analyzer
On Fri, Jan 14, 2022 at 05:59:24PM +0100, Claudio Jeker wrote: > On Fri, Jan 14, 2022 at 04:44:49PM +, Stuart Henderson wrote: > > On 2022/01/14 16:52, Rafael Sadowski wrote: > > > On Fri Jan 14, 2022 at 03:17:21PM +0100, Tobias Heider wrote: > > > > Hi, > > > > > > > > clang ships with a pretty useful static analyzer to find all kinds of > > > > bugs > > > > in C and C++ code: > > > > > > > > https://clang-analyzer.llvm.org/ > > > > > > > > I use it regularly to check my own diffs and found plenty of bugs I > > > > could > > > > have missed otherwise. While we have the code in base we don't actually > > > > build it into our libclang currently, so the only ways to use it are > > > > manually modifying the Makefiles or installing llvm from ports. > > > > > > > > I was wondering if anyone else uses this and if there was any interest > > > > to > > > > have this in our base clang? > > > > > > Please checkout devel/clang-tools-extra, if you missed something let me > > > know. > > > CLANG_ENABLE_STATIC_ANALYZER=ON is enabled by default. > > > > No need for clang-tools-extra, it is in the llvm package > > > > Like others I am happy just having the static analyzer / scan-build in > > ports. It is useful, but I think not really useful enough to add to the > > time taken by llvm in every base build when it's available in ports. > > The build spends a lot of time in lldb and its usefulness is questionable. > Why do not tell people to install lldb from ports as well? > > Honestly the build time of clang is already so bad that adding an extra > few 100 objects to it would not make it much worse. I have compared build time without and with the static analyzer patch. root@ot29:.../clang# time make -j 6 90m55.98s real 280m16.61s user 212m18.56s system 98m56.58s real 302m43.42s user 227m02.29s system This is 8 minutes or 8.8% more real build time for clang subdir. Having the analyzer in base is good if people use it. It is even more useful if this encourages people to find and fix bugs. But it is a waste of time if all potential bug fixers use the ports version anyway. I am a bit undecided, but prefer to ship it with base. bluhm
Re: clang: compile static analyzer
On Fri, Jan 14, 2022 at 04:44:49PM +, Stuart Henderson wrote: > On 2022/01/14 16:52, Rafael Sadowski wrote: > > On Fri Jan 14, 2022 at 03:17:21PM +0100, Tobias Heider wrote: > > > Hi, > > > > > > clang ships with a pretty useful static analyzer to find all kinds of bugs > > > in C and C++ code: > > > > > > https://clang-analyzer.llvm.org/ > > > > > > I use it regularly to check my own diffs and found plenty of bugs I could > > > have missed otherwise. While we have the code in base we don't actually > > > build it into our libclang currently, so the only ways to use it are > > > manually modifying the Makefiles or installing llvm from ports. > > > > > > I was wondering if anyone else uses this and if there was any interest to > > > have this in our base clang? > > > > Please checkout devel/clang-tools-extra, if you missed something let me > > know. > > CLANG_ENABLE_STATIC_ANALYZER=ON is enabled by default. > > No need for clang-tools-extra, it is in the llvm package > > Like others I am happy just having the static analyzer / scan-build in > ports. It is useful, but I think not really useful enough to add to the > time taken by llvm in every base build when it's available in ports. The build spends a lot of time in lldb and its usefulness is questionable. Why do not tell people to install lldb from ports as well? Honestly the build time of clang is already so bad that adding an extra few 100 objects to it would not make it much worse. -- :wq Claudio
Re: clang: compile static analyzer
On 2022/01/14 16:52, Rafael Sadowski wrote: > On Fri Jan 14, 2022 at 03:17:21PM +0100, Tobias Heider wrote: > > Hi, > > > > clang ships with a pretty useful static analyzer to find all kinds of bugs > > in C and C++ code: > > > > https://clang-analyzer.llvm.org/ > > > > I use it regularly to check my own diffs and found plenty of bugs I could > > have missed otherwise. While we have the code in base we don't actually > > build it into our libclang currently, so the only ways to use it are > > manually modifying the Makefiles or installing llvm from ports. > > > > I was wondering if anyone else uses this and if there was any interest to > > have this in our base clang? > > Please checkout devel/clang-tools-extra, if you missed something let me know. > CLANG_ENABLE_STATIC_ANALYZER=ON is enabled by default. No need for clang-tools-extra, it is in the llvm package Like others I am happy just having the static analyzer / scan-build in ports. It is useful, but I think not really useful enough to add to the time taken by llvm in every base build when it's available in ports.
Re: clang: compile static analyzer
On Fri Jan 14, 2022 at 03:17:21PM +0100, Tobias Heider wrote:
> Hi,
>
> clang ships with a pretty useful static analyzer to find all kinds of bugs
> in C and C++ code:
>
> https://clang-analyzer.llvm.org/
>
> I use it regularly to check my own diffs and found plenty of bugs I could
> have missed otherwise. While we have the code in base we don't actually
> build it into our libclang currently, so the only ways to use it are
> manually modifying the Makefiles or installing llvm from ports.
>
> I was wondering if anyone else uses this and if there was any interest to
> have this in our base clang?
Please checkout devel/clang-tools-extra, if you missed something let me know.
CLANG_ENABLE_STATIC_ANALYZER=ON is enabled by default.
Rafael
>
> diff --git gnu/usr.bin/clang/Makefile gnu/usr.bin/clang/Makefile
> index 6cf71d36cf8..b47abc02474 100644
> --- gnu/usr.bin/clang/Makefile
> +++ gnu/usr.bin/clang/Makefile
> @@ -39,6 +39,11 @@ SUBDIR+=libclangSerialization
> SUBDIR+=libclangFrontend
> SUBDIR+=libclangRewriteFrontend
> SUBDIR+=libclangFrontendTool
> +SUBDIR+=libclangASTMatchers
> +SUBDIR+=libclangCrossTU
> +SUBDIR+=libclangStaticAnalyzer
> +SUBDIR+=libclangIndex
> +SUBDIR+=libclangTooling
>
> SUBDIR+=clang
>
> diff --git gnu/usr.bin/clang/clang/Makefile gnu/usr.bin/clang/clang/Makefile
> index 76535ee8842..7d3847f883d 100644
> --- gnu/usr.bin/clang/clang/Makefile
> +++ gnu/usr.bin/clang/clang/Makefile
> @@ -43,6 +43,11 @@ LLVM_LIBDEPS= LLVM \
> clangEdit \
> clangAST \
> clangLex \
> - clangBasic
> + clangBasic \
> + clangStaticAnalyzer \
> + clangCrossTU \
> + clangASTMatchers \
> + clangIndex \
> + clangTooling \
>
> .include
> diff --git gnu/usr.bin/clang/include/clang/Config/config.h
> gnu/usr.bin/clang/include/clang/Config/config.h
> index 02a049bf2be..93494d6a0b1 100644
> --- gnu/usr.bin/clang/include/clang/Config/config.h
> +++ gnu/usr.bin/clang/include/clang/Config/config.h
> @@ -78,7 +78,7 @@
> /* Enable each functionality of modules */
> #define CLANG_ENABLE_ARCMT 0
> #define CLANG_ENABLE_OBJC_REWRITER 0
> -#define CLANG_ENABLE_STATIC_ANALYZER 0
> +#define CLANG_ENABLE_STATIC_ANALYZER 1
>
> /* Spawn a new process clang.exe for the CC1 tool invocation, when necessary
> */
> #define CLANG_SPAWN_CC1 0
> diff --git gnu/usr.bin/clang/libclangASTMatchers/Makefile
> gnu/usr.bin/clang/libclangASTMatchers/Makefile
> new file mode 100644
> index 000..76c79c738cb
> --- /dev/null
> +++ gnu/usr.bin/clang/libclangASTMatchers/Makefile
> @@ -0,0 +1,25 @@
> +LIB= clangASTMatchers
> +NOPIC=
> +NOPROFILE=
> +
> +CPPFLAGS+=${CLANG_INCLUDES}
> +
> +.include
> +
> +# Core
> +SRCS+= ASTMatchFinder.cpp \
> + ASTMatchersInternal.cpp \
> + GtestMatchers.cpp \
> + Diagnostics.cpp \
> + Marshallers.cpp \
> + Parser.cpp \
> + Registry.cpp \
> + VariantValue.cpp \
> +
> +.PATH: ${.CURDIR}/../../../llvm/clang/lib/ASTMatchers
> +.PATH: ${.CURDIR}/../../../llvm/clang/lib/ASTMatchers/Dynamic
> +
> +install:
> + @# Nothing here so far ...
> +
> +.include
> diff --git gnu/usr.bin/clang/libclangAnalysis/Makefile
> gnu/usr.bin/clang/libclangAnalysis/Makefile
> index 25669a34cc0..7be18f24685 100644
> --- gnu/usr.bin/clang/libclangAnalysis/Makefile
> +++ gnu/usr.bin/clang/libclangAnalysis/Makefile
> @@ -23,6 +23,7 @@ SRCS= AnalysisDeclContext.cpp \
> ExprMutationAnalyzer.cpp \
> IssueHash.cpp \
> LiveVariables.cpp \
> + MacroExpansionContext.cpp \
> ObjCNoReturn.cpp \
> PathDiagnostic.cpp \
> PostOrderCFGView.cpp \
> diff --git gnu/usr.bin/clang/libclangCrossTU/Makefile
> gnu/usr.bin/clang/libclangCrossTU/Makefile
> new file mode 100644
> index 000..59541bce012
> --- /dev/null
> +++ gnu/usr.bin/clang/libclangCrossTU/Makefile
> @@ -0,0 +1,17 @@
> +LIB= clangCrossTU
> +NOPIC=
> +NOPROFILE=
> +
> +CPPFLAGS+= -I ${.CURDIR}/../../../llvm/clang/lib/CrossTU
> +CPPFLAGS+=${CLANG_INCLUDES}
> +
> +.include
> +
> +SRCS+= CrossTranslationUnit.cpp \
> +
> +.PATH: ${.CURDIR}/../../../llvm/clang/lib/CrossTU/
> +
> +install:
> + @# Nothing here so far ...
> +
> +.include
> diff --git gnu/usr.bin/clang/libclangIndex/Makefile
> gnu/usr.bin/clang/libclangIndex/Makefile
> new file mode 100644
> index 000..b31d906a5ee
> --- /dev/null
> +++ gnu/usr.bin/clang/libclangIndex/Makefile
> @@ -0,0 +1,18 @@
> +LIB= clangIndex
> +NOPIC=
> +NOPROFILE=
> +
> +CPPFLAGS+= -I ${.CURDIR}/../../../llvm/clang/lib/Index
> +CPPFLAGS+=${CLANG_INCLUDES}
> +
> +.include
> +
> +SRCS+= CommentToXML.cpp \
> + USRGeneration.cpp \
> +
> +.PATH: ${.CURDIR}/../../../llvm/clang/lib/Index/
> +
> +install:
> + @# Nothing here so far ...
> +
> +.include
> diff --git gnu/usr.bin/clang/libclangStaticAnalyzer/Makefile
>
Re: clang: compile static analyzer
On Fri, Jan 14, 2022 at 03:17:21PM +0100, Tobias Heider wrote:
> Hi,
>
> clang ships with a pretty useful static analyzer to find all kinds of bugs
> in C and C++ code:
>
> https://clang-analyzer.llvm.org/
>
> I use it regularly to check my own diffs and found plenty of bugs I could
> have missed otherwise. While we have the code in base we don't actually
> build it into our libclang currently, so the only ways to use it are
> manually modifying the Makefiles or installing llvm from ports.
>
> I was wondering if anyone else uses this and if there was any interest to
> have this in our base clang?
>
> diff --git gnu/usr.bin/clang/Makefile gnu/usr.bin/clang/Makefile
> index 6cf71d36cf8..b47abc02474 100644
> --- gnu/usr.bin/clang/Makefile
> +++ gnu/usr.bin/clang/Makefile
> @@ -39,6 +39,11 @@ SUBDIR+=libclangSerialization
> SUBDIR+=libclangFrontend
> SUBDIR+=libclangRewriteFrontend
> SUBDIR+=libclangFrontendTool
> +SUBDIR+=libclangASTMatchers
> +SUBDIR+=libclangCrossTU
> +SUBDIR+=libclangStaticAnalyzer
> +SUBDIR+=libclangIndex
> +SUBDIR+=libclangTooling
>
> SUBDIR+=clang
>
> diff --git gnu/usr.bin/clang/clang/Makefile gnu/usr.bin/clang/clang/Makefile
> index 76535ee8842..7d3847f883d 100644
> --- gnu/usr.bin/clang/clang/Makefile
> +++ gnu/usr.bin/clang/clang/Makefile
> @@ -43,6 +43,11 @@ LLVM_LIBDEPS= LLVM \
> clangEdit \
> clangAST \
> clangLex \
> - clangBasic
> + clangBasic \
> + clangStaticAnalyzer \
> + clangCrossTU \
> + clangASTMatchers \
> + clangIndex \
> + clangTooling \
>
> .include
> diff --git gnu/usr.bin/clang/include/clang/Config/config.h
> gnu/usr.bin/clang/include/clang/Config/config.h
> index 02a049bf2be..93494d6a0b1 100644
> --- gnu/usr.bin/clang/include/clang/Config/config.h
> +++ gnu/usr.bin/clang/include/clang/Config/config.h
> @@ -78,7 +78,7 @@
> /* Enable each functionality of modules */
> #define CLANG_ENABLE_ARCMT 0
> #define CLANG_ENABLE_OBJC_REWRITER 0
> -#define CLANG_ENABLE_STATIC_ANALYZER 0
> +#define CLANG_ENABLE_STATIC_ANALYZER 1
>
> /* Spawn a new process clang.exe for the CC1 tool invocation, when necessary
> */
> #define CLANG_SPAWN_CC1 0
> diff --git gnu/usr.bin/clang/libclangASTMatchers/Makefile
> gnu/usr.bin/clang/libclangASTMatchers/Makefile
> new file mode 100644
> index 000..76c79c738cb
> --- /dev/null
> +++ gnu/usr.bin/clang/libclangASTMatchers/Makefile
> @@ -0,0 +1,25 @@
> +LIB= clangASTMatchers
> +NOPIC=
> +NOPROFILE=
> +
> +CPPFLAGS+=${CLANG_INCLUDES}
> +
> +.include
> +
> +# Core
> +SRCS+= ASTMatchFinder.cpp \
> + ASTMatchersInternal.cpp \
> + GtestMatchers.cpp \
> + Diagnostics.cpp \
> + Marshallers.cpp \
> + Parser.cpp \
> + Registry.cpp \
> + VariantValue.cpp \
> +
> +.PATH: ${.CURDIR}/../../../llvm/clang/lib/ASTMatchers
> +.PATH: ${.CURDIR}/../../../llvm/clang/lib/ASTMatchers/Dynamic
> +
> +install:
> + @# Nothing here so far ...
> +
> +.include
> diff --git gnu/usr.bin/clang/libclangAnalysis/Makefile
> gnu/usr.bin/clang/libclangAnalysis/Makefile
> index 25669a34cc0..7be18f24685 100644
> --- gnu/usr.bin/clang/libclangAnalysis/Makefile
> +++ gnu/usr.bin/clang/libclangAnalysis/Makefile
> @@ -23,6 +23,7 @@ SRCS= AnalysisDeclContext.cpp \
> ExprMutationAnalyzer.cpp \
> IssueHash.cpp \
> LiveVariables.cpp \
> + MacroExpansionContext.cpp \
> ObjCNoReturn.cpp \
> PathDiagnostic.cpp \
> PostOrderCFGView.cpp \
> diff --git gnu/usr.bin/clang/libclangCrossTU/Makefile
> gnu/usr.bin/clang/libclangCrossTU/Makefile
> new file mode 100644
> index 000..59541bce012
> --- /dev/null
> +++ gnu/usr.bin/clang/libclangCrossTU/Makefile
> @@ -0,0 +1,17 @@
> +LIB= clangCrossTU
> +NOPIC=
> +NOPROFILE=
> +
> +CPPFLAGS+= -I ${.CURDIR}/../../../llvm/clang/lib/CrossTU
> +CPPFLAGS+=${CLANG_INCLUDES}
> +
> +.include
> +
> +SRCS+= CrossTranslationUnit.cpp \
> +
> +.PATH: ${.CURDIR}/../../../llvm/clang/lib/CrossTU/
> +
> +install:
> + @# Nothing here so far ...
> +
> +.include
> diff --git gnu/usr.bin/clang/libclangIndex/Makefile
> gnu/usr.bin/clang/libclangIndex/Makefile
> new file mode 100644
> index 000..b31d906a5ee
> --- /dev/null
> +++ gnu/usr.bin/clang/libclangIndex/Makefile
> @@ -0,0 +1,18 @@
> +LIB= clangIndex
> +NOPIC=
> +NOPROFILE=
> +
> +CPPFLAGS+= -I ${.CURDIR}/../../../llvm/clang/lib/Index
> +CPPFLAGS+=${CLANG_INCLUDES}
> +
> +.include
> +
> +SRCS+= CommentToXML.cpp \
> + USRGeneration.cpp \
> +
> +.PATH: ${.CURDIR}/../../../llvm/clang/lib/Index/
> +
> +install:
> + @# Nothing here so far ...
> +
> +.include
> diff --git gnu/usr.bin/clang/libclangStaticAnalyzer/Makefile
> gnu/usr.bin/clang/libclangStaticAnalyzer/Makefile
> new file mode 100644
> index 000..6d152afe283
> --- /dev/null
> +++ gnu/usr.bin/clang/libclangStaticAnalyzer/Makefile
>
Re: clang: compile static analyzer
On Fri, 14 Jan 2022 14:53:21 +, Visa Hankala wrote: > I think the tool is useful. However, installing it from ports is good > enough for me. Same here. - todd
Re: clang: compile static analyzer
On Fri, Jan 14, 2022 at 03:17:21PM +0100, Tobias Heider wrote: > Hi, > > clang ships with a pretty useful static analyzer to find all kinds of bugs > in C and C++ code: > > https://clang-analyzer.llvm.org/ > > I use it regularly to check my own diffs and found plenty of bugs I could > have missed otherwise. While we have the code in base we don't actually > build it into our libclang currently, so the only ways to use it are > manually modifying the Makefiles or installing llvm from ports. > > I was wondering if anyone else uses this and if there was any interest to > have this in our base clang? I think the tool is useful. However, installing it from ports is good enough for me. How much would this addition increase the build time and space usage of the finished sets?
clang: compile static analyzer
Hi,
clang ships with a pretty useful static analyzer to find all kinds of bugs
in C and C++ code:
https://clang-analyzer.llvm.org/
I use it regularly to check my own diffs and found plenty of bugs I could
have missed otherwise. While we have the code in base we don't actually
build it into our libclang currently, so the only ways to use it are
manually modifying the Makefiles or installing llvm from ports.
I was wondering if anyone else uses this and if there was any interest to
have this in our base clang?
diff --git gnu/usr.bin/clang/Makefile gnu/usr.bin/clang/Makefile
index 6cf71d36cf8..b47abc02474 100644
--- gnu/usr.bin/clang/Makefile
+++ gnu/usr.bin/clang/Makefile
@@ -39,6 +39,11 @@ SUBDIR+=libclangSerialization
SUBDIR+=libclangFrontend
SUBDIR+=libclangRewriteFrontend
SUBDIR+=libclangFrontendTool
+SUBDIR+=libclangASTMatchers
+SUBDIR+=libclangCrossTU
+SUBDIR+=libclangStaticAnalyzer
+SUBDIR+=libclangIndex
+SUBDIR+=libclangTooling
SUBDIR+=clang
diff --git gnu/usr.bin/clang/clang/Makefile gnu/usr.bin/clang/clang/Makefile
index 76535ee8842..7d3847f883d 100644
--- gnu/usr.bin/clang/clang/Makefile
+++ gnu/usr.bin/clang/clang/Makefile
@@ -43,6 +43,11 @@ LLVM_LIBDEPS=LLVM \
clangEdit \
clangAST \
clangLex \
- clangBasic
+ clangBasic \
+ clangStaticAnalyzer \
+ clangCrossTU \
+ clangASTMatchers \
+ clangIndex \
+ clangTooling \
.include
diff --git gnu/usr.bin/clang/include/clang/Config/config.h
gnu/usr.bin/clang/include/clang/Config/config.h
index 02a049bf2be..93494d6a0b1 100644
--- gnu/usr.bin/clang/include/clang/Config/config.h
+++ gnu/usr.bin/clang/include/clang/Config/config.h
@@ -78,7 +78,7 @@
/* Enable each functionality of modules */
#define CLANG_ENABLE_ARCMT 0
#define CLANG_ENABLE_OBJC_REWRITER 0
-#define CLANG_ENABLE_STATIC_ANALYZER 0
+#define CLANG_ENABLE_STATIC_ANALYZER 1
/* Spawn a new process clang.exe for the CC1 tool invocation, when necessary */
#define CLANG_SPAWN_CC1 0
diff --git gnu/usr.bin/clang/libclangASTMatchers/Makefile
gnu/usr.bin/clang/libclangASTMatchers/Makefile
new file mode 100644
index 000..76c79c738cb
--- /dev/null
+++ gnu/usr.bin/clang/libclangASTMatchers/Makefile
@@ -0,0 +1,25 @@
+LIB= clangASTMatchers
+NOPIC=
+NOPROFILE=
+
+CPPFLAGS+= ${CLANG_INCLUDES}
+
+.include
+
+# Core
+SRCS+= ASTMatchFinder.cpp \
+ ASTMatchersInternal.cpp \
+ GtestMatchers.cpp \
+ Diagnostics.cpp \
+ Marshallers.cpp \
+ Parser.cpp \
+ Registry.cpp \
+ VariantValue.cpp \
+
+.PATH: ${.CURDIR}/../../../llvm/clang/lib/ASTMatchers
+.PATH: ${.CURDIR}/../../../llvm/clang/lib/ASTMatchers/Dynamic
+
+install:
+ @# Nothing here so far ...
+
+.include
diff --git gnu/usr.bin/clang/libclangAnalysis/Makefile
gnu/usr.bin/clang/libclangAnalysis/Makefile
index 25669a34cc0..7be18f24685 100644
--- gnu/usr.bin/clang/libclangAnalysis/Makefile
+++ gnu/usr.bin/clang/libclangAnalysis/Makefile
@@ -23,6 +23,7 @@ SRCS= AnalysisDeclContext.cpp \
ExprMutationAnalyzer.cpp \
IssueHash.cpp \
LiveVariables.cpp \
+ MacroExpansionContext.cpp \
ObjCNoReturn.cpp \
PathDiagnostic.cpp \
PostOrderCFGView.cpp \
diff --git gnu/usr.bin/clang/libclangCrossTU/Makefile
gnu/usr.bin/clang/libclangCrossTU/Makefile
new file mode 100644
index 000..59541bce012
--- /dev/null
+++ gnu/usr.bin/clang/libclangCrossTU/Makefile
@@ -0,0 +1,17 @@
+LIB= clangCrossTU
+NOPIC=
+NOPROFILE=
+
+CPPFLAGS+= -I ${.CURDIR}/../../../llvm/clang/lib/CrossTU
+CPPFLAGS+= ${CLANG_INCLUDES}
+
+.include
+
+SRCS+= CrossTranslationUnit.cpp \
+
+.PATH: ${.CURDIR}/../../../llvm/clang/lib/CrossTU/
+
+install:
+ @# Nothing here so far ...
+
+.include
diff --git gnu/usr.bin/clang/libclangIndex/Makefile
gnu/usr.bin/clang/libclangIndex/Makefile
new file mode 100644
index 000..b31d906a5ee
--- /dev/null
+++ gnu/usr.bin/clang/libclangIndex/Makefile
@@ -0,0 +1,18 @@
+LIB= clangIndex
+NOPIC=
+NOPROFILE=
+
+CPPFLAGS+= -I ${.CURDIR}/../../../llvm/clang/lib/Index
+CPPFLAGS+= ${CLANG_INCLUDES}
+
+.include
+
+SRCS+= CommentToXML.cpp \
+ USRGeneration.cpp \
+
+.PATH: ${.CURDIR}/../../../llvm/clang/lib/Index/
+
+install:
+ @# Nothing here so far ...
+
+.include
diff --git gnu/usr.bin/clang/libclangStaticAnalyzer/Makefile
gnu/usr.bin/clang/libclangStaticAnalyzer/Makefile
new file mode 100644
index 000..6d152afe283
--- /dev/null
+++ gnu/usr.bin/clang/libclangStaticAnalyzer/Makefile
@@ -0,0 +1,206 @@
+LIB= clangStaticAnalyzer
+NOPIC=
+NOPROFILE=
+
+CPPFLAGS+= -I ${.CURDIR}/../../../llvm/clang/lib/StaticAnalyzer/Checkers
+CPPFLAGS+= ${CLANG_INCLUDES}
+
+.include
+
+# Core
+SRCS+= APSIntType.cpp \
+ AnalysisManager.cpp \
+ AnalyzerOptions.cpp \
+ BasicValueFactory.cpp \
+ BlockCounter.cpp \
+
