I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.
I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.
This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.
Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).
llvm-svn: 304787
Summary:
This allows to keep handlers installed by sanitizers.
In other cases third-party code can replace handlers after libFuzzer
initialization anyway.
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33522
llvm-svn: 303828
This has been mysteriously failing since r301593, which cleaned up the
types of things like size_t and SIZE_MAX for freestanding targets. Reid
and Kostya suggested marking it as UNSUPPORTED on windows, given that no
one has been able to reproduce locally.
llvm-svn: 301719
The test fails on Darwin because Fuzzer::DeathCallback (which calls
DumpCurrentUnit("crash-")) is called before DumpCurrentUnit("oom-") is
called in Fuzzer::RssLimitCallback. DeathCallback is transitively called
from __sanitizer_print_memory_profile.
This should fix the fuzzer bot that has been failing for a while:
http://lab.llvm.org:8080/green/job/libFuzzer/
llvm-svn: 300127
We need to export external functions so they are found when calling
GetProcAddress() on Windows. But we can't use `__declspec(dllexport)` because
we want the targets to be completely independent from the fuzz engines and don't
depend on other header files. Also, we don't want to include platform specific
code managed with conditional macros.
So, the solution is to add the exported symbols with linker flags in cmake.
Differential revision: https://reviews.llvm.org/D29752
llvm-svn: 294688
We should always use unsigned long long to ensure 64 bits. On Windows, unsigned
long is 4 bytes. This was the reason why value-profile-cmp4.test was failing on
Windows.
Differential Revision: https://reviews.llvm.org/D29617
llvm-svn: 294390
Update cmake to use a custom target TestBinaries instead of a list of targets.
This simplifies cmake, and fix some errors. This way, we don't have to propagate
the values into parents directories. We only need to use add_dependencies.
Differential Revision: https://reviews.llvm.org/D29593
llvm-svn: 294389
On Windows, executables with the word "uninst" included in their names are
associated with administrator privileges.
Differential Revision: https://reviews.llvm.org/D29549
llvm-svn: 294387
Kostya Serebryany