[Support] Don't print stacktrace if DbgHelp.dll hasn't been loaded yet

On Windows certain function from `Signals.h` require that `DbgHelp.dll` is loaded. This typically happens when the main program

[Support] Don't print stacktrace if DbgHelp.dll hasn't been loaded yet

On Windows certain function from `Signals.h` require that `DbgHelp.dll` is loaded. This typically happens when the main program calls `llvm::InitLLVM`, however in some cases main program doesn't do that (e.g. when the application is using LLDB via `liblldb.dll`). This patch adds a safe guard to prevent crashes. More discussion in
https://reviews.llvm.org/D119009.

Reviewed By: aganea

Differential Revision: https://reviews.llvm.org/D119181

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
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

show more ...

Add the 'googlemock' component of Google Test to LLVM's unittest libraries.

I have two immediate motivations for adding this:
1) It makes writing expectations in tests *dramatically* easier. A
qu

Add the 'googlemock' component of Google Test to LLVM's unittest libraries.

I have two immediate motivations for adding this:
1) It makes writing expectations in tests *dramatically* easier. A
quick example that is a taste of what is possible:

std::vector<int> v = ...;
EXPECT_THAT(v, UnorderedElementsAre(1, 2, 3));

This checks that v contains '1', '2', and '3' in some order. There
are a wealth of other helpful matchers like this. They tend to be
highly generic and STL-friendly so they will in almost all cases work
out of the box even on custom LLVM data structures.

I actually find the matcher syntax substantially easier to read even
for simple assertions:

EXPECT_THAT(a, Eq(b));
EXPECT_THAT(b, Ne(c));

Both of these make it clear what is being *tested* and what is being
*expected*. With `EXPECT_EQ` this is implicit (the LHS is expected,
the RHS is tested) and often confusing. With `EXPECT_NE` it is just
not clear. Even the failure error messages are superior with the
matcher based expectations.

2) When testing any kind of generic code, you are continually defining
dummy types with interfaces and then trying to check that the
interfaces are manipulated in a particular way. This is actually what
mocks are *good* for -- testing *interface interactions*. With
generic code, there is often no "fake" or other object that can be
used.

For a concrete example of where this is currently causing significant
pain, look at the pass manager unittests which are riddled with
counters incremented when methods are called. All of these could be
replaced with mocks. The result would be more effective at testing
the code by having tighter constraints. It would be substantially
more readable and maintainable when updating the code. And the error
messages on failure would have substantially more information as
mocks automatically record stack traces and other information *when
the API is misused* instead of trying to diagnose it after the fact.

I expect that #1 will be the overwhelming majority of the uses of gmock,
but I think that is sufficient to justify having it. I would actually
like to update the coding standards to encourage the use of matchers
rather than any other form of `EXPECT_...` macros as they are IMO
a strict superset in terms of functionality and readability.

I think that #2 is relatively rarely useful, but there *are* cases where
it is useful. Historically, I think misuse of actual mocking as
described in #2 has led to resistance towards this framework. I am
actually sympathetic to this -- mocking can easily be overused. However
I think this is not a significant concern in LLVM. First and foremost,
LLVM has very careful and rare exposure of abstract interfaces or
dependency injection, which are the most prone to abuse with mocks. So
there are few opportunities to abuse them. Second, a large fraction of
LLVM's unittests are testing *generic code* where mocks actually make
tremendous sense. And gmock is well suited to building interfaces that
exercise generic libraries. Finally, I still think we should be willing
to have testing utilities in tree even if they should be used rarely. We
can use code review to help guide the usage here.

For a longer and more complete discussion of this, see the llvm-dev
thread here:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/108672.html

The general consensus seems that this is a reasonable direction to start
down, but that doesn't mean we should race ahead and use this
everywhere. I have one test that is blocked on this to land and that was
specifically used as an example. Before widespread adoption, I'm going
to work up some (brief) guidelines as some of these facilities should be
used sparingly and carefully.

Differential Revision: https://reviews.llvm.org/D28156

llvm-svn: 291606

show more ...

Search for llvm-symbolizer binary in the same directory as argv[0], before
looking for it along $PATH. This allows installs of LLVM tools outside of
$PATH to find the symbolizer and produce pretty ba

Search for llvm-symbolizer binary in the same directory as argv[0], before
looking for it along $PATH. This allows installs of LLVM tools outside of
$PATH to find the symbolizer and produce pretty backtraces if they crash.

llvm-svn: 272232

show more ...

Make UnitTestMain/TestMain.cpp free from llvm/Config/config.h.

llvm/Config/config.h is unavailable outside of build tree.

llvm-svn: 241523

Add boolean to PrintStackTraceOnErrorSignal to disable crash reporting.

The current crash reporting on Mac OS is only disabled via an environment variable.
This adds a boolean (default false) which

Add boolean to PrintStackTraceOnErrorSignal to disable crash reporting.

The current crash reporting on Mac OS is only disabled via an environment variable.
This adds a boolean (default false) which can also disable crash reporting.

The only client right now is the unittests which don't ever want crash reporting, but do want to detect killed programs.

Reduces the time to run the APFloat unittests on my machine from

[----------] 47 tests from APFloatTest (51250 ms total)

to

[----------] 47 tests from APFloatTest (765 ms total)

Reviewed by Reid Kleckner and Justin Bogner

llvm-svn: 234353

show more ...

Try to fix ProgramTest on FreeBSD

This seemed like the cleanest way to find the test executable. Also fix
the file mode.

llvm-svn: 180770

Add basic command line parsing to TestMain.

Summary:
This allows unit tests for components that use Support/Debug.h to print
debug information from test runs by specifying -debug when running the
te

Add basic command line parsing to TestMain.

Summary:
This allows unit tests for components that use Support/Debug.h to print
debug information from test runs by specifying -debug when running the
test.

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D301

llvm-svn: 172801

show more ...

Make Win32's header file name lower for cross build on case-sensitive filesystem.

llvm-svn: 124864

Merge System into Support.

llvm-svn: 120298

Fix MSVC release mode compilation error.

llvm-svn: 115407

Fix line endings from my last commit.

llvm-svn: 114728

unittests: Support Windows.

llvm-svn: 114727

Move unittest driver to utils/unittest/UnitTestMain.
- This eliminates a race between building the unittests and linking the
UnitTestMain library.

llvm-svn: 81719