| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
ref:
https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertEqual
|
|
Fixes #106761.
|
|
Install scan-build-py modules into the plain `lib` directory,
without LLVM_LIBDIR_SUFFIX appended, to match the path expected
by `intercept-build` executable. This fixes the program being unable
to find its modules. Using unsuffixed path makes sense here, since
Python modules are not subject to multilib.
This change effectively reverts 1334e129a39cb427e7b855e9a711a3e7604e50e5.
The commit in question changed the path without a clear justification
("does not respect the given prefix") and the Python code was never
modified to actually work with the change.
Fixes #106608
|
|
This patch remove 36 checks for compiler flags that are done via
invoking the compiler across LLVM, Clang, and LLDB. It's was made
possible by raising the bar for supported compilers that has been
happening over the years since the checks were added.
This is going to improve CMake configuration times. This topic was
highlighted in
https://discourse.llvm.org/t/cmake-compiler-flag-checks-are-really-slow-ideas-to-speed-them-up/78882.
|
|
This reverts commit d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6.
Adds the patch by @hans from
https://github.com/llvm/llvm-project/issues/62719
This patch fixes the Windows build.
d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 reverted the reviews
D144509 [CMake] Bumps minimum version to 3.20.0.
This partly undoes D137724.
This change has been discussed on discourse
https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193
Note this does not remove work-arounds for older CMake versions, that
will be done in followup patches.
D150532 [OpenMP] Compile assembly files as ASM, not C
Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent)
when compiling a file which has been set as having the language
C. This behaviour change only takes place if "cmake_minimum_required"
is set to 3.20 or newer, or if the policy CMP0119 is set to new.
Attempting to compile assembly files with "-x c" fails, however
this is workarounded in many cases, as OpenMP overrides this with
"-x assembler-with-cpp", however this is only added for non-Windows
targets.
Thus, after increasing cmake_minimum_required to 3.20, this breaks
compiling the GNU assembly for Windows targets; the GNU assembly is
used for ARM and AArch64 Windows targets when building with Clang.
This patch unbreaks that.
D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump
The build uses other mechanism to select the runtime.
Fixes #62719
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D151344
|
|
This is an ongoing series of commits that are reformatting our
Python code.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: MatzeB
Differential Revision: https://reviews.llvm.org/D150761
|
|
This reverts commit 65429b9af6a2c99d340ab2dcddd41dab201f399c.
Broke several projects, see https://reviews.llvm.org/D144509#4347562 onwards.
Also reverts follow-up commit "[OpenMP] Compile assembly files as ASM, not C"
This reverts commit 4072c8aee4c89c4457f4f30d01dc9bb4dfa52559.
Also reverts fix attempt "[cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump"
This reverts commit 7d47dac5f828efd1d378ba44a97559114f00fb64.
|
|
The owner of the last two failing buildbots updated CMake.
This reverts commit e8e8707b4aa6e4cc04c0cffb2de01d2de71165fc.
|
|
Unfortunatly not all buildbots are updated.
This reverts commit ffb807ab5375b3f78df198dc5d4302b3b552242f.
|
|
All build bots should be updated now.
This reverts commit 44d38022ab29a3156349602733b3459df5beef93.
|
|
This reverts commit 1ef4c3c859728008cf707cad8d67f45ae5070ae1.
Two buildbots still haven't been updated.
|
|
This reverts commit 92523a35a827539db8557bbc3ecab7f9ea3f6ade.
Reland to see whether CIs are updated.
|
|
This reverts commit a72165e5df59032cdd54dcb18155f2630d73abd1.
Some buildbots have not been updated yet.
|
|
This reverts commit 92523a35a827539db8557bbc3ecab7f9ea3f6ade.
Test whether all CI runners are updated.
|
|
Some build bots have not been updated to the new minimal CMake version.
Reverting for now and ping the buildbot owners.
This reverts commit 44c6b905f8527635e49bb3ea97dea315f92d38ec.
|
|
This partly undoes D137724.
This change has been discussed on discourse
https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193
Note this does not remove work-arounds for older CMake versions, that
will be done in followup patches.
Reviewed By: mehdi_amini, MaskRay, ChuanqiXu, to268, thieta, tschuett, phosek, #libunwind, #libc_vendors, #libc, #libc_abi, sivachandra, philnik, zibi
Differential Revision: https://reviews.llvm.org/D144509
|
|
some regular files(e.g. files have no shebang and no execute
bit in source dir) are wrongly assigned an execution permission,
such as scanview.css and ear.c from libscanbuild, which is
unnecessary and introduces warnings in some envs.
Reviewed By: MaskRay, phosek
Differential Revision: https://reviews.llvm.org/D133308
|
|
met this issue when building llvm with config LLVM_LIBDIR_SUFFIX=64, and
the installation destination of scan-build-py does not respect the given
suffix.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D133160
|
|
As proposed in D126215 (ffe7950ebc62380c3afc7c71f454a1db3f6f5c76),
I'm dropping the `-analyzer-store` and
`-analyzer-opt-analyze-nested-blocks` clang frontend flags.
I'm also dropping the corresponding commandline handlers of `scanbuild`.
This behavior is planned to be part of `clang-16`.
Reviewed By: xazax.hun
Differential Revision: https://reviews.llvm.org/D132289
|
|
This reverts commit f7a33090a91015836497c75f173775392ab0304d.
Unfortunately this causes a number of failures that didn't show up in my
local build.
|
|
We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it.
Now we return this.
`LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set
`CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed
entirely.
I imagine this is too potentially-breaking to make LLVM 15. That's fine.
I have a more minimal version of this in the disto (NixOS) patches for
LLVM 15 (like previous versions). This more expansive version I will
test harder after the release is cut.
Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D130586
|
|
I went over the output of the following mess of a command:
(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z |
parallel --xargs -0 cat | aspell list --mode=none --ignore-case |
grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n |
grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)
and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).
Differential Revision: https://reviews.llvm.org/D130827
|
|
When running scan-build-py's analyze-build script with output format set
to sarif & html it wants to print a message on how to look at the
defects mentioning the directory name twice.
But the path argument was only given once to the logging function,
causing "TypeError: not enough arguments for format string" exception.
Differential Revision: https://reviews.llvm.org/D126974
|
|
The "#!" line in all scan-build-py scripts were using just bare
"/usr/bin/python" which according to PEP-0394 can be either python3,
python2 or not exist at all.
E.g in latest debian and ubuntu releases "/usr/bin/python" does not
exist at all by default and user must install python-is-python2 or
python-is-python3 packages to get the bare version less "python"
command.
Until recently (70b06fe8a186 "scan-build-py: Force the opening in utf-8"
changed "libscanbuild") these scripts worked in both python2 and
python3, but now they (rightfully) are python3 only, and broke on
systems where the "python" command means python2.
By changing the "#!" to be "python3" it is not only explicit that the
scripts require python3 it also works on systems where "python" command
is python2 or nonexistent.
Differential Revision: https://reviews.llvm.org/D126804
|
|
We experienced some deadlocks when we used multiple threads for logging
using `scan-builds` intercept-build tool when we used multiple threads by
e.g. logging `make -j16`
```
(gdb) bt
#0 0x00007f2bb3aff110 in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f2bb3af70a3 in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f2bb3d152e4 in ?? ()
#3 0x00007ffcc5f0cc80 in ?? ()
#4 0x00007f2bb3d2bf5b in ?? () from /lib64/ld-linux-x86-64.so.2
#5 0x00007f2bb3b5da27 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#6 0x00007f2bb3b5dbe0 in exit () from /lib/x86_64-linux-gnu/libc.so.6
#7 0x00007f2bb3d144ee in ?? ()
#8 0x746e692f706d742f in ?? ()
#9 0x692d747065637265 in ?? ()
#10 0x2f653631326b3034 in ?? ()
#11 0x646d632e35353532 in ?? ()
#12 0x0000000000000000 in ?? ()
```
I think the gcc's exit call caused the injected `libear.so` to be unloaded
by the `ld`, which in turn called the `void on_unload() __attribute__((destructor))`.
That tried to acquire an already locked mutex which was left locked in the
`bear_report_call()` call, that probably encountered some error and
returned early when it forgot to unlock the mutex.
All of these are speculation since from the backtrace I could not verify
if frames 2 and 3 are in fact corresponding to the `libear.so` module.
But I think it's a fairly safe bet.
So, hereby I'm releasing the held mutex on *all paths*, even if some failure
happens.
PS: I would use lock_guards, but it's C.
Reviewed-by: NoQ
Differential Revision: https://reviews.llvm.org/D118439
|
|
I am breaking apart D99484 so the cause of build failures is easier to
understand.
Differential Revision: https://reviews.llvm.org/D117419
|
|
https://lab.llvm.org/buildbot/#/builders/46/builds/21146 Still have
this odd error, not sure how to reproduce, so I will just try breaking
up my patch.
This reverts commit 4a678f8072004eff9214c1a4e1836a14abb69535.
|
|
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece!
It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up
- Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested.
- Converting all the packages, not just LLVM, effecting many more projects than LLVM itself.
I figured it was time to make a new revision.
I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful.
---
As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`.
These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder.
Reviewed By: #libunwind, #libc, #libc_abi, compnerd
Differential Revision: https://reviews.llvm.org/D99484
|
|
Sorry for the disruption, I will try again later.
This reverts commit efeb50197091b2ade24c00b9d55814bc433a7fd1.
|
|
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece!
It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up
- Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested.
- Converting all the packages, not just LLVM, effecting many more projects than LLVM itself.
I figured it was time to make a new revision.
I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful.
---
As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`.
These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder.
Reviewed By: #libunwind, #libc, #libc_abi, compnerd
Differential Revision: https://reviews.llvm.org/D99484
|
|
Fix https://bugs.llvm.org/show_bug.cgi?id=51897
Differential Revision: https://reviews.llvm.org/D110521
|
|
Once installed, scan-build-py doesn't know anything about its auxiliary
executable and can't find them.
Use relative path wrt. scan-build-py script.
Differential Revision: https://reviews.llvm.org/D109659
|
|
It fails on ubuntu bionic otherwise with:
```
scan-build-py-14: Run 'scan-view /tmp/scan-build-2021-08-09-09-14-36-765350-nx9s888s' to examine bug reports.
scan-build-py-14: Internal error.
Traceback (most recent call last):
File "/usr/lib/llvm-14/lib/libscanbuild/__init__.py", line 125, in wrapper
return function(*args, **kwargs)
File "/usr/lib/llvm-14/lib/libscanbuild/analyze.py", line 72, in scan_build
number_of_bugs = document(args)
File "/usr/lib/llvm-14/lib/libscanbuild/report.py", line 35, in document
for bug in read_bugs(args.output, html_reports_available):
File "/usr/lib/llvm-14/lib/libscanbuild/report.py", line 282, in read_bugs
for bug in parser(bug_file):
File "/usr/lib/llvm-14/lib/libscanbuild/report.py", line 421, in parse_bug_html
for line in handler.readlines():
File "/usr/lib/python3.6/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3360: ordinal not in range(128)
scan-build-py-14: Please run this command again and turn on verbose mode (add '-vvvv' as argument).
```
I guess it is caused by a problem in Python 3.6
Reviewed By: phosek, isthismyaccount
Differential Revision: https://reviews.llvm.org/D107887
|
|
A new revision identical to https://reviews.llvm.org/D101139
The parent revision of aforementioned revision seems to cause pre-merge checks to fail opaquely. Seeing if creating a new revision will work.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D104138
|
|
Update scan-build-py to be able to trigger sarif-html output format in clang static analyzer.
NOTE: testcase `test_sarif_and_html_creates_sarif_and_html_reports` will fail if the default clang does not have change https://reviews.llvm.org/D96389 . This can be remediated by pointing the default clang in arguments.py to a locally built clang. I was unable to figure out where these particular tests for scan-build-py are being invoked (aside from manually), so any help there would be greatly appreciated.
Reviewed By: aabbaabb, xazax.hun
Differential Revision: https://reviews.llvm.org/D96570
|
|
clang static analysis reports can be generated in html, plist, or sarif
format. This updates scan-build-py to be able to specify SARIF as the
desired output format, as previously it only support plist and html
formats.
Differential Revision: https://reviews.llvm.org/D94251
|
|
Differential Revision: https://www.youtube.com/watch?v=RsL0cipURA0
|
|
Excluded folders in scan build is turned to absolute path before
comapre to 'file' in cdb. 'file' in cdb might be a path relative
to 'directory', so we need to turn it to absolute path before
comparison.
Patch by Yu Shan
Differential Revision: https://reviews.llvm.org/D90362
|
|
Recent versions of python3's multiprocessing module will blow up with
a Runtime error from this code, saying:
An attempt has been made to start a new process before the
current process has finished its bootstrapping phase
This is becuae the wrappers in bin/ are not using the `__name__ == "__main__"` idiom correctly.
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D87051
|
|
This upgrade should be friction-less because we've already been ensuring
that CMake >= 3.13.4 is used.
This is part of the effort discussed on llvm-dev here:
http://lists.llvm.org/pipermail/llvm-dev/2020-April/140578.html
Differential Revision: https://reviews.llvm.org/D78648
|
|
* Unhandled exceptions
* Typos
Differential Revision: https://reviews.llvm.org/D70693
|
|
The python documentation says "it’s highly recommended that you use raw strings for all but the simplest expressions." (https://docs.python.org/3/library/re.html)
So do that with the attached patch generated by
sed -i -e "s/re.search('/re.search(r'/g" $(git grep -l 're.search(')
The warning can be seen in e.g. python3.7:
$ python3.7 -Wd
>>> import re; re.search('\s', '')
<stdin>:1: DeprecationWarning: invalid escape sequence \s
Commited on behalf of Marco Falke.
Differential Revision: https://reviews.llvm.org/D57528
llvm-svn: 353707
|
|
llvm-svn: 351651
|
|
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
external functions
Summary: This is just changing naming and documentation to be general about external definitions that can be imported for cross translation unit analysis. There is at least a plan to add VarDecls: D46421
Reviewers: NoQ, xazax.hun, martong, a.sidorin, george.karpenkov, serge-sans-paille
Reviewed By: xazax.hun, martong
Subscribers: mgorny, whisperity, baloghadamsoftware, szepet, rnkovacs, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D56441
llvm-svn: 350852
|
|
Make scripts more future-proof by importing most __future__ stuff.
Differential Revision: https://reviews.llvm.org/D55208
llvm-svn: 349504
|
|
Using from __future__ import print_function it is possible to have a compatible behavior of `print(...)` across Python version.
Differential Revision: https://reviews.llvm.org/D55213
llvm-svn: 349454
|
|
Ubigraph project has been dead since about 2008, and to the best of my
knowledge, no one was using it.
Previously, I wasn't able to launch the existing binary at all.
Differential Revision: https://reviews.llvm.org/D51655
llvm-svn: 341601
|
|
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
|
|
Originally submitted as r326323 and r326324.
Reverted in r326432.
Reverting the commit was a mistake.
The breakage was due to invalid build files in our internal buildsystem,
CMakeLists did not have any cyclic dependencies.
llvm-svn: 326439
|
