update googletests (nw)

3rdparty/googletest/.gitignore

@@ -0,0 +1,2 @@
+# Ignore CI build directory
+build/

3rdparty/googletest/.travis.yml

@@ -2,29 +2,29 @@
 # http://about.travis-ci.org/docs/user/build-configuration/
 # This file can be validated on:
 # http://lint.travis-ci.org/
-# See also
-# http://stackoverflow.com/questions/22111549/travis-ci-with-clang-3-4-and-c11/30925448#30925448
-# to allow C++11, though we are not yet building with -std=c++11
 
 install:
 # /usr/bin/gcc is 4.6 always, but gcc-X.Y is available.
 - if [ "$CXX" = "g++" ]; then export CXX="g++-4.9" CC="gcc-4.9"; fi
-# /usr/bin/clang is our version already, and clang-X.Y does not exist.
+# /usr/bin/clang is 3.4, lets override with modern one.
-#- if [ "$CXX" = "clang++" ]; then export CXX="clang++-3.7" CC="clang-3.7"; fi
+- if [ "$CXX" = "clang++" ] && [ "$TRAVIS_OS_NAME" = "linux" ]; then export CXX="clang++-3.7" CC="clang-3.7"; fi
 - echo ${PATH}
-- ls /usr/local
-- ls /usr/local/bin
-- export PATH=/usr/local/bin:/usr/bin:${PATH}
 - echo ${CXX}
 - ${CXX} --version
+- ${CXX} -v
 addons:
   apt:
+    # List of whitelisted in travis packages for ubuntu-precise can be found here:
+    #   https://github.com/travis-ci/apt-package-whitelist/blob/master/ubuntu-precise
+    # List of whitelisted in travis apt-sources:
+    #   https://github.com/travis-ci/apt-source-whitelist/blob/master/ubuntu.json
     sources:
     - ubuntu-toolchain-r-test
+    - llvm-toolchain-precise-3.7
     packages:
     - gcc-4.9
     - g++-4.9
-    - clang
+    - clang-3.7
     - valgrind
 os:
   - linux

3rdparty/googletest/CMakeLists.txt

@@ -0,0 +1,16 @@
+cmake_minimum_required(VERSION 2.6.2)
+
+project( googletest-distribution )
+
+enable_testing()
+
+option(BUILD_GTEST "Builds the googletest subproject" OFF)
+
+#Note that googlemock target already builds googletest
+option(BUILD_GMOCK "Builds the googlemock subproject" ON)
+
+if(BUILD_GMOCK)
+  add_subdirectory( googlemock )
+elseif(BUILD_GTEST)
+  add_subdirectory( googletest )
+endif()

3rdparty/googletest/README.md

@@ -14,6 +14,9 @@ mailing list for questions, discussions, and development.  There is
 also an IRC channel on OFTC (irc.oftc.net) #gtest available.  Please
 join us!
 
+Getting started information for **Google Test** is available in the 
+[Google Test Primer](googletest/docs/Primer.md) documentation.
+
 **Google Mock** is an extension to Google Test for writing and using C++ mock
 classes.  See the separate [Google Mock documentation](googlemock/README.md).
 
@@ -53,7 +56,7 @@ the following notable projects:
   * The [Chromium projects](http://www.chromium.org/) (behind the Chrome
     browser and Chrome OS).
   * The [LLVM](http://llvm.org/) compiler.
-  * [Protocol Buffers](http://code.google.com/p/protobuf/), Google's data
+  * [Protocol Buffers](https://github.com/google/protobuf), Google's data
     interchange format.
   * The [OpenCV](http://opencv.org/) computer vision library.
 
@@ -66,7 +69,7 @@ Test UI is written in C#.
 
 [GTest TAP Listener](https://github.com/kinow/gtest-tap-listener) is an event
 listener for Google Test that implements the
-[TAP protocol](http://en.wikipedia.org/wiki/Test_Anything_Protocol) for test
+[TAP protocol](https://en.wikipedia.org/wiki/Test_Anything_Protocol) for test
 result output. If your test runner understands TAP, you may find it useful.
 
 ## Requirements ##
@@ -102,7 +105,7 @@ package (as described below):
 ### Mac OS X Requirements ###
 
   * Mac OS X v10.4 Tiger or newer
-  * XCode Developer Tools
+  * Xcode Developer Tools
 
 ### Requirements for Contributors ###
 
@@ -110,9 +113,9 @@ We welcome patches.  If you plan to contribute a patch, you need to
 build Google Test and its own tests from a git checkout (described
 below), which has further requirements:
 
-  * [Python](http://python.org/) v2.3 or newer (for running some of
+  * [Python](https://www.python.org/) v2.3 or newer (for running some of
     the tests and re-generating certain source files from templates)
-  * [CMake](http://www.cmake.org/) v2.6.4 or newer
+  * [CMake](https://cmake.org/) v2.6.4 or newer
 
 ## Regenerating Source Files ##
 

3rdparty/googletest/googlemock/CMakeLists.txt

@@ -92,6 +92,22 @@ cxx_library(gmock_main
             src/gmock-all.cc
             src/gmock_main.cc)
 
+# If the CMake version supports it, attach header directory information
+# to the targets for when we are part of a parent build (ie being pulled
+# in via add_subdirectory() rather than being a standalone build).
+if (DEFINED CMAKE_VERSION AND NOT "${CMAKE_VERSION}" VERSION_LESS "2.8.11")
+  target_include_directories(gmock      INTERFACE "${gmock_SOURCE_DIR}/include")
+  target_include_directories(gmock_main INTERFACE "${gmock_SOURCE_DIR}/include")
+endif()
+
+########################################################################
+#
+# Install rules
+install(TARGETS gmock gmock_main
+  DESTINATION lib)
+install(DIRECTORY ${gmock_SOURCE_DIR}/include/gmock
+  DESTINATION include)
+
 ########################################################################
 #
 # Google Mock's own tests.

3rdparty/googletest/googlemock/README.md

@@ -78,7 +78,7 @@ posting a question on the
 
 Google Mock is not a testing framework itself.  Instead, it needs a
 testing framework for writing tests.  Google Mock works seamlessly
-with [Google Test](http://code.google.com/p/googletest/), butj
+with [Google Test](http://code.google.com/p/googletest/), but
 you can also use it with [any C++ testing framework](googlemock/ForDummies.md#Using_Google_Mock_with_Any_Testing_Framework).
 
 ### Requirements for End Users ###

3rdparty/googletest/googlemock/docs/CheatSheet.md

@@ -77,7 +77,7 @@ The typical flow is:
   1. Create the mock objects.
   1. Optionally, set the default actions of the mock objects.
   1. Set your expectations on the mock objects (How will they be called? What wil they do?).
-  1. Exercise code that uses the mock objects; if necessary, check the result using [Google Test](http://code.google.com/p/googletest/) assertions.
+  1. Exercise code that uses the mock objects; if necessary, check the result using [Google Test](../../googletest/) assertions.
   1. When a mock objects is destructed, Google Mock automatically verifies that all expectations on it have been satisfied.
 
 Here is an example:
@@ -197,7 +197,7 @@ matcher will be changed.
 |`NanSensitiveFloatEq(a_float)`|`argument` is a `float` value approximately equal to `a_float`, treating two NaNs as equal.    |
 
 The above matchers use ULP-based comparison (the same as used in
-[Google Test](http://code.google.com/p/googletest/)). They
+[Google Test](../../googletest/)). They
 automatically pick a reasonable error bound based on the absolute
 value of the expected value.  `DoubleEq()` and `FloatEq()` conform to
 the IEEE standard, which requires comparing two NaNs for equality to
@@ -227,7 +227,7 @@ The `argument` can be either a C string or a C++ string object:
 
 `ContainsRegex()` and `MatchesRegex()` use the regular expression
 syntax defined
-[here](http://code.google.com/p/googletest/wiki/AdvancedGuide#Regular_Expression_Syntax).
+[here](../../googletest/docs/AdvancedGuide.md#regular-expression-syntax).
 `StrCaseEq()`, `StrCaseNe()`, `StrEq()`, and `StrNe()` work for wide
 strings as well.
 
@@ -322,7 +322,7 @@ You can make a matcher from one or more other matchers:
 
 |`MatcherCast<T>(m)`|casts matcher `m` to type `Matcher<T>`.|
 |:------------------|:--------------------------------------|
-|`SafeMatcherCast<T>(m)`| [safely casts](http://code.google.com/p/googlemock/wiki/CookBook#Casting_Matchers) matcher `m` to type `Matcher<T>`. |
+|`SafeMatcherCast<T>(m)`| [safely casts](CookBook.md#casting-matchers) matcher `m` to type `Matcher<T>`. |
 |`Truly(predicate)` |`predicate(argument)` returns something considered by C++ to be true, where `predicate` is a function or functor.|
 
 ## Matchers as Predicates ##
@@ -347,7 +347,7 @@ You can make a matcher from one or more other matchers:
 
 ## Matchers as Test Assertions ##
 
-|`ASSERT_THAT(expression, m)`|Generates a [fatal failure](http://code.google.com/p/googletest/wiki/Primer#Assertions) if the value of `expression` doesn't match matcher `m`.|
+|`ASSERT_THAT(expression, m)`|Generates a [fatal failure](../../googletest/docs/Primer.md#assertions) if the value of `expression` doesn't match matcher `m`.|
 |:---------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------|
 |`EXPECT_THAT(expression, m)`|Generates a non-fatal failure if the value of `expression` doesn't match matcher `m`.                                                          |
 
@@ -553,10 +553,10 @@ class MockFunction<R(A1, ..., An)> {
   MOCK_METHODn(Call, R(A1, ..., An));
 };
 ```
-See this [recipe](http://code.google.com/p/googlemock/wiki/CookBook#Using_Check_Points) for one application of it.
+See this [recipe](CookBook.md#using-check-points) for one application of it.
 
 # Flags #
 
 | `--gmock_catch_leaked_mocks=0` | Don't report leaked mock objects as failures. |
 |:-------------------------------|:----------------------------------------------|
-| `--gmock_verbose=LEVEL`        | Sets the default verbosity level (`info`, `warning`, or `error`) of Google Mock messages. |
+| `--gmock_verbose=LEVEL`        | Sets the default verbosity level (`info`, `warning`, or `error`) of Google Mock messages. |

3rdparty/googletest/googlemock/docs/CookBook.md

@@ -905,7 +905,7 @@ Matches(AllOf(Ge(0), Le(100), Ne(50)))
 
 Since matchers are basically predicates that also know how to describe
 themselves, there is a way to take advantage of them in
-[Google Test](http://code.google.com/p/googletest/) assertions. It's
+[Google Test](../../googletest/) assertions. It's
 called `ASSERT_THAT` and `EXPECT_THAT`:
 
 ```
@@ -948,7 +948,7 @@ Expected: starts with "Hello"
 ```
 
 **Credit:** The idea of `(ASSERT|EXPECT)_THAT` was stolen from the
-[Hamcrest](http://code.google.com/p/hamcrest/) project, which adds
+[Hamcrest](https://github.com/hamcrest/) project, which adds
 `assertThat()` to JUnit.
 
 ## Using Predicates as Matchers ##
@@ -1343,7 +1343,7 @@ Remember that `_` is the wildcard matcher that matches anything. With this, if `
 
 Note that the order of the two `EXPECT_CALLs` is important, as a newer `EXPECT_CALL` takes precedence over an older one.
 
-For more on uninteresting calls, nice mocks, and strict mocks, read ["The Nice, the Strict, and the Naggy"](https://code.google.com/p/googlemock/wiki/CookBook#The_Nice,_the_Strict,_and_the_Naggy).
+For more on uninteresting calls, nice mocks, and strict mocks, read ["The Nice, the Strict, and the Naggy"](#the-nice-the-strict-and-the-naggy).
 
 ## Expecting Ordered Calls ##
 
@@ -1387,7 +1387,7 @@ instead of being overly constraining.
 
 Google Mock allows you to impose an arbitrary DAG (directed acyclic
 graph) on the calls. One way to express the DAG is to use the
-[After](http://code.google.com/p/googlemock/wiki/CheatSheet#The_After_Clause) clause of `EXPECT_CALL`.
+[After](CheatSheet.md#the-after-clause) clause of `EXPECT_CALL`.
 
 Another way is via the `InSequence()` clause (not the same as the
 `InSequence` class), which we borrowed from jMock 2. It's less
@@ -2484,7 +2484,7 @@ MockFoo::~MockFoo() {}
 
 When it's being destoyed, your friendly mock object will automatically
 verify that all expectations on it have been satisfied, and will
-generate [Google Test](http://code.google.com/p/googletest/) failures
+generate [Google Test](../../googletest/) failures
 if not. This is convenient as it leaves you with one less thing to
 worry about. That is, unless you are not sure if your mock object will
 be destoyed.
@@ -2803,7 +2803,7 @@ obvious that the third `EXPECT_CALL` is written wrong. Case solved.
 ## Running Tests in Emacs ##
 
 If you build and run your tests in Emacs, the source file locations of
-Google Mock and [Google Test](http://code.google.com/p/googletest/)
+Google Mock and [Google Test](../../googletest/)
 errors will be highlighted. Just press `<Enter>` on one of them and
 you'll be taken to the offending line. Or, you can just type `C-x ``
 to jump to the next error.
@@ -2838,7 +2838,7 @@ and you should see an `OUTPUT_DIR` directory being created with files
 These three files contain everything you need to use Google Mock (and
 Google Test).  Just copy them to anywhere you want and you are ready
 to write tests and use mocks.  You can use the
-[scrpts/test/Makefile](http://code.google.com/p/googlemock/source/browse/trunk/scripts/test/Makefile) file as an example on how to compile your tests
+[scrpts/test/Makefile](../scripts/test/Makefile) file as an example on how to compile your tests
 against them.
 
 # Extending Google Mock #
@@ -3670,6 +3670,6 @@ This printer knows how to print built-in C++ types, native arrays, STL
 containers, and any type that supports the `<<` operator.  For other
 types, it prints the raw bytes in the value and hopes that you the
 user can figure it out.
-[Google Test's advanced guide](http://code.google.com/p/googletest/wiki/AdvancedGuide#Teaching_Google_Test_How_to_Print_Your_Values)
+[Google Test's advanced guide](../../googletest/docs/AdvancedGuide.md#teaching-google-test-how-to-print-your-values)
 explains how to extend the printer to do a better job at
-printing your particular type than to dump the bytes.
+printing your particular type than to dump the bytes.

3rdparty/googletest/googlemock/docs/DevGuide.md

@@ -15,7 +15,7 @@ All Google Mock source and pre-built packages are provided under the [New BSD Li
 ## The Google Mock Community ##
 
 The Google Mock community exists primarily through the [discussion group](http://groups.google.com/group/googlemock), the
-[issue tracker](http://code.google.com/p/googlemock/issues/list) and, to a lesser extent, the [source control repository](http://code.google.com/p/googlemock/source/checkout). You are definitely encouraged to contribute to the
+[issue tracker](https://github.com/google/googletest/issues) and, to a lesser extent, the [source control repository](../). You are definitely encouraged to contribute to the
 discussion and you can also help us to keep the effectiveness of the
 group high by following and promoting the guidelines listed here.
 
@@ -52,12 +52,12 @@ Checking out the Google Mock source is most useful if you plan to
 tweak it yourself.  You check out the source for Google Mock using a
 [Subversion](http://subversion.tigris.org/) client as you would for any
 other project hosted on Google Code.  Please see the instruction on
-the [source code access page](http://code.google.com/p/googlemock/source/checkout) for how to do it.
+the [source code access page](../) for how to do it.
 
 ## Compiling from Source ##
 
 Once you check out the code, you can find instructions on how to
-compile it in the [README](http://code.google.com/p/googlemock/source/browse/trunk/README) file.
+compile it in the [README](../README.md) file.
 
 ## Testing ##
 
@@ -90,8 +90,8 @@ instructions for how to sign and return it.
 ## Coding Style ##
 
 To keep the source consistent, readable, diffable and easy to merge,
-we use a fairly rigid coding style, as defined by the [google-styleguide](http://code.google.com/p/google-styleguide/) project.  All patches will be expected
+we use a fairly rigid coding style, as defined by the [google-styleguide](https://github.com/google/styleguide) project.  All patches will be expected
-to conform to the style outlined [here](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml).
+to conform to the style outlined [here](https://github.com/google/styleguide/blob/gh-pages/cppguide.xml).
 
 ## Submitting Patches ##
 
@@ -104,7 +104,7 @@ Please do submit code. Here's what you need to do:
   1. Ensure that there are unit tests for your code.
   1. Sign a Contributor License Agreement.
   1. Create a patch file using `svn diff`.
-  1. We use [Rietveld](http://codereview.appspot.com/) to do web-based code reviews.  You can read about the tool [here](http://code.google.com/p/rietveld/wiki/CodeReviewHelp).  When you are ready, upload your patch via Rietveld and notify `googlemock@googlegroups.com` to review it.  There are several ways to upload the patch.  We recommend using the [upload\_gmock.py](http://code.google.com/p/googlemock/source/browse/trunk/scripts/upload_gmock.py) script, which you can find in the `scripts/` folder in the SVN trunk.
+  1. We use [Rietveld](http://codereview.appspot.com/) to do web-based code reviews.  You can read about the tool [here](https://github.com/rietveld-codereview/rietveld/wiki).  When you are ready, upload your patch via Rietveld and notify `googlemock@googlegroups.com` to review it.  There are several ways to upload the patch.  We recommend using the [upload\_gmock.py](../scripts/upload_gmock.py) script, which you can find in the `scripts/` folder in the SVN trunk.
 
 ## Google Mock Committers ##
 
@@ -129,4 +129,4 @@ We follow the typical release process for Subversion-based projects:
 
 ---
 
-This page is based on the [Making GWT Better](http://code.google.com/webtoolkit/makinggwtbetter.html) guide from the [Google Web Toolkit](http://code.google.com/webtoolkit/) project.  Except as otherwise [noted](http://code.google.com/policies.html#restrictions), the content of this page is licensed under the [Creative Commons Attribution 2.5 License](http://creativecommons.org/licenses/by/2.5/).
+This page is based on the [Making GWT Better](http://code.google.com/webtoolkit/makinggwtbetter.html) guide from the [Google Web Toolkit](http://code.google.com/webtoolkit/) project.  Except as otherwise [noted](http://code.google.com/policies.html#restrictions), the content of this page is licensed under the [Creative Commons Attribution 2.5 License](http://creativecommons.org/licenses/by/2.5/).

3rdparty/googletest/googlemock/docs/Documentation.md

@@ -9,4 +9,4 @@ This page lists all documentation wiki pages for Google Mock **(the SVN trunk ve
 To contribute code to Google Mock, read:
 
   * [DevGuide](DevGuide.md) -- read this _before_ writing your first patch.
-  * [Pump Manual](http://code.google.com/p/googletest/wiki/PumpManual) -- how we generate some of Google Mock's source files.
+  * [Pump Manual](../googletest/docs/PumpManual.md) -- how we generate some of Google Mock's source files.

3rdparty/googletest/googlemock/docs/ForDummies.md

@@ -1,6 +1,6 @@
 
 
-(**Note:** If you get compiler errors that you don't understand, be sure to consult [Google Mock Doctor](http://code.google.com/p/googlemock/wiki/FrequentlyAskedQuestions#How_am_I_supposed_to_make_sense_of_these_horrible_template_error).)
+(**Note:** If you get compiler errors that you don't understand, be sure to consult [Google Mock Doctor](FrequentlyAskedQuestions.md#how-am-i-supposed-to-make-sense-of-these-horrible-template-errors).)
 
 # What Is Google C++ Mocking Framework? #
 When you write a prototype or test, often it's not feasible or wise to rely on real objects entirely. A **mock object** implements the same interface as a real object (so it can be used as one), but lets you specify at run time how it will be used and what it should do (which methods will be called? in which order? how many times? with what arguments? what will they return? etc).
@@ -44,7 +44,7 @@ We encourage you to use Google Mock as:
   * a _testing_ tool to cut your tests' outbound dependencies and probe the interaction between your module and its collaborators.
 
 # Getting Started #
-Using Google Mock is easy! Inside your C++ source file, just #include `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go.
+Using Google Mock is easy! Inside your C++ source file, just `#include` `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go.
 
 # A Case for Mock Turtles #
 Let's look at an example. Suppose you are developing a graphics program that relies on a LOGO-like API for drawing. How would you test that it does the right thing? Well, you can run it and compare the screen with a golden screen snapshot, but let's admit it: tests like this are expensive to run and fragile (What if you just upgraded to a shiny new graphics card that has better anti-aliasing? Suddenly you have to update all your golden images.). It would be too painful if all your tests are like this. Fortunately, you learned about Dependency Injection and know the right thing to do: instead of having your application talk to the drawing API directly, wrap the API in an interface (say, `Turtle`) and code to that interface:
@@ -76,7 +76,7 @@ If you are lucky, the mocks you need to use have already been implemented by som
 Using the `Turtle` interface as example, here are the simple steps you need to follow:
 
   1. Derive a class `MockTurtle` from `Turtle`.
-  1. Take a _virtual_ function of `Turtle` (while it's possible to [mock non-virtual methods using templates](http://code.google.com/p/googlemock/wiki/CookBook#Mocking_Nonvirtual_Methods), it's much more involved). Count how many arguments it has.
+  1. Take a _virtual_ function of `Turtle` (while it's possible to [mock non-virtual methods using templates](CookBook.md#mocking-nonvirtual-methods), it's much more involved). Count how many arguments it has.
   1. In the `public:` section of the child class, write `MOCK_METHODn();` (or `MOCK_CONST_METHODn();` if you are mocking a `const` method), where `n` is the number of the arguments; if you counted wrong, shame on you, and a compiler error will tell you so.
   1. Now comes the fun part: you take the function signature, cut-and-paste the _function name_ as the _first_ argument to the macro, and leave what's left as the _second_ argument (in case you're curious, this is the _type of the function_).
   1. Repeat until all virtual functions you want to mock are done.
@@ -105,7 +105,7 @@ You don't need to define these mock methods somewhere else - the `MOCK_METHOD*`
 tool requires that you have Python 2.4 installed.  You give it a C++ file and the name of an abstract class defined in it,
 and it will print the definition of the mock class for you.  Due to the
 complexity of the C++ language, this script may not always work, but
-it can be quite handy when it does.  For more details, read the [user documentation](http://code.google.com/p/googlemock/source/browse/trunk/scripts/generator/README).
+it can be quite handy when it does.  For more details, read the [user documentation](../scripts/generator/README).
 
 ## Where to Put It ##
 When you define a mock class, you need to decide where to put its definition. Some people put it in a `*_test.cc`. This is fine when the interface being mocked (say, `Foo`) is owned by the same person or team. Otherwise, when the owner of `Foo` changes it, your test could break. (You can't really expect `Foo`'s maintainer to fix every test that uses `Foo`, can you?)
@@ -169,7 +169,7 @@ This means `EXPECT_CALL()` should be read as expecting that a call will occur _i
 Admittedly, this test is contrived and doesn't do much. You can easily achieve the same effect without using Google Mock. However, as we shall reveal soon, Google Mock allows you to do _much more_ with the mocks.
 
 ## Using Google Mock with Any Testing Framework ##
-If you want to use something other than Google Test (e.g. [CppUnit](http://apps.sourceforge.net/mediawiki/cppunit/index.php?title=Main_Page) or
+If you want to use something other than Google Test (e.g. [CppUnit](http://sourceforge.net/projects/cppunit/) or
 [CxxTest](http://cxxtest.tigris.org/)) as your testing framework, just change the `main()` function in the previous section to:
 ```
 int main(int argc, char** argv) {
@@ -187,7 +187,7 @@ sometimes causes the test program to crash.  You'll still be able to
 notice that the test has failed, but it's not a graceful failure.
 
 A better solution is to use Google Test's
-[event listener API](http://code.google.com/p/googletest/wiki/AdvancedGuide#Extending_Google_Test_by_Handling_Test_Events)
+[event listener API](../../googletest/docs/AdvancedGuide.md#extending-google-test-by-handling-test-events)
 to report a test failure to your testing framework properly.  You'll need to
 implement the `OnTestPartResult()` method of the event listener interface, but it
 should be straightforward.
@@ -301,7 +301,7 @@ says that `turtle.GetY()` will be called _at least twice_ (Google Mock knows thi
 
 Of course, if you explicitly write a `Times()`, Google Mock will not try to infer the cardinality itself. What if the number you specified is larger than there are `WillOnce()` clauses? Well, after all `WillOnce()`s are used up, Google Mock will do the _default_ action for the function every time (unless, of course, you have a `WillRepeatedly()`.).
 
-What can we do inside `WillOnce()` besides `Return()`? You can return a reference using `ReturnRef(variable)`, or invoke a pre-defined function, among [others](http://code.google.com/p/googlemock/wiki/CheatSheet#Actions).
+What can we do inside `WillOnce()` besides `Return()`? You can return a reference using `ReturnRef(variable)`, or invoke a pre-defined function, among [others](CheatSheet.md#actions).
 
 **Important note:** The `EXPECT_CALL()` statement evaluates the action clause only once, even though the action may be performed many times. Therefore you must be careful about side effects. The following may not do what you want:
 
@@ -436,4 +436,4 @@ In Google Mock, if you are not interested in a method, just don't say anything a
 # What Now? #
 Congratulations! You've learned enough about Google Mock to start using it. Now, you might want to join the [googlemock](http://groups.google.com/group/googlemock) discussion group and actually write some tests using Google Mock - it will be fun. Hey, it may even be addictive - you've been warned.
 
-Then, if you feel like increasing your mock quotient, you should move on to the [CookBook](CookBook.md). You can learn many advanced features of Google Mock there -- and advance your level of enjoyment and testing bliss.
+Then, if you feel like increasing your mock quotient, you should move on to the [CookBook](CookBook.md). You can learn many advanced features of Google Mock there -- and advance your level of enjoyment and testing bliss.

3rdparty/googletest/googlemock/docs/FrequentlyAskedQuestions.md

@@ -7,7 +7,7 @@ tried [Google Mock Doctor](#How_am_I_supposed_to_make_sense_of_these_horrible_te
 
 ## When I call a method on my mock object, the method for the real object is invoked instead.  What's the problem? ##
 
-In order for a method to be mocked, it must be _virtual_, unless you use the [high-perf dependency injection technique](http://code.google.com/p/googlemock/wiki/CookBook#Mocking_Nonvirtual_Methods).
+In order for a method to be mocked, it must be _virtual_, unless you use the [high-perf dependency injection technique](CookBook.md#mocking-nonvirtual-methods).
 
 ## I wrote some matchers.  After I upgraded to a new version of Google Mock, they no longer compile.  What's going on? ##
 
@@ -196,8 +196,8 @@ class MyGreatMatcher {
 ```
 
 For more information, you can read these
-[two](http://code.google.com/p/googlemock/wiki/CookBook#Writing_New_Monomorphic_Matchers)
+[two](CookBook.md#writing-new-monomorphic-matchers)
-[recipes](http://code.google.com/p/googlemock/wiki/CookBook#Writing_New_Polymorphic_Matchers)
+[recipes](CookBook.md#writing-new-polymorphic-matchers)
 from the cookbook.  As always, you
 are welcome to post questions on `googlemock@googlegroups.com` if you
 need any help.
@@ -206,7 +206,7 @@ need any help.
 
 Google Mock works out of the box with Google Test.  However, it's easy
 to configure it to work with any testing framework of your choice.
-[Here](http://code.google.com/p/googlemock/wiki/ForDummies#Using_Google_Mock_with_Any_Testing_Framework) is how.
+[Here](ForDummies.md#using-google-mock-with-any-testing-framework) is how.
 
 ## How am I supposed to make sense of these horrible template errors? ##
 
@@ -474,10 +474,10 @@ verbose level.
 If you find yourself needing to perform some action that's not
 supported by Google Mock directly, remember that you can define your own
 actions using
-[MakeAction()](http://code.google.com/p/googlemock/wiki/CookBook#Writing_New_Actions) or
+[MakeAction()](CookBook.md#writing-new-actions) or
-[MakePolymorphicAction()](http://code.google.com/p/googlemock/wiki/CookBook#Writing_New_Polymorphic_Actions),
+[MakePolymorphicAction()](CookBook.md#writing_new_polymorphic_actions),
 or you can write a stub function and invoke it using
-[Invoke()](http://code.google.com/p/googlemock/wiki/CookBook#Using_Functions_Methods_Functors).
+[Invoke()](CookBook.md#using-functions_methods_functors).
 
 ## MOCK\_METHODn()'s second argument looks funny.  Why don't you use the MOCK\_METHODn(Method, return\_type, arg\_1, ..., arg\_n) syntax? ##
 
@@ -599,7 +599,7 @@ when the mock method is called.  `SetArgPointee()` says what the
 side effect is, but doesn't say what the return value should be.  You
 need `DoAll()` to chain a `SetArgPointee()` with a `Return()`.
 
-See this [recipe](http://code.google.com/p/googlemock/wiki/CookBook#Mocking_Side_Effects) for more details and an example.
+See this [recipe](CookBook.md#mocking_side_effects) for more details and an example.
 
 
 ## My question is not in your FAQ! ##
@@ -607,12 +607,12 @@ See this [recipe](http://code.google.com/p/googlemock/wiki/CookBook#Mocking_Side
 If you cannot find the answer to your question in this FAQ, there are
 some other resources you can use:
 
-  1. read other [wiki pages](http://code.google.com/p/googlemock/w/list),
+  1. read other [documentation](Documentation.md),
   1. search the mailing list [archive](http://groups.google.com/group/googlemock/topics),
   1. ask it on [googlemock@googlegroups.com](mailto:googlemock@googlegroups.com) and someone will answer it (to prevent spam, we require you to join the [discussion group](http://groups.google.com/group/googlemock) before you can post.).
 
 Please note that creating an issue in the
-[issue tracker](http://code.google.com/p/googlemock/issues/list) is _not_
+[issue tracker](https://github.com/google/googletest/issues) is _not_
 a good way to get your answer, as it is monitored infrequently by a
 very small number of people.
 
@@ -625,4 +625,4 @@ not enough information in your question):
   * the name and version of your compiler,
   * the complete command line flags you give to your compiler,
   * the complete compiler error messages (if the question is about compilation),
-  * the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.
+  * the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.

3rdparty/googletest/googlemock/docs/v1_5/ForDummies.md

@@ -44,7 +44,7 @@ We encourage you to use Google Mock as:
   * a _testing_ tool to cut your tests' outbound dependencies and probe the interaction between your module and its collaborators.
 
 # Getting Started #
-Using Google Mock is easy! Inside your C++ source file, just #include `<gtest/gtest.h>` and `<gmock/gmock.h>`, and you are ready to go.
+Using Google Mock is easy! Inside your C++ source file, just `#include` `<gtest/gtest.h>` and `<gmock/gmock.h>`, and you are ready to go.
 
 # A Case for Mock Turtles #
 Let's look at an example. Suppose you are developing a graphics program that relies on a LOGO-like API for drawing. How would you test that it does the right thing? Well, you can run it and compare the screen with a golden screen snapshot, but let's admit it: tests like this are expensive to run and fragile (What if you just upgraded to a shiny new graphics card that has better anti-aliasing? Suddenly you have to update all your golden images.). It would be too painful if all your tests are like this. Fortunately, you learned about Dependency Injection and know the right thing to do: instead of having your application talk to the drawing API directly, wrap the API in an interface (say, `Turtle`) and code to that interface:

3rdparty/googletest/googlemock/docs/v1_6/ForDummies.md

@@ -44,7 +44,7 @@ We encourage you to use Google Mock as:
   * a _testing_ tool to cut your tests' outbound dependencies and probe the interaction between your module and its collaborators.
 
 # Getting Started #
-Using Google Mock is easy! Inside your C++ source file, just #include `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go.
+Using Google Mock is easy! Inside your C++ source file, just `#include` `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go.
 
 # A Case for Mock Turtles #
 Let's look at an example. Suppose you are developing a graphics program that relies on a LOGO-like API for drawing. How would you test that it does the right thing? Well, you can run it and compare the screen with a golden screen snapshot, but let's admit it: tests like this are expensive to run and fragile (What if you just upgraded to a shiny new graphics card that has better anti-aliasing? Suddenly you have to update all your golden images.). It would be too painful if all your tests are like this. Fortunately, you learned about Dependency Injection and know the right thing to do: instead of having your application talk to the drawing API directly, wrap the API in an interface (say, `Turtle`) and code to that interface:

3rdparty/googletest/googlemock/docs/v1_7/ForDummies.md

@@ -44,7 +44,7 @@ We encourage you to use Google Mock as:
   * a _testing_ tool to cut your tests' outbound dependencies and probe the interaction between your module and its collaborators.
 
 # Getting Started #
-Using Google Mock is easy! Inside your C++ source file, just #include `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go.
+Using Google Mock is easy! Inside your C++ source file, just `#include` `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go.
 
 # A Case for Mock Turtles #
 Let's look at an example. Suppose you are developing a graphics program that relies on a LOGO-like API for drawing. How would you test that it does the right thing? Well, you can run it and compare the screen with a golden screen snapshot, but let's admit it: tests like this are expensive to run and fragile (What if you just upgraded to a shiny new graphics card that has better anti-aliasing? Suddenly you have to update all your golden images.). It would be too painful if all your tests are like this. Fortunately, you learned about Dependency Injection and know the right thing to do: instead of having your application talk to the drawing API directly, wrap the API in an interface (say, `Turtle`) and code to that interface:

3rdparty/googletest/googlemock/include/gmock/gmock-actions.h

@@ -46,7 +46,7 @@
 #include "gmock/internal/gmock-internal-utils.h"
 #include "gmock/internal/gmock-port.h"
 
-#if GTEST_LANG_CXX11  // Defined by gtest-port.h via gmock-port.h.
+#if GTEST_HAS_STD_TYPE_TRAITS_  // Defined by gtest-port.h via gmock-port.h.
 #include <type_traits>
 #endif
 
@@ -96,7 +96,7 @@ struct BuiltInDefaultValueGetter<T, false> {
 template <typename T>
 class BuiltInDefaultValue {
  public:
-#if GTEST_LANG_CXX11
+#if GTEST_HAS_STD_TYPE_TRAITS_
   // This function returns true iff type T has a built-in default value.
   static bool Exists() {
     return ::std::is_default_constructible<T>::value;
@@ -107,7 +107,7 @@ class BuiltInDefaultValue {
         T, ::std::is_default_constructible<T>::value>::Get();
   }
 
-#else  // GTEST_LANG_CXX11
+#else  // GTEST_HAS_STD_TYPE_TRAITS_
   // This function returns true iff type T has a built-in default value.
   static bool Exists() {
     return false;
@@ -117,7 +117,7 @@ class BuiltInDefaultValue {
     return BuiltInDefaultValueGetter<T, false>::Get();
   }
 
-#endif  // GTEST_LANG_CXX11
+#endif  // GTEST_HAS_STD_TYPE_TRAITS_
 };
 
 // This partial specialization says that we use the same built-in

3rdparty/googletest/googlemock/make/Makefile

@@ -17,7 +17,7 @@
 # Points to the root of Google Test, relative to where this file is.
 # Remember to tweak this if you move this file, or if you want to use
 # a copy of Google Test at a different location.
-GTEST_DIR = ../../googletest
+GTEST_DIR = ../gtest
 
 # Points to the root of Google Mock, relative to where this file is.
 # Remember to tweak this if you move this file.

3rdparty/googletest/googlemock/src/gmock-spec-builders.cc

@@ -258,8 +258,8 @@ void ReportUninterestingCall(CallReaction reaction, const string& msg) {
           "\nNOTE: You can safely ignore the above warning unless this "
           "call should not happen.  Do not suppress it by blindly adding "
           "an EXPECT_CALL() if you don't mean to enforce the call.  "
-          "See http://code.google.com/p/googlemock/wiki/CookBook#"
+          "See https://github.com/google/googletest/blob/master/googlemock/docs/CookBook.md#"
-          "Knowing_When_to_Expect for details.\n",
+          "knowing-when-to-expect for details.\n",
           stack_frames_to_skip);
       break;
     default:  // FAIL

3rdparty/googletest/googlemock/test/gmock-actions_test.cc

@@ -214,7 +214,7 @@ class MyNonDefaultConstructible {
   int value_;
 };
 
-#if GTEST_LANG_CXX11
+#if GTEST_HAS_STD_TYPE_TRAITS_
 
 TEST(BuiltInDefaultValueTest, ExistsForDefaultConstructibleType) {
   EXPECT_TRUE(BuiltInDefaultValue<MyDefaultConstructible>::Exists());
@@ -224,7 +224,7 @@ TEST(BuiltInDefaultValueTest, IsDefaultConstructedForDefaultConstructibleType) {
   EXPECT_EQ(42, BuiltInDefaultValue<MyDefaultConstructible>::Get().value());
 }
 
-#endif  // GTEST_LANG_CXX11
+#endif  // GTEST_HAS_STD_TYPE_TRAITS_
 
 TEST(BuiltInDefaultValueTest, DoesNotExistForNonDefaultConstructibleType) {
   EXPECT_FALSE(BuiltInDefaultValue<MyNonDefaultConstructible>::Exists());

3rdparty/googletest/googlemock/test/gmock-matchers_test.cc

@@ -1042,14 +1042,14 @@ TEST(IsNullTest, ReferenceToConstLinkedPtr) {
   EXPECT_FALSE(m.Matches(non_null_p));
 }
 
-#if GTEST_LANG_CXX11
+#if GTEST_HAS_STD_FUNCTION_
 TEST(IsNullTest, StdFunction) {
   const Matcher<std::function<void()>> m = IsNull();
 
   EXPECT_TRUE(m.Matches(std::function<void()>()));
   EXPECT_FALSE(m.Matches([]{}));
 }
-#endif  // GTEST_LANG_CXX11
+#endif  // GTEST_HAS_STD_FUNCTION_
 
 // Tests that IsNull() describes itself properly.
 TEST(IsNullTest, CanDescribeSelf) {
@@ -1090,14 +1090,14 @@ TEST(NotNullTest, ReferenceToConstLinkedPtr) {
   EXPECT_TRUE(m.Matches(non_null_p));
 }
 
-#if GTEST_LANG_CXX11
+#if GTEST_HAS_STD_FUNCTION_
 TEST(NotNullTest, StdFunction) {
   const Matcher<std::function<void()>> m = NotNull();
 
   EXPECT_TRUE(m.Matches([]{}));
   EXPECT_FALSE(m.Matches(std::function<void()>()));
 }
-#endif  // GTEST_LANG_CXX11
+#endif  // GTEST_HAS_STD_FUNCTION_
 
 // Tests that NotNull() describes itself properly.
 TEST(NotNullTest, CanDescribeSelf) {
@@ -2708,22 +2708,18 @@ class FloatingPointTest : public testing::Test {
         zero_bits_(Floating(0).bits()),
         one_bits_(Floating(1).bits()),
         infinity_bits_(Floating(Floating::Infinity()).bits()),
-        close_to_positive_zero_(
+        close_to_positive_zero_(AsBits(zero_bits_ + max_ulps_/2)),
-            Floating::ReinterpretBits(zero_bits_ + max_ulps_/2)),
+        close_to_negative_zero_(AsBits(zero_bits_ + max_ulps_ - max_ulps_/2)),
-        close_to_negative_zero_(
+        further_from_negative_zero_(-AsBits(
-            -Floating::ReinterpretBits(zero_bits_ + max_ulps_ - max_ulps_/2)),
-        further_from_negative_zero_(-Floating::ReinterpretBits(
             zero_bits_ + max_ulps_ + 1 - max_ulps_/2)),
-        close_to_one_(Floating::ReinterpretBits(one_bits_ + max_ulps_)),
+        close_to_one_(AsBits(one_bits_ + max_ulps_)),
-        further_from_one_(Floating::ReinterpretBits(one_bits_ + max_ulps_ + 1)),
+        further_from_one_(AsBits(one_bits_ + max_ulps_ + 1)),
         infinity_(Floating::Infinity()),
-        close_to_infinity_(
+        close_to_infinity_(AsBits(infinity_bits_ - max_ulps_)),
-            Floating::ReinterpretBits(infinity_bits_ - max_ulps_)),
+        further_from_infinity_(AsBits(infinity_bits_ - max_ulps_ - 1)),
-        further_from_infinity_(
-            Floating::ReinterpretBits(infinity_bits_ - max_ulps_ - 1)),
         max_(Floating::Max()),
-        nan1_(Floating::ReinterpretBits(Floating::kExponentBitMask | 1)),
+        nan1_(AsBits(Floating::kExponentBitMask | 1)),
-        nan2_(Floating::ReinterpretBits(Floating::kExponentBitMask | 200)) {
+        nan2_(AsBits(Floating::kExponentBitMask | 200)) {
   }
 
   void TestSize() {
@@ -2804,6 +2800,12 @@ class FloatingPointTest : public testing::Test {
   // Some NaNs.
   const RawType nan1_;
   const RawType nan2_;
+
+ private:
+  template <typename T>
+  static RawType AsBits(T value) {
+    return Floating::ReinterpretBits(static_cast<Bits>(value));
+  }
 };
 
 // Tests floating-point matchers with fixed epsilons.
@@ -3179,6 +3181,8 @@ MATCHER_P(FieldIIs, inner_matcher, "") {
   return ExplainMatchResult(inner_matcher, arg.i, result_listener);
 }
 
+#if GTEST_HAS_RTTI
+
 TEST(WhenDynamicCastToTest, SameType) {
   Derived derived;
   derived.i = 4;
@@ -3236,12 +3240,8 @@ TEST(WhenDynamicCastToTest, AmbiguousCast) {
 
 TEST(WhenDynamicCastToTest, Describe) {
   Matcher<Base*> matcher = WhenDynamicCastTo<Derived*>(Pointee(_));
-#if GTEST_HAS_RTTI
   const string prefix =
       "when dynamic_cast to " + internal::GetTypeName<Derived*>() + ", ";
-#else  // GTEST_HAS_RTTI
-  const string prefix = "when dynamic_cast, ";
-#endif  // GTEST_HAS_RTTI
   EXPECT_EQ(prefix + "points to a value that is anything", Describe(matcher));
   EXPECT_EQ(prefix + "does not point to a value that is anything",
             DescribeNegation(matcher));
@@ -3275,6 +3275,8 @@ TEST(WhenDynamicCastToTest, BadReference) {
   EXPECT_THAT(as_base_ref, Not(WhenDynamicCastTo<const OtherDerived&>(_)));
 }
 
+#endif  // GTEST_HAS_RTTI
+
 // Minimal const-propagating pointer.
 template <typename T>
 class ConstPropagatingPtr {

3rdparty/googletest/googlemock/test/gmock-spec-builders_test.cc

@@ -2117,8 +2117,8 @@ class GMockVerboseFlagTest : public VerboseFlagPreservingFixture {
         "NOTE: You can safely ignore the above warning unless this "
         "call should not happen.  Do not suppress it by blindly adding "
         "an EXPECT_CALL() if you don't mean to enforce the call.  "
-        "See http://code.google.com/p/googlemock/wiki/CookBook#"
+        "See https://github.com/google/googletest/blob/master/googlemock/docs/CookBook.md#"
-        "Knowing_When_to_Expect for details.";
+        "knowing-when-to-expect for details.";
 
     // A void-returning function.
     CaptureStdout();

3rdparty/googletest/googlemock/test/gmock_output_test_golden.txt

@@ -75,14 +75,14 @@ GMOCK WARNING:
 Uninteresting mock function call - returning default value.
     Function call: Bar2(0, 1)
           Returns: false
-NOTE: You can safely ignore the above warning unless this call should not happen.  Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call.  See http://code.google.com/p/googlemock/wiki/CookBook#Knowing_When_to_Expect for details.
+NOTE: You can safely ignore the above warning unless this call should not happen.  Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call.  See https://github.com/google/googletest/blob/master/googlemock/docs/CookBook.md#knowing-when-to-expect for details.
 [       OK ] GMockOutputTest.UninterestingCall
 [ RUN      ] GMockOutputTest.UninterestingCallToVoidFunction
 
 GMOCK WARNING:
 Uninteresting mock function call - returning directly.
     Function call: Bar3(0, 1)
-NOTE: You can safely ignore the above warning unless this call should not happen.  Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call.  See http://code.google.com/p/googlemock/wiki/CookBook#Knowing_When_to_Expect for details.
+NOTE: You can safely ignore the above warning unless this call should not happen.  Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call.  See https://github.com/google/googletest/blob/master/googlemock/docs/CookBook.md#knowing-when-to-expect for details.
 [       OK ] GMockOutputTest.UninterestingCallToVoidFunction
 [ RUN      ] GMockOutputTest.RetiredExpectation
 unknown file: Failure
@@ -266,14 +266,14 @@ Uninteresting mock function call - taking default action specified at:
 FILE:#:
     Function call: Bar2(2, 2)
           Returns: true
-NOTE: You can safely ignore the above warning unless this call should not happen.  Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call.  See http://code.google.com/p/googlemock/wiki/CookBook#Knowing_When_to_Expect for details.
+NOTE: You can safely ignore the above warning unless this call should not happen.  Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call.  See https://github.com/google/googletest/blob/master/googlemock/docs/CookBook.md#knowing-when-to-expect for details.
 
 GMOCK WARNING:
 Uninteresting mock function call - taking default action specified at:
 FILE:#:
     Function call: Bar2(1, 1)
           Returns: false
-NOTE: You can safely ignore the above warning unless this call should not happen.  Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call.  See http://code.google.com/p/googlemock/wiki/CookBook#Knowing_When_to_Expect for details.
+NOTE: You can safely ignore the above warning unless this call should not happen.  Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call.  See https://github.com/google/googletest/blob/master/googlemock/docs/CookBook.md#knowing-when-to-expect for details.
 [       OK ] GMockOutputTest.UninterestingCallWithDefaultAction
 [ RUN      ] GMockOutputTest.ExplicitActionsRunOutWithDefaultAction
 

3rdparty/googletest/googletest/.gitignore

@@ -0,0 +1,2 @@
+# python
+*.pyc

3rdparty/googletest/googletest/CMakeLists.txt

@@ -22,6 +22,11 @@ option(gtest_build_samples "Build gtest's sample programs." OFF)
 
 option(gtest_disable_pthreads "Disable uses of pthreads in gtest." OFF)
 
+option(
+  gtest_hide_internal_symbols
+  "Build gtest with internal symbols hidden in shared libraries."
+  OFF)
+
 # Defines pre_project_set_up_hermetic_build() and set_up_hermetic_build().
 include(cmake/hermetic_build.cmake OPTIONAL)
 
@@ -46,6 +51,11 @@ if (COMMAND set_up_hermetic_build)
   set_up_hermetic_build()
 endif()
 
+if (gtest_hide_internal_symbols)
+  set(CMAKE_CXX_VISIBILITY_PRESET hidden)
+  set(CMAKE_VISIBILITY_INLINES_HIDDEN 1)
+endif()
+
 # Define helper functions and macros used by Google Test.
 include(cmake/internal_utils.cmake)
 
@@ -81,6 +91,22 @@ cxx_library(gtest "${cxx_strict}" src/gtest-all.cc)
 cxx_library(gtest_main "${cxx_strict}" src/gtest_main.cc)
 target_link_libraries(gtest_main gtest)
 
+# If the CMake version supports it, attach header directory information
+# to the targets for when we are part of a parent build (ie being pulled
+# in via add_subdirectory() rather than being a standalone build).
+if (DEFINED CMAKE_VERSION AND NOT "${CMAKE_VERSION}" VERSION_LESS "2.8.11")
+  target_include_directories(gtest      INTERFACE "${gtest_SOURCE_DIR}/include")
+  target_include_directories(gtest_main INTERFACE "${gtest_SOURCE_DIR}/include")
+endif()
+
+########################################################################
+#
+# Install rules
+install(TARGETS gtest gtest_main
+  DESTINATION lib)
+install(DIRECTORY ${gtest_SOURCE_DIR}/include/gtest
+  DESTINATION include)
+
 ########################################################################
 #
 # Samples on how to link user tests with gtest or gtest_main.

3rdparty/googletest/googletest/README.md

@@ -54,7 +54,7 @@ it.
 ### Using CMake ###
 
 Google Test comes with a CMake build script (
-[CMakeLists.txt](master/CMakeLists.txt)) that can be used on a wide range of platforms ("C" stands for
+[CMakeLists.txt](CMakeLists.txt)) that can be used on a wide range of platforms ("C" stands for
 cross-platform.). If you don't have CMake installed already, you can
 download it for free from <http://www.cmake.org/>.
 
@@ -136,7 +136,7 @@ these macros are named like `GTEST_XYZ` and you define them to either 1
 or 0 to enable or disable a certain feature.
 
 We list the most frequently used macros below.  For a complete list,
-see file [include/gtest/internal/gtest-port.h](https://github.com/google/googletest/blob/master/include/gtest/internal/gtest-port.h).
+see file [include/gtest/internal/gtest-port.h](include/gtest/internal/gtest-port.h).
 
 ### Choosing a TR1 Tuple Library ###
 
@@ -221,7 +221,7 @@ your build script.
 ### Avoiding Macro Name Clashes ###
 
 In C++, macros don't obey namespaces.  Therefore two libraries that
-both define a macro of the same name will clash if you #include both
+both define a macro of the same name will clash if you `#include` both
 definitions.  In case a Google Test macro clashes with another
 library, you can force Google Test to rename its macro to avoid the
 conflict.

3rdparty/googletest/googletest/docs/AdvancedGuide.md

@@ -230,7 +230,7 @@ message is formatted:
 
 | **Fatal assertion** | **Nonfatal assertion** | **Verifies** |
 |:--------------------|:-----------------------|:-------------|
-| `ASSERT_PRED_FORMAT1(`_pred\_format1, val1_`);`        | `EXPECT_PRED_FORMAT1(`_pred\_format1, val1_`); | _pred\_format1(val1)_ is successful |
+| `ASSERT_PRED_FORMAT1(`_pred\_format1, val1_`);`        | `EXPECT_PRED_FORMAT1(`_pred\_format1, val1_`);` | _pred\_format1(val1)_ is successful |
 | `ASSERT_PRED_FORMAT2(`_pred\_format2, val1, val2_`);` | `EXPECT_PRED_FORMAT2(`_pred\_format2, val1, val2_`);` | _pred\_format2(val1, val2)_ is successful |
 | `...`               | `...`                  | `...`        |
 
@@ -265,7 +265,7 @@ int SmallestPrimeCommonDivisor(int m, int n) { ... }
                                                int n) {
   if (MutuallyPrime(m, n))
     return ::testing::AssertionSuccess();
- 
+
   return ::testing::AssertionFailure()
       << m_expr << " and " << n_expr << " (" << m << " and " << n
       << ") are not mutually prime, " << "as they have a common divisor "
@@ -312,8 +312,8 @@ want to learn more, see
 
 | **Fatal assertion** | **Nonfatal assertion** | **Verifies** |
 |:--------------------|:-----------------------|:-------------|
-| `ASSERT_FLOAT_EQ(`_expected, actual_`);`  | `EXPECT_FLOAT_EQ(`_expected, actual_`);` | the two `float` values are almost equal |
+| `ASSERT_FLOAT_EQ(`_val1, val2_`);`  | `EXPECT_FLOAT_EQ(`_val1, val2_`);` | the two `float` values are almost equal |
-| `ASSERT_DOUBLE_EQ(`_expected, actual_`);` | `EXPECT_DOUBLE_EQ(`_expected, actual_`);` | the two `double` values are almost equal |
+| `ASSERT_DOUBLE_EQ(`_val1, val2_`);` | `EXPECT_DOUBLE_EQ(`_val1, val2_`);` | the two `double` values are almost equal |
 
 By "almost equal", we mean the two values are within 4 ULP's from each
 other.
@@ -527,9 +527,9 @@ Google Test has the following macros to support death tests:
 
 | **Fatal assertion** | **Nonfatal assertion** | **Verifies** |
 |:--------------------|:-----------------------|:-------------|
-| `ASSERT_DEATH(`_statement, regex_`); | `EXPECT_DEATH(`_statement, regex_`); | _statement_ crashes with the given error |
+| `ASSERT_DEATH(`_statement, regex_`);` | `EXPECT_DEATH(`_statement, regex_`);` | _statement_ crashes with the given error |
-| `ASSERT_DEATH_IF_SUPPORTED(`_statement, regex_`); | `EXPECT_DEATH_IF_SUPPORTED(`_statement, regex_`); | if death tests are supported, verifies that _statement_ crashes with the given error; otherwise verifies nothing |
+| `ASSERT_DEATH_IF_SUPPORTED(`_statement, regex_`);` | `EXPECT_DEATH_IF_SUPPORTED(`_statement, regex_`);` | if death tests are supported, verifies that _statement_ crashes with the given error; otherwise verifies nothing |
-| `ASSERT_EXIT(`_statement, predicate, regex_`); | `EXPECT_EXIT(`_statement, predicate, regex_`); |_statement_ exits with the given error and its exit code matches _predicate_ |
+| `ASSERT_EXIT(`_statement, predicate, regex_`);` | `EXPECT_EXIT(`_statement, predicate, regex_`);` |_statement_ exits with the given error and its exit code matches _predicate_ |
 
 where _statement_ is a statement that is expected to cause the process to
 die, _predicate_ is a function or function object that evaluates an integer
@@ -804,7 +804,7 @@ For example,
 11:   EXPECT_EQ(1, Bar(n));
 12:   EXPECT_EQ(2, Bar(n + 1));
 13: }
-14: 
+14:
 15: TEST(FooTest, Bar) {
 16:   {
 17:     SCOPED_TRACE("A");  // This trace point will be included in
@@ -1199,9 +1199,9 @@ which are all in the `testing` namespace:
 | `Values(v1, v2, ..., vN)`   | Yields values `{v1, v2, ..., vN}`.                                                                                |
 | `ValuesIn(container)` and `ValuesIn(begin, end)` | Yields values from a C-style array, an STL-style container, or an iterator range `[begin, end)`. `container`, `begin`, and `end` can be expressions whose values are determined at run time.  |
 | `Bool()`                    | Yields sequence `{false, true}`.                                                                                  |
-| `Combine(g1, g2, ..., gN)`  | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](https://github.com/google/googletest/blob/master/googletest/include/gtest/internal/gtest-port.h) for more information. |
+| `Combine(g1, g2, ..., gN)`  | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](../include/gtest/internal/gtest-port.h) for more information. |
 
-For more details, see the comments at the definitions of these functions in the [source code](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest-param-test.h).
+For more details, see the comments at the definitions of these functions in the [source code](../include/gtest/gtest-param-test.h).
 
 The following statement will instantiate tests from the `FooTest` test case
 each with parameter values `"meeny"`, `"miny"`, and `"moe"`.
@@ -1249,8 +1249,8 @@ tests in the given test case, whether their definitions come before or
 _after_ the `INSTANTIATE_TEST_CASE_P` statement.
 
 You can see
-[these](https://github.com/google/googletest/blob/master/googletest/samples/sample7_unittest.cc)
+[these](../samples/sample7_unittest.cc)
-[files](https://github.com/google/googletest/blob/master/googletest/samples/sample8_unittest.cc) for more examples.
+[files](../samples/sample8_unittest.cc) for more examples.
 
 _Availability_: Linux, Windows (requires MSVC 8.0 or above), Mac; since version 1.2.0.
 
@@ -1450,7 +1450,7 @@ two cases to consider:
 
 Both static functions and definitions/declarations in an unnamed namespace are
 only visible within the same translation unit. To test them, you can `#include`
-the entire `.cc` file being tested in your `*_test.cc` file. (#including `.cc`
+the entire `.cc` file being tested in your `*_test.cc` file. (`#include`ing `.cc`
 files is not a good way to reuse code - you should not do this in production
 code!)
 
@@ -1551,8 +1551,8 @@ exception, you could catch the exception and assert on it.  But Google
 Test doesn't use exceptions, so how do we test that a piece of code
 generates an expected failure?
 
-`"gtest/gtest-spi.h"` contains some constructs to do this.  After
+`"gtest/gtest-spi.h"` contains some constructs to do this.  After 
-#including this header, you can use
+`#include`ing this header, you can use
 
 | `EXPECT_FATAL_FAILURE(`_statement, substring_`);` |
 |:--------------------------------------------------|
@@ -1646,8 +1646,8 @@ _Availability:_ Linux, Windows, Mac; since v1.4.0.
 ## Defining Event Listeners ##
 
 To define a event listener, you subclass either
-[testing::TestEventListener](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest.h#L991)
+[testing::TestEventListener](../include/gtest/gtest.h#L991)
-or [testing::EmptyTestEventListener](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest.h#L1044).
+or [testing::EmptyTestEventListener](../include/gtest/gtest.h#L1044).
 The former is an (abstract) interface, where <i>each pure virtual method<br>
 can be overridden to handle a test event</i> (For example, when a test
 starts, the `OnTestStart()` method will be called.). The latter provides
@@ -1656,10 +1656,10 @@ subclass only needs to override the methods it cares about.
 
 When an event is fired, its context is passed to the handler function
 as an argument. The following argument types are used:
-  * [UnitTest](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest.h#L1151) reflects the state of the entire test program,
+  * [UnitTest](../include/gtest/gtest.h#L1151) reflects the state of the entire test program,
-  * [TestCase](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest.h#L778) has information about a test case, which can contain one or more tests,
+  * [TestCase](../include/gtest/gtest.h#L778) has information about a test case, which can contain one or more tests,
-  * [TestInfo](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest.h#L644) contains the state of a test, and
+  * [TestInfo](../include/gtest/gtest.h#L644) contains the state of a test, and
-  * [TestPartResult](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest-test-part.h#L47) represents the result of a test assertion.
+  * [TestPartResult](../include/gtest/gtest-test-part.h#L47) represents the result of a test assertion.
 
 An event handler function can examine the argument it receives to find
 out interesting information about the event and the test program's
@@ -1695,7 +1695,7 @@ state.  Here's an example:
 
 To use the event listener you have defined, add an instance of it to
 the Google Test event listener list (represented by class
-[TestEventListeners](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest.h#L1064)
+[TestEventListeners](../include/gtest/gtest.h#L1064)
 - note the "s" at the end of the name) in your
 `main()` function, before calling `RUN_ALL_TESTS()`:
 ```
@@ -1723,7 +1723,7 @@ event listener list and delete it. You can do so by adding one line:
 
 Now, sit back and enjoy a completely different output from your
 tests. For more details, you can read this
-[sample](https://github.com/google/googletest/blob/master/googletest/samples/sample9_unittest.cc).
+[sample](../samples/sample9_unittest.cc).
 
 You may append more than one listener to the list. When an `On*Start()`
 or `OnTestPartResult()` event is fired, the listeners will receive it in
@@ -1748,7 +1748,7 @@ failures. This ensures that failures generated by the latter are
 attributed to the right test by the former.
 
 We have a sample of failure-raising listener
-[here](https://github.com/google/googletest/blob/master/googletest/samples/sample10_unittest.cc).
+[here](../samples/sample10_unittest.cc).
 
 # Running Test Programs: Advanced Options #
 
@@ -2173,7 +2173,7 @@ and you should see an `OUTPUT_DIR` directory being created with files
 `gtest/gtest.h` and `gtest/gtest-all.cc` in it.  These files contain
 everything you need to use Google Test.  Just copy them to anywhere
 you want and you are ready to write tests.  You can use the
-[scripts/test/Makefile](https://github.com/google/googletest/blob/master/googletest/scripts/test/Makefile)
+[scripts/test/Makefile](../scripts/test/Makefile)
 file as an example on how to compile your tests against them.
 
 # Where to Go from Here #

3rdparty/googletest/googletest/docs/DevGuide.md

@@ -14,8 +14,8 @@ All Google Test source and pre-built packages are provided under the [New BSD Li
 
 ## The Google Test Community ##
 
-The Google Test community exists primarily through the [discussion group](http://groups.google.com/group/googletestframework), the
+The Google Test community exists primarily through the [discussion group](http://groups.google.com/group/googletestframework) and the GitHub repository.
-[issue tracker](http://code.google.com/p/googletest/issues/list) and, to a lesser extent, the [source control repository](http://code.google.com/p/googletest/source/checkout). You are definitely encouraged to contribute to the
+You are definitely encouraged to contribute to the
 discussion and you can also help us to keep the effectiveness of the
 group high by following and promoting the guidelines listed here.
 
@@ -35,37 +35,27 @@ Sure, C++ testing is serious business and all that, but it's also
 a lot of fun. Let's keep it that way. Let's strive to be one of the
 friendliest communities in all of open source.
 
-### Where to Discuss Google Test ###
+As always, discuss Google Test in the official GoogleTest discussion group.
-
+You don't have to actually submit code in order to sign up. Your participation
-As always, discuss Google Test in the official [Google C++ Testing Framework discussion group](http://groups.google.com/group/googletestframework).  You don't have to actually submit
+itself is a valuable contribution.
-code in order to sign up. Your participation itself is a valuable
-contribution.
 
 # Working with the Code #
 
 If you want to get your hands dirty with the code inside Google Test,
 this is the section for you.
 
-## Checking Out the Source from Subversion ##
-
-Checking out the Google Test source is most useful if you plan to
-tweak it yourself.  You check out the source for Google Test using a
-[Subversion](http://subversion.tigris.org/) client as you would for any
-other project hosted on Google Code.  Please see the instruction on
-the [source code access page](http://code.google.com/p/googletest/source/checkout) for how to do it.
-
 ## Compiling from Source ##
 
 Once you check out the code, you can find instructions on how to
-compile it in the [README](http://code.google.com/p/googletest/source/browse/trunk/README) file.
+compile it in the [README](../README.md) file.
 
 ## Testing ##
 
 A testing framework is of no good if itself is not thoroughly tested.
 Tests should be written for any new code, and changes should be
 verified to not break existing tests before they are submitted for
-review. To perform the tests, follow the instructions in [README](http://code.google.com/p/googletest/source/browse/trunk/README) and
+review. To perform the tests, follow the instructions in
-verify that there are no failures.
+[README](../README.md) and verify that there are no failures.
 
 # Contributing Code #
 
@@ -104,14 +94,12 @@ can read the PumpManual for details.
 
 Please do submit code. Here's what you need to do:
 
-  1. Normally you should make your change against the SVN trunk instead of a branch or a tag, as the latter two are for release control and should be treated mostly as read-only.
+  1. A submission should be a set of changes that addresses one issue in the [issue tracker](https://github.com/google/googletest/issues). Please don't mix more than one logical change per submittal, because it makes the history hard to follow. If you want to make a change that doesn't have a corresponding issue in the issue tracker, please create one.
-  1. Decide which code you want to submit. A submission should be a set of changes that addresses one issue in the [Google Test issue tracker](http://code.google.com/p/googletest/issues/list). Please don't mix more than one logical change per submittal, because it makes the history hard to follow. If you want to make a change that doesn't have a corresponding issue in the issue tracker, please create one.
   1. Also, coordinate with team members that are listed on the issue in question. This ensures that work isn't being duplicated and communicating your plan early also generally leads to better patches.
   1. Ensure that your code adheres to the [Google Test source code style](#Coding_Style.md).
   1. Ensure that there are unit tests for your code.
   1. Sign a Contributor License Agreement.
-  1. Create a patch file using `svn diff`.
+  1. Create a Pull Request in the usual way.
-  1. We use [Rietveld](http://codereview.appspot.com/) to do web-based code reviews.  You can read about the tool [here](http://code.google.com/p/rietveld/wiki/CodeReviewHelp).  When you are ready, upload your patch via Rietveld and notify `googletestframework@googlegroups.com` to review it.  There are several ways to upload the patch.  We recommend using the [upload\_gtest.py](http://code.google.com/p/googletest/source/browse/trunk/scripts/upload_gtest.py) script, which you can find in the `scripts/` folder in the SVN trunk.
 
 ## Google Test Committers ##
 
@@ -125,7 +113,7 @@ Test.
 
 # Release Process #
 
-We follow the typical release process for Subversion-based projects:
+We follow a typical release process:
 
   1. A release branch named `release-X.Y` is created.
   1. Bugs are fixed and features are added in trunk; those individual patches are merged into the release branch until it's stable.
@@ -133,7 +121,6 @@ We follow the typical release process for Subversion-based projects:
   1. Repeat steps 2 and 3 throughout one release cycle (as determined by features or time).
   1. Go back to step 1 to create another release branch and so on.
 
-
 ---
 
-This page is based on the [Making GWT Better](http://code.google.com/webtoolkit/makinggwtbetter.html) guide from the [Google Web Toolkit](http://code.google.com/webtoolkit/) project.  Except as otherwise [noted](http://code.google.com/policies.html#restrictions), the content of this page is licensed under the [Creative Commons Attribution 2.5 License](http://creativecommons.org/licenses/by/2.5/).
+This page is based on the [Making GWT Better](http://code.google.com/webtoolkit/makinggwtbetter.html) guide from the [Google Web Toolkit](http://code.google.com/webtoolkit/) project.  Except as otherwise [noted](http://code.google.com/policies.html#restrictions), the content of this page is licensed under the [Creative Commons Attribution 2.5 License](http://creativecommons.org/licenses/by/2.5/).

3rdparty/googletest/googletest/docs/FAQ.md

@@ -28,11 +28,11 @@ list can help you decide whether it is for you too.
   * `SCOPED_TRACE` helps you understand the context of an assertion failure when it comes from inside a sub-routine or loop.
   * You can decide which tests to run using name patterns.  This saves time when you want to quickly reproduce a test failure.
   * Google Test can generate XML test result reports that can be parsed by popular continuous build system like Hudson.
-  * Simple things are easy in Google Test, while hard things are possible: in addition to advanced features like [global test environments](http://code.google.com/p/googletest/wiki/AdvancedGuide#Global_Set-Up_and_Tear-Down) and tests parameterized by [values](http://code.google.com/p/googletest/wiki/AdvancedGuide#Value_Parameterized_Tests) or [types](http://code.google.com/p/googletest/wiki/AdvancedGuide#Typed_Tests), Google Test supports various ways for the user to extend the framework -- if Google Test doesn't do something out of the box, chances are that a user can implement the feature using Google Test's public API, without changing Google Test itself.  In particular, you can:
+  * Simple things are easy in Google Test, while hard things are possible: in addition to advanced features like [global test environments](AdvancedGuide.md#global-set-up-and-tear-down) and tests parameterized by [values](AdvancedGuide.md#value-parameterized-tests) or [types](docs/AdvancedGuide.md#typed-tests), Google Test supports various ways for the user to extend the framework -- if Google Test doesn't do something out of the box, chances are that a user can implement the feature using Google Test's public API, without changing Google Test itself.  In particular, you can:
-    * expand your testing vocabulary by defining [custom predicates](http://code.google.com/p/googletest/wiki/AdvancedGuide#Predicate_Assertions_for_Better_Error_Messages),
+    * expand your testing vocabulary by defining [custom predicates](AdvancedGuide.md#predicate-assertions-for-better-error-messages),
-    * teach Google Test how to [print your types](http://code.google.com/p/googletest/wiki/AdvancedGuide#Teaching_Google_Test_How_to_Print_Your_Values),
+    * teach Google Test how to [print your types](AdvancedGuide.md#teaching-google-test-how-to-print-your-values),
-    * define your own testing macros or utilities and verify them using Google Test's [Service Provider Interface](http://code.google.com/p/googletest/wiki/AdvancedGuide#Catching_Failures), and
+    * define your own testing macros or utilities and verify them using Google Test's [Service Provider Interface](AdvancedGuide.md#catching-failures), and
-    * reflect on the test cases or change the test output format by intercepting the [test events](http://code.google.com/p/googletest/wiki/AdvancedGuide#Extending_Google_Test_by_Handling_Test_Events).
+    * reflect on the test cases or change the test output format by intercepting the [test events](AdvancedGuide.md#extending-google-test-by-handling-test-events).
 
 ## I'm getting warnings when compiling Google Test.  Would you fix them? ##
 
@@ -76,7 +76,7 @@ for simplicity we just say that it cannot start with `_`.).
 
 It may seem fine for `TestCaseName` and `TestName` to contain `_` in the
 middle.  However, consider this:
-```
+``` cpp
 TEST(Time, Flies_Like_An_Arrow) { ... }
 TEST(Time_Flies, Like_An_Arrow) { ... }
 ```
@@ -201,7 +201,7 @@ we don't have a convention on the order of the two arguments for
 twice in the implementation, making it even harder to understand and
 maintain. We believe the benefit doesn't justify the cost.
 
-Finally, with the growth of Google Mock's [matcher](http://code.google.com/p/googlemock/wiki/CookBook#Using_Matchers_in_Google_Test_Assertions) library, we are
+Finally, with the growth of Google Mock's [matcher](../../googlemock/docs/CookBook.md#using-matchers-in-google-test-assertions) library, we are
 encouraging people to use the unified `EXPECT_THAT(value, matcher)`
 syntax more often in tests. One significant advantage of the matcher
 approach is that matchers can be easily combined to form new matchers,
@@ -242,7 +242,7 @@ of this approach:
   1. Throwing in a destructor is undefined behavior in C++.  Not using exceptions means Google Test's assertions are safe to use in destructors.
   1. The `EXPECT_*` family of macros will continue even after a failure, allowing multiple failures in a `TEST` to be reported in a single run. This is a popular feature, as in C++ the edit-compile-test cycle is usually quite long and being able to fixing more than one thing at a time is a blessing.
   1. If assertions are implemented using exceptions, a test may falsely ignore a failure if it's caught by user code:
-```
+``` cpp
 try { ... ASSERT_TRUE(...) ... }
 catch (...) { ... }
 ```
@@ -259,13 +259,13 @@ macro for both cases.  One possibility is to provide only one macro
 for tests with fixtures, and require the user to define an empty
 fixture sometimes:
 
-```
+``` cpp
 class FooTest : public ::testing::Test {};
 
 TEST_F(FooTest, DoesThis) { ... }
 ```
 or
-```
+``` cpp
 typedef ::testing::Test FooTest;
 
 TEST_F(FooTest, DoesThat) { ... }
@@ -293,7 +293,7 @@ possibly allows.  In particular:
   * The runner-style requires to split the information into two pieces: the definition of the death test itself, and the specification for the runner on how to run the death test and what to expect.  The death test would be written in C++, while the runner spec may or may not be.  A user needs to carefully keep the two in sync. `ASSERT_DEATH(statement, expected_message)` specifies all necessary information in one place, in one language, without boilerplate code. It is very declarative.
   * `ASSERT_DEATH` has a similar syntax and error-reporting semantics as other Google Test assertions, and thus is easy to learn.
   * `ASSERT_DEATH` can be mixed with other assertions and other logic at your will.  You are not limited to one death test per test method. For example, you can write something like:
-```
+``` cpp
     if (FooCondition()) {
       ASSERT_DEATH(Bar(), "blah");
     } else {
@@ -302,7 +302,7 @@ possibly allows.  In particular:
 ```
 If you prefer one death test per test method, you can write your tests in that style too, but we don't want to impose that on the users.  The fewer artificial limitations the better.
   * `ASSERT_DEATH` can reference local variables in the current function, and you can decide how many death tests you want based on run-time information.  For example,
-```
+``` cpp
     const int count = GetCount();  // Only known at run time.
     for (int i = 1; i <= count; i++) {
       ASSERT_DEATH({
@@ -335,7 +335,7 @@ as running in a parallel universe, more or less.
 
 If your class has a static data member:
 
-```
+``` cpp
 // foo.h
 class Foo {
   ...
@@ -345,7 +345,7 @@ class Foo {
 
 You also need to define it _outside_ of the class body in `foo.cc`:
 
-```
+``` cpp
 const int Foo::kBar;  // No initializer here.
 ```
 
@@ -376,7 +376,7 @@ to write tests using each derived fixture.
 
 Typically, your code looks like this:
 
-```
+``` cpp
 // Defines a base test fixture.
 class BaseTest : public ::testing::Test {
   protected:
@@ -409,7 +409,7 @@ If necessary, you can continue to derive test fixtures from a derived fixture.
 Google Test has no limit on how deep the hierarchy can be.
 
 For a complete example using derived test fixtures, see
-[sample5](http://code.google.com/p/googletest/source/browse/trunk/samples/sample5_unittest.cc).
+[sample5](../samples/sample5_unittest.cc).
 
 ## My compiler complains "void value not ignored as it ought to be." What does this mean? ##
 
@@ -476,7 +476,7 @@ explicitly telling the compiler which version to pick.
 
 For example, suppose you have
 
-```
+``` cpp
 bool IsPositive(int n) {
   return n > 0;
 }
@@ -487,13 +487,13 @@ bool IsPositive(double x) {
 
 you will get a compiler error if you write
 
-```
+``` cpp
 EXPECT_PRED1(IsPositive, 5);
 ```
 
 However, this will work:
 
-```
+``` cpp
 EXPECT_PRED1(*static_cast<bool (*)(int)>*(IsPositive), 5);
 ```
 
@@ -502,7 +502,7 @@ type of the function pointer for the `int`-version of `IsPositive()`.)
 
 As another example, when you have a template function
 
-```
+``` cpp
 template <typename T>
 bool IsNegative(T x) {
   return x < 0;
@@ -511,14 +511,14 @@ bool IsNegative(T x) {
 
 you can use it in a predicate assertion like this:
 
-```
+``` cpp
 ASSERT_PRED1(IsNegative*<int>*, -5);
 ```
 
 Things are more interesting if your template has more than one parameters. The
 following won't compile:
 
-```
+``` cpp
 ASSERT_PRED2(*GreaterThan<int, int>*, 5, 0);
 ```
 
@@ -527,7 +527,7 @@ as the C++ pre-processor thinks you are giving `ASSERT_PRED2` 4 arguments,
 which is one more than expected. The workaround is to wrap the predicate
 function in parentheses:
 
-```
+``` cpp
 ASSERT_PRED2(*(GreaterThan<int, int>)*, 5, 0);
 ```
 
@@ -537,13 +537,13 @@ ASSERT_PRED2(*(GreaterThan<int, int>)*, 5, 0);
 Some people had been ignoring the return value of `RUN_ALL_TESTS()`. That is,
 instead of
 
-```
+``` cpp
 return RUN_ALL_TESTS();
 ```
 
 they write
 
-```
+``` cpp
 RUN_ALL_TESTS();
 ```
 
@@ -562,7 +562,7 @@ is used as the return value of `main()`.
 Due to a peculiarity of C++, in order to support the syntax for streaming
 messages to an `ASSERT_*`, e.g.
 
-```
+``` cpp
 ASSERT_EQ(1, Foo()) << "blah blah" << foo;
 ```
 
@@ -591,7 +591,7 @@ the corresponding source code, or use `C-x `` to jump to the next failure.
 
 You don't have to. Instead of
 
-```
+``` cpp
 class FooTest : public BaseTest {};
 
 TEST_F(FooTest, Abc) { ... }
@@ -604,7 +604,7 @@ TEST_F(BarTest, Def) { ... }
 ```
 
 you can simply `typedef` the test fixtures:
-```
+``` cpp
 typedef BaseTest FooTest;
 
 TEST_F(FooTest, Abc) { ... }
@@ -646,7 +646,7 @@ members of the helper class public.
 
 You have several other options that don't require using `FRIEND_TEST`:
   * Write the tests as members of the fixture class:
-```
+``` cpp
 class Foo {
   friend class FooTest;
   ...
@@ -668,7 +668,7 @@ TEST_F(FooTest, Test2) {
 }
 ```
   * In the fixture class, write accessors for the tested class' private members, then use the accessors in your tests:
-```
+``` cpp
 class Foo {
   friend class FooTest;
   ...
@@ -689,7 +689,7 @@ TEST_F(FooTest, Test1) {
 }
 ```
   * If the methods are declared **protected**, you can change their access level in a test-only subclass:
-```
+``` cpp
 class YourClass {
   ...
  protected: // protected access for testability.
@@ -717,7 +717,7 @@ implementation details and ideally should be kept out of a .h. So often I make
 them free functions instead.
 
 Instead of:
-```
+``` cpp
 // foo.h
 class Foo {
   ...
@@ -733,7 +733,7 @@ EXPECT_TRUE(Foo::Func(12345));
 ```
 
 You probably should better write:
-```
+``` cpp
 // foo.h
 class Foo {
   ...
@@ -754,7 +754,7 @@ EXPECT_TRUE(internal::Func(12345));
 
 ## I would like to run a test several times with different parameters. Do I need to write several similar copies of it? ##
 
-No. You can use a feature called [value-parameterized tests](AdvancedGuide#Value_Parameterized_Tests.md) which
+No. You can use a feature called [value-parameterized tests](AdvancedGuide.md#Value_Parameterized_Tests) which
 lets you repeat your tests with different parameters, without defining it more than once.
 
 ## How do I test a file that defines main()? ##
@@ -774,7 +774,7 @@ Then `foo.cc` can be easily tested.
 If you are adding tests to an existing file and don't want an intrusive change
 like this, there is a hack: just include the entire `foo.cc` file in your unit
 test. For example:
-```
+``` cpp
 // File foo_unittest.cc
 
 // The headers section
@@ -803,8 +803,9 @@ reference global and/or local variables, and can be:
   * a complex expression, or
   * a compound statement.
 
-> Some examples are shown here:
+Some examples are shown here:
-```
+
+``` cpp
 // A death test can be a simple function call.
 TEST(MyDeathTest, FunctionCall) {
   ASSERT_DEATH(Xyz(5), "Xyz failed");
@@ -848,7 +849,7 @@ expression syntax
 (http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions).
 On Windows, it uses a limited variant of regular expression
 syntax. For more details, see the
-[regular expression syntax](AdvancedGuide#Regular_Expression_Syntax.md).
+[regular expression syntax](AdvancedGuide.md#Regular_Expression_Syntax).
 
 ## I have a fixture class Foo, but TEST\_F(Foo, Bar) gives me error "no matching function for call to Foo::Foo()". Why? ##
 
@@ -883,7 +884,7 @@ inefficient and makes the semantics unclean.
 If we were to determine the order of tests based on test name instead of test
 case name, then we would have a problem with the following situation:
 
-```
+``` cpp
 TEST_F(FooTest, AbcDeathTest) { ... }
 TEST_F(FooTest, Uvw) { ... }
 
@@ -902,7 +903,7 @@ You don't have to, but if you like, you may split up the test case into
 `FooTest` and `FooDeathTest`, where the names make it clear that they are
 related:
 
-```
+``` cpp
 class FooTest : public ::testing::Test { ... };
 
 TEST_F(FooTest, Abc) { ... }
@@ -955,13 +956,12 @@ using gtest-md.vcproj instead of gtest.vcproj.
 
 ## I put my tests in a library and Google Test doesn't run them. What's happening? ##
 Have you read a
-[warning](http://code.google.com/p/googletest/wiki/Primer#Important_note_for_Visual_C++_users) on
+[warning](Primer.md#important-note-for-visual-c-users) on
 the Google Test Primer page?
 
 ## I want to use Google Test with Visual Studio but don't know where to start. ##
 Many people are in your position and one of the posted his solution to
-our mailing list. Here is his link:
+our mailing list.
-http://hassanjamilahmad.blogspot.com/2009/07/gtest-starters-help.html.
 
 ## I am seeing compile errors mentioning std::type\_traits when I try to use Google Test on Solaris. ##
 Google Test uses parts of the standard C++ library that SunStudio does not support.
@@ -994,7 +994,7 @@ you can use the _horrible_ hack of sniffing your executable name
 ## Google Test defines a macro that clashes with one defined by another library. How do I deal with that? ##
 
 In C++, macros don't obey namespaces.  Therefore two libraries that
-both define a macro of the same name will clash if you #include both
+both define a macro of the same name will clash if you `#include` both
 definitions.  In case a Google Test macro clashes with another
 library, you can force Google Test to rename its macro to avoid the
 conflict.
@@ -1006,11 +1006,11 @@ Specifically, if both Google Test and some other code define macro
 ```
 to the compiler flags to tell Google Test to change the macro's name
 from `FOO` to `GTEST_FOO`. For example, with `-DGTEST_DONT_DEFINE_TEST=1`, you'll need to write
-```
+``` cpp
   GTEST_TEST(SomeTest, DoesThis) { ... }
 ```
 instead of
-```
+``` cpp
   TEST(SomeTest, DoesThis) { ... }
 ```
 in order to define a test.
@@ -1024,7 +1024,7 @@ Yes.
 
 The rule is **all test methods in the same test case must use the same fixture class**. This means that the following is **allowed** because both tests use the same fixture class (`::testing::Test`).
 
-```
+``` cpp
 namespace foo {
 TEST(CoolTest, DoSomething) {
   SUCCEED();
@@ -1040,7 +1040,7 @@ TEST(CoolTest, DoSomething) {
 
 However, the following code is **not allowed** and will produce a runtime error from Google Test because the test methods are using different test fixture classes with the same test case name.
 
-```
+``` cpp
 namespace foo {
 class CoolTest : public ::testing::Test {};  // Fixture foo::CoolTest
 TEST_F(CoolTest, DoSomething) {
@@ -1059,19 +1059,19 @@ TEST_F(CoolTest, DoSomething) {
 ## How do I build Google Testing Framework with Xcode 4? ##
 
 If you try to build Google Test's Xcode project with Xcode 4.0 or later, you may encounter an error message that looks like
-"Missing SDK in target gtest\_framework: /Developer/SDKs/MacOSX10.4u.sdk". That means that Xcode does not support the SDK the project is targeting. See the Xcode section in the [README](http://code.google.com/p/googletest/source/browse/trunk/README) file on how to resolve this.
+"Missing SDK in target gtest\_framework: /Developer/SDKs/MacOSX10.4u.sdk". That means that Xcode does not support the SDK the project is targeting. See the Xcode section in the [README](../README.md) file on how to resolve this.
 
 ## My question is not covered in your FAQ! ##
 
 If you cannot find the answer to your question in this FAQ, there are
 some other resources you can use:
 
-  1. read other [wiki pages](http://code.google.com/p/googletest/w/list),
+  1. read other [wiki pages](../docs),
-  1. search the mailing list [archive](http://groups.google.com/group/googletestframework/topics),
+  1. search the mailing list [archive](https://groups.google.com/forum/#!forum/googletestframework),
   1. ask it on [googletestframework@googlegroups.com](mailto:googletestframework@googlegroups.com) and someone will answer it (to prevent spam, we require you to join the [discussion group](http://groups.google.com/group/googletestframework) before you can post.).
 
 Please note that creating an issue in the
-[issue tracker](http://code.google.com/p/googletest/issues/list) is _not_
+[issue tracker](https://github.com/google/googletest/issues) is _not_
 a good way to get your answer, as it is monitored infrequently by a
 very small number of people.
 
@@ -1079,9 +1079,9 @@ When asking a question, it's helpful to provide as much of the
 following information as possible (people cannot help you if there's
 not enough information in your question):
 
-  * the version (or the revision number if you check out from SVN directly) of Google Test you use (Google Test is under active development, so it's possible that your problem has been solved in a later version),
+  * the version (or the commit hash if you check out from Git directly) of Google Test you use (Google Test is under active development, so it's possible that your problem has been solved in a later version),
   * your operating system,
   * the name and version of your compiler,
   * the complete command line flags you give to your compiler,
   * the complete compiler error messages (if the question is about compilation),
-  * the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.
+  * the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.

3rdparty/googletest/googletest/docs/Primer.md

@@ -127,18 +127,14 @@ This section describes assertions that compare two values.
 
 | **Fatal assertion** | **Nonfatal assertion** | **Verifies** |
 |:--------------------|:-----------------------|:-------------|
-|`ASSERT_EQ(`_expected_`, `_actual_`);`|`EXPECT_EQ(`_expected_`, `_actual_`);`| _expected_ `==` _actual_ |
+|`ASSERT_EQ(`_val1_`, `_val2_`);`|`EXPECT_EQ(`_val1_`, `_val2_`);`| _val1_ `==` _val2_ |
-|`ASSERT_NE(`_val1_`, `_val2_`);`      |`EXPECT_NE(`_val1_`, `_val2_`);`      | _val1_ `!=` _val2_ |
+|`ASSERT_NE(`_val1_`, `_val2_`);`|`EXPECT_NE(`_val1_`, `_val2_`);`| _val1_ `!=` _val2_ |
-|`ASSERT_LT(`_val1_`, `_val2_`);`      |`EXPECT_LT(`_val1_`, `_val2_`);`      | _val1_ `<` _val2_ |
+|`ASSERT_LT(`_val1_`, `_val2_`);`|`EXPECT_LT(`_val1_`, `_val2_`);`| _val1_ `<` _val2_ |
-|`ASSERT_LE(`_val1_`, `_val2_`);`      |`EXPECT_LE(`_val1_`, `_val2_`);`      | _val1_ `<=` _val2_ |
+|`ASSERT_LE(`_val1_`, `_val2_`);`|`EXPECT_LE(`_val1_`, `_val2_`);`| _val1_ `<=` _val2_ |
-|`ASSERT_GT(`_val1_`, `_val2_`);`      |`EXPECT_GT(`_val1_`, `_val2_`);`      | _val1_ `>` _val2_ |
+|`ASSERT_GT(`_val1_`, `_val2_`);`|`EXPECT_GT(`_val1_`, `_val2_`);`| _val1_ `>` _val2_ |
-|`ASSERT_GE(`_val1_`, `_val2_`);`      |`EXPECT_GE(`_val1_`, `_val2_`);`      | _val1_ `>=` _val2_ |
+|`ASSERT_GE(`_val1_`, `_val2_`);`|`EXPECT_GE(`_val1_`, `_val2_`);`| _val1_ `>=` _val2_ |
 
-In the event of a failure, Google Test prints both _val1_ and _val2_
+In the event of a failure, Google Test prints both _val1_ and _val2_.
-. In `ASSERT_EQ*` and `EXPECT_EQ*` (and all other equality assertions
-we'll introduce later), you should put the expression you want to test
-in the position of _actual_, and put its expected value in _expected_,
-as Google Test's failure messages are optimized for this convention.
 
 Value arguments must be comparable by the assertion's comparison
 operator or you'll get a compiler error.  We used to require the
@@ -147,7 +143,7 @@ but it's no longer necessary since v1.6.0 (if `<<` is supported, it
 will be called to print the arguments when the assertion fails;
 otherwise Google Test will attempt to print them in the best way it
 can. For more details and how to customize the printing of the
-arguments, see this Google Mock [recipe](http://code.google.com/p/googlemock/wiki/CookBook#Teaching_Google_Mock_How_to_Print_Your_Values).).
+arguments, see this Google Mock [recipe](../../googlemock/docs/CookBook.md#teaching-google-mock-how-to-print-your-values).).
 
 These assertions can work with a user-defined type, but only if you define the
 corresponding comparison operator (e.g. `==`, `<`, etc).  If the corresponding
@@ -172,6 +168,10 @@ and `wstring`).
 
 _Availability_: Linux, Windows, Mac.
 
+_Historical note_: Before February 2016 `*_EQ` had a convention of calling it as
+`ASSERT_EQ(expected, actual)`, so lots of existing code uses this order.
+Now `*_EQ` treats both parameters in the same way.
+
 ## String Comparison ##
 
 The assertions in this group compare two **C strings**. If you want to compare
@@ -179,9 +179,9 @@ two `string` objects, use `EXPECT_EQ`, `EXPECT_NE`, and etc instead.
 
 | **Fatal assertion** | **Nonfatal assertion** | **Verifies** |
 |:--------------------|:-----------------------|:-------------|
-| `ASSERT_STREQ(`_expected\_str_`, `_actual\_str_`);`    | `EXPECT_STREQ(`_expected\_str_`, `_actual\_str_`);`     | the two C strings have the same content |
+| `ASSERT_STREQ(`_str1_`, `_str2_`);`    | `EXPECT_STREQ(`_str1_`, `_str_2`);`     | the two C strings have the same content |
 | `ASSERT_STRNE(`_str1_`, `_str2_`);`    | `EXPECT_STRNE(`_str1_`, `_str2_`);`     | the two C strings have different content |
-| `ASSERT_STRCASEEQ(`_expected\_str_`, `_actual\_str_`);`| `EXPECT_STRCASEEQ(`_expected\_str_`, `_actual\_str_`);` | the two C strings have the same content, ignoring case |
+| `ASSERT_STRCASEEQ(`_str1_`, `_str2_`);`| `EXPECT_STRCASEEQ(`_str1_`, `_str2_`);` | the two C strings have the same content, ignoring case |
 | `ASSERT_STRCASENE(`_str1_`, `_str2_`);`| `EXPECT_STRCASENE(`_str1_`, `_str2_`);` | the two C strings have different content, ignoring case |
 
 Note that "CASE" in an assertion name means that case is ignored.
@@ -256,7 +256,7 @@ To create a fixture, just:
   1. Derive a class from `::testing::Test` . Start its body with `protected:` or `public:` as we'll want to access fixture members from sub-classes.
   1. Inside the class, declare any objects you plan to use.
   1. If necessary, write a default constructor or `SetUp()` function to prepare the objects for each test. A common mistake is to spell `SetUp()` as `Setup()` with a small `u` - don't let that happen to you.
-  1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](http://code.google.com/p/googletest/wiki/FAQ#Should_I_use_the_constructor/destructor_of_the_test_fixture_or_t).
+  1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](FAQ.md#should-i-use-the-constructordestructor-of-the-test-fixture-or-the-set-uptear-down-function).
   1. If needed, define subroutines for your tests to share.
 
 When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to

3rdparty/googletest/googletest/docs/V1_5_AdvancedGuide.md

@@ -123,7 +123,7 @@ c is 10<br>
 
 **Notes:**
 
-  1. If you see a compiler error "no matching function to call" when using `ASSERT_PRED*` or `EXPECT_PRED*`, please see [this](http://code.google.com/p/googletest/wiki/V1_5_FAQ#The_compiler_complains_%22no_matching_function_to_call%22) for how to resolve it.
+  1. If you see a compiler error "no matching function to call" when using `ASSERT_PRED*` or `EXPECT_PRED*`, please see [this](V1_5_FAQ.md#the-compiler-complains-about-undefined-references-to-some-static-const-member-variables-but-i-did-define-them-in-the-class-body-whats-wrong) for how to resolve it.
   1. Currently we only provide predicate assertions of arity <= 5. If you need a higher-arity assertion, let us know.
 
 _Availability_: Linux, Windows, Mac
@@ -263,7 +263,7 @@ int SmallestPrimeCommonDivisor(int m, int n) { ... }
                                                int n) {
   if (MutuallyPrime(m, n))
     return ::testing::AssertionSuccess();
- 
+
   return ::testing::AssertionFailure()
       << m_expr << " and " << n_expr << " (" << m << " and " << n
       << ") are not mutually prime, " << "as they have a common divisor "
@@ -444,7 +444,7 @@ Since these precondition checks cause the processes to die, we call such tests
 _death tests_. More generally, any test that checks that a program terminates
 in an expected fashion is also a death test.
 
-If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see [Catching Failures](#Catching_Failures.md).
+If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see [Catching Failures](#catching-failures).
 
 ## How to Write a Death Test ##
 
@@ -729,7 +729,7 @@ For example,
 11:   EXPECT_EQ(1, Bar(n));
 12:   EXPECT_EQ(2, Bar(n + 1));
 13: }
-14: 
+14:
 15: TEST(FooTest, Bar) {
 16:   {
 17:     SCOPED_TRACE("A");  // This trace point will be included in
@@ -1114,9 +1114,9 @@ which are all in the `testing` namespace:
 | `Values(v1, v2, ..., vN)`   | Yields values `{v1, v2, ..., vN}`.                                                                                |
 | `ValuesIn(container)` and `ValuesIn(begin, end)` | Yields values from a C-style array, an STL-style container, or an iterator range `[begin, end)`.                  |
 | `Bool()`                    | Yields sequence `{false, true}`.                                                                                  |
-| `Combine(g1, g2, ..., gN)`  | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/internal/gtest-port.h) for more information. |
+| `Combine(g1, g2, ..., gN)`  | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](../include/gtest/internal/gtest-port.h) for more information. |
 
-For more details, see the comments at the definitions of these functions in the [source code](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-param-test.h).
+For more details, see the comments at the definitions of these functions in the [source code](../include/gtest/gtest-param-test.h).
 
 The following statement will instantiate tests from the `FooTest` test case
 each with parameter values `"meeny"`, `"miny"`, and `"moe"`.
@@ -1141,7 +1141,7 @@ names:
   * `InstantiationName/FooTest.HasBlahBlah/1` for `"miny"`
   * `InstantiationName/FooTest.HasBlahBlah/2` for `"moe"`
 
-You can use these names in [--gtest\_filter](#Running_a_Subset_of_the_Tests.md).
+You can use these names in [--gtest\-filter](#running-a-subset-of-the-tests).
 
 This statement will instantiate all tests from `FooTest` again, each
 with parameter values `"cat"` and `"dog"`:
@@ -1164,8 +1164,8 @@ tests in the given test case, whether their definitions come before or
 _after_ the `INSTANTIATE_TEST_CASE_P` statement.
 
 You can see
-[these](http://code.google.com/p/googletest/source/browse/trunk/samples/sample7_unittest.cc)
+[these](../samples/sample7_unittest.cc)
-[files](http://code.google.com/p/googletest/source/browse/trunk/samples/sample8_unittest.cc) for more examples.
+[files](../samples/sample8_unittest.cc) for more examples.
 
 _Availability_: Linux, Windows (requires MSVC 8.0 or above), Mac; since version 1.2.0.
 
@@ -1365,7 +1365,7 @@ two cases to consider:
 
 Both static functions and definitions/declarations in an unnamed namespace are
 only visible within the same translation unit. To test them, you can `#include`
-the entire `.cc` file being tested in your `*_test.cc` file. (#including `.cc`
+the entire `.cc` file being tested in your `*_test.cc` file. (`#include`ing `.cc`
 files is not a good way to reuse code - you should not do this in production
 code!)
 
@@ -1467,7 +1467,7 @@ Test doesn't use exceptions, so how do we test that a piece of code
 generates an expected failure?
 
 `<gtest/gtest-spi.h>` contains some constructs to do this.  After
-#including this header, you can use
+`#include`ing this header, you can use
 
 | `EXPECT_FATAL_FAILURE(`_statement, substring_`);` |
 |:--------------------------------------------------|
@@ -1561,8 +1561,8 @@ _Availability:_ Linux, Windows, Mac; since v1.4.0.
 ## Defining Event Listeners ##
 
 To define a event listener, you subclass either
-[testing::TestEventListener](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#855)
+[testing::TestEventListener](../include/gtest/gtest.h#L855)
-or [testing::EmptyTestEventListener](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#905).
+or [testing::EmptyTestEventListener](../include/gtest/gtest.h#L905).
 The former is an (abstract) interface, where <i>each pure virtual method<br>
 can be overridden to handle a test event</i> (For example, when a test
 starts, the `OnTestStart()` method will be called.). The latter provides
@@ -1571,10 +1571,10 @@ subclass only needs to override the methods it cares about.
 
 When an event is fired, its context is passed to the handler function
 as an argument. The following argument types are used:
-  * [UnitTest](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#1007) reflects the state of the entire test program,
+  * [UnitTest](../include/gtest/gtest.h#L1007) reflects the state of the entire test program,
-  * [TestCase](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#689) has information about a test case, which can contain one or more tests,
+  * [TestCase](../include/gtest/gtest.h#L689) has information about a test case, which can contain one or more tests,
-  * [TestInfo](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#599) contains the state of a test, and
+  * [TestInfo](../include/gtest/gtest.h#L599) contains the state of a test, and
-  * [TestPartResult](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-test-part.h#42) represents the result of a test assertion.
+  * [TestPartResult](../include/gtest/gtest-test-part.h#L42) represents the result of a test assertion.
 
 An event handler function can examine the argument it receives to find
 out interesting information about the event and the test program's
@@ -1610,7 +1610,7 @@ state.  Here's an example:
 
 To use the event listener you have defined, add an instance of it to
 the Google Test event listener list (represented by class
-[TestEventListeners](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#929)
+[TestEventListeners](../include/gtest/gtest.h#L929)
 - note the "s" at the end of the name) in your
 `main()` function, before calling `RUN_ALL_TESTS()`:
 ```
@@ -1638,7 +1638,7 @@ event listener list and delete it. You can do so by adding one line:
 
 Now, sit back and enjoy a completely different output from your
 tests. For more details, you can read this
-[sample](http://code.google.com/p/googletest/source/browse/trunk/samples/sample9_unittest.cc).
+[sample](../samples/sample9_unittest.cc).
 
 You may append more than one listener to the list. When an `On*Start()`
 or `OnTestPartResult()` event is fired, the listeners will receive it in
@@ -1663,7 +1663,7 @@ failures. This ensures that failures generated by the latter are
 attributed to the right test by the former.
 
 We have a sample of failure-raising listener
-[here](http://code.google.com/p/googletest/source/browse/trunk/samples/sample10_unittest.cc).
+[here](../samples/sample10_unittest.cc).
 
 # Running Test Programs: Advanced Options #
 
@@ -1783,12 +1783,12 @@ _Availability:_ Linux, Windows, Mac.
 
 ### Temporarily Enabling Disabled Tests ###
 
-To include [disabled tests](#Temporarily_Disabling_Tests.md) in test
+To include [disabled tests](#temporarily-disabling-tests) in test
 execution, just invoke the test program with the
 `--gtest_also_run_disabled_tests` flag or set the
 `GTEST_ALSO_RUN_DISABLED_TESTS` environment variable to a value other
 than `0`.  You can combine this with the
-[--gtest\_filter](#Running_a_Subset_of_the_Tests.md) flag to further select
+[--gtest\_filter](#running-a-subset-of-the-tests) flag to further select
 which disabled tests to run.
 
 _Availability:_ Linux, Windows, Mac; since version 1.3.0.
@@ -2086,11 +2086,11 @@ and you should see an `OUTPUT_DIR` directory being created with files
 `gtest/gtest.h` and `gtest/gtest-all.cc` in it.  These files contain
 everything you need to use Google Test.  Just copy them to anywhere
 you want and you are ready to write tests.  You can use the
-[scrpts/test/Makefile](http://code.google.com/p/googletest/source/browse/trunk/scripts/test/Makefile)
+[scrpts/test/Makefile](../scripts/test/Makefile)
 file as an example on how to compile your tests against them.
 
 # Where to Go from Here #
 
 Congratulations! You've now learned more advanced Google Test tools and are
 ready to tackle more complex testing tasks. If you want to dive even deeper, you
-can read the [FAQ](V1_5_FAQ.md).
+can read the [FAQ](V1_5_FAQ.md).

3rdparty/googletest/googletest/docs/V1_5_FAQ.md

@@ -104,7 +104,7 @@ we don't have a convention on the order of the two arguments for
 twice in the implementation, making it even harder to understand and
 maintain. We believe the benefit doesn't justify the cost.
 
-Finally, with the growth of Google Mock's [matcher](http://code.google.com/p/googlemock/wiki/CookBook#Using_Matchers_in_Google_Test_Assertions) library, we are
+Finally, with the growth of Google Mock's [matcher](../../CookBook.md#using-matchers-in-google-test-assertions) library, we are
 encouraging people to use the unified `EXPECT_THAT(value, matcher)`
 syntax more often in tests. One significant advantage of the matcher
 approach is that matchers can be easily combined to form new matchers,
@@ -651,7 +651,7 @@ EXPECT_TRUE(internal::Func(12345));
 
 ## I would like to run a test several times with different parameters. Do I need to write several similar copies of it? ##
 
-No. You can use a feature called [value-parameterized tests](V1_5_AdvancedGuide#Value_Parameterized_Tests.md) which
+No. You can use a feature called [value-parameterized tests](V1_5_AdvancedGuide.md#Value_Parameterized_Tests) which
 lets you repeat your tests with different parameters, without defining it more than once.
 
 ## How do I test a file that defines main()? ##
@@ -701,6 +701,7 @@ reference global and/or local variables, and can be:
   * a compound statement.
 
 > Some examples are shown here:
+
 ```
 // A death test can be a simple function call.
 TEST(MyDeathTest, FunctionCall) {
@@ -744,7 +745,7 @@ On POSIX systems, Google Test uses the POSIX Extended regular
 expression syntax
 (http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions). On
 Windows, it uses a limited variant of regular expression syntax. For
-more details, see the [regular expression syntax](V1_5_AdvancedGuide#Regular_Expression_Syntax.md).
+more details, see the [regular expression syntax](V1_5_AdvancedGuide.md#Regular_Expression_Syntax).
 
 ## I have a fixture class Foo, but TEST\_F(Foo, Bar) gives me error "no matching function for call to Foo::Foo()". Why? ##
 
@@ -851,7 +852,7 @@ using gtest-md.vcproj instead of gtest.vcproj.
 
 ## I put my tests in a library and Google Test doesn't run them. What's happening? ##
 Have you read a
-[warning](V1_5_Primer#Important_note_for_Visual_C++_users.md) on
+[warning](V1_5_Primer.md#important-note-for-visual-c-users) on
 the Google Test Primer page?
 
 ## I want to use Google Test with Visual Studio but don't know where to start. ##
@@ -882,4 +883,4 @@ not enough information in your question):
   * the name and version of your compiler,
   * the complete command line flags you give to your compiler,
   * the complete compiler error messages (if the question is about compilation),
-  * the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.
+  * the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.

3rdparty/googletest/googletest/docs/V1_5_Primer.md

@@ -251,7 +251,7 @@ To create a fixture, just:
   1. Derive a class from `::testing::Test` . Start its body with `protected:` or `public:` as we'll want to access fixture members from sub-classes.
   1. Inside the class, declare any objects you plan to use.
   1. If necessary, write a default constructor or `SetUp()` function to prepare the objects for each test. A common mistake is to spell `SetUp()` as `Setup()` with a small `u` - don't let that happen to you.
-  1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](http://code.google.com/p/googletest/wiki/V1_5_FAQ#Should_I_use_the_constructor/destructor_of_the_test_fixture_or_t).
+  1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](V1_5_FAQ.md#should-i-use-the-constructordestructor-of-the-test-fixture-or-the-set-uptear-down-function).
   1. If needed, define subroutines for your tests to share.
 
 When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to
@@ -494,4 +494,4 @@ is currently _unsafe_ to use Google Test assertions from two threads
 concurrently on other systems (e.g. Windows).  In most tests this is
 not an issue as usually the assertions are done in the main thread. If
 you want to help, you can volunteer to implement the necessary
-synchronization primitives in `gtest-port.h` for your platform.
+synchronization primitives in `gtest-port.h` for your platform.

3rdparty/googletest/googletest/docs/V1_6_AdvancedGuide.md

@@ -123,7 +123,7 @@ c is 10<br>
 
 **Notes:**
 
-  1. If you see a compiler error "no matching function to call" when using `ASSERT_PRED*` or `EXPECT_PRED*`, please see [this](http://code.google.com/p/googletest/wiki/V1_6_FAQ#The_compiler_complains_%22no_matching_function_to_call%22) for how to resolve it.
+  1. If you see a compiler error "no matching function to call" when using `ASSERT_PRED*` or `EXPECT_PRED*`, please see [this](v1_6_FAQ.md#ithe-compiler-complains-about-undefined-references-to-some-static-const-member-variables-but-i-did-define-them-in-the-class-body-whats-wrong) for how to resolve it.
   1. Currently we only provide predicate assertions of arity <= 5. If you need a higher-arity assertion, let us know.
 
 _Availability_: Linux, Windows, Mac
@@ -263,7 +263,7 @@ int SmallestPrimeCommonDivisor(int m, int n) { ... }
                                                int n) {
   if (MutuallyPrime(m, n))
     return ::testing::AssertionSuccess();
- 
+
   return ::testing::AssertionFailure()
       << m_expr << " and " << n_expr << " (" << m << " and " << n
       << ") are not mutually prime, " << "as they have a common divisor "
@@ -515,9 +515,9 @@ _death tests_. More generally, any test that checks that a program terminates
 Note that if a piece of code throws an exception, we don't consider it "death"
 for the purpose of death tests, as the caller of the code could catch the exception
 and avoid the crash. If you want to verify exceptions thrown by your code,
-see [Exception Assertions](#Exception_Assertions.md).
+see [Exception Assertions](#exception-assertions).
 
-If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see [Catching Failures](#Catching_Failures.md).
+If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see [Catching Failures](#catching-failures).
 
 ## How to Write a Death Test ##
 
@@ -801,7 +801,7 @@ For example,
 11:   EXPECT_EQ(1, Bar(n));
 12:   EXPECT_EQ(2, Bar(n + 1));
 13: }
-14: 
+14:
 15: TEST(FooTest, Bar) {
 16:   {
 17:     SCOPED_TRACE("A");  // This trace point will be included in
@@ -1196,9 +1196,9 @@ which are all in the `testing` namespace:
 | `Values(v1, v2, ..., vN)`   | Yields values `{v1, v2, ..., vN}`.                                                                                |
 | `ValuesIn(container)` and `ValuesIn(begin, end)` | Yields values from a C-style array, an STL-style container, or an iterator range `[begin, end)`. `container`, `begin`, and `end` can be expressions whose values are determined at run time.  |
 | `Bool()`                    | Yields sequence `{false, true}`.                                                                                  |
-| `Combine(g1, g2, ..., gN)`  | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/internal/gtest-port.h) for more information. |
+| `Combine(g1, g2, ..., gN)`  | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](../include/gtest/internal/gtest-port.h) for more information. |
 
-For more details, see the comments at the definitions of these functions in the [source code](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-param-test.h).
+For more details, see the comments at the definitions of these functions in the [source code](../include/gtest/gtest-param-test.h).
 
 The following statement will instantiate tests from the `FooTest` test case
 each with parameter values `"meeny"`, `"miny"`, and `"moe"`.
@@ -1223,7 +1223,7 @@ names:
   * `InstantiationName/FooTest.HasBlahBlah/1` for `"miny"`
   * `InstantiationName/FooTest.HasBlahBlah/2` for `"moe"`
 
-You can use these names in [--gtest\_filter](#Running_a_Subset_of_the_Tests.md).
+You can use these names in [--gtest\-filter](#running-a-subset-of-the-tests).
 
 This statement will instantiate all tests from `FooTest` again, each
 with parameter values `"cat"` and `"dog"`:
@@ -1246,8 +1246,8 @@ tests in the given test case, whether their definitions come before or
 _after_ the `INSTANTIATE_TEST_CASE_P` statement.
 
 You can see
-[these](http://code.google.com/p/googletest/source/browse/trunk/samples/sample7_unittest.cc)
+[these](../samples/sample7_unittest.cc)
-[files](http://code.google.com/p/googletest/source/browse/trunk/samples/sample8_unittest.cc) for more examples.
+[files](../samples/sample8_unittest.cc) for more examples.
 
 _Availability_: Linux, Windows (requires MSVC 8.0 or above), Mac; since version 1.2.0.
 
@@ -1447,7 +1447,7 @@ two cases to consider:
 
 Both static functions and definitions/declarations in an unnamed namespace are
 only visible within the same translation unit. To test them, you can `#include`
-the entire `.cc` file being tested in your `*_test.cc` file. (#including `.cc`
+the entire `.cc` file being tested in your `*_test.cc` file. (`#include`ing `.cc`
 files is not a good way to reuse code - you should not do this in production
 code!)
 
@@ -1549,7 +1549,7 @@ Test doesn't use exceptions, so how do we test that a piece of code
 generates an expected failure?
 
 `"gtest/gtest-spi.h"` contains some constructs to do this.  After
-#including this header, you can use
+`#include`ing this header, you can use
 
 | `EXPECT_FATAL_FAILURE(`_statement, substring_`);` |
 |:--------------------------------------------------|
@@ -1643,8 +1643,8 @@ _Availability:_ Linux, Windows, Mac; since v1.4.0.
 ## Defining Event Listeners ##
 
 To define a event listener, you subclass either
-[testing::TestEventListener](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#855)
+[testing::TestEventListener](../include/gtest/gtest.h#L855)
-or [testing::EmptyTestEventListener](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#905).
+or [testing::EmptyTestEventListener](../include/gtest/gtest.h#L905).
 The former is an (abstract) interface, where <i>each pure virtual method<br>
 can be overridden to handle a test event</i> (For example, when a test
 starts, the `OnTestStart()` method will be called.). The latter provides
@@ -1653,10 +1653,10 @@ subclass only needs to override the methods it cares about.
 
 When an event is fired, its context is passed to the handler function
 as an argument. The following argument types are used:
-  * [UnitTest](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#1007) reflects the state of the entire test program,
+  * [UnitTest](../include/gtest/gtest.h#L1007) reflects the state of the entire test program,
-  * [TestCase](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#689) has information about a test case, which can contain one or more tests,
+  * [TestCase](../include/gtest/gtest.h#L689) has information about a test case, which can contain one or more tests,
-  * [TestInfo](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#599) contains the state of a test, and
+  * [TestInfo](../include/gtest/gtest.h#L599) contains the state of a test, and
-  * [TestPartResult](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-test-part.h#42) represents the result of a test assertion.
+  * [TestPartResult](../include/gtest/gtest-test-part.h#L42) represents the result of a test assertion.
 
 An event handler function can examine the argument it receives to find
 out interesting information about the event and the test program's
@@ -1692,7 +1692,7 @@ state.  Here's an example:
 
 To use the event listener you have defined, add an instance of it to
 the Google Test event listener list (represented by class
-[TestEventListeners](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#929)
+[TestEventListeners](../include/gtest/gtest.h#L929)
 - note the "s" at the end of the name) in your
 `main()` function, before calling `RUN_ALL_TESTS()`:
 ```
@@ -1720,7 +1720,7 @@ event listener list and delete it. You can do so by adding one line:
 
 Now, sit back and enjoy a completely different output from your
 tests. For more details, you can read this
-[sample](http://code.google.com/p/googletest/source/browse/trunk/samples/sample9_unittest.cc).
+[sample](../samples/sample9_unittest.cc).
 
 You may append more than one listener to the list. When an `On*Start()`
 or `OnTestPartResult()` event is fired, the listeners will receive it in
@@ -1745,7 +1745,7 @@ failures. This ensures that failures generated by the latter are
 attributed to the right test by the former.
 
 We have a sample of failure-raising listener
-[here](http://code.google.com/p/googletest/source/browse/trunk/samples/sample10_unittest.cc).
+[here](../samples/sample10_unittest.cc).
 
 # Running Test Programs: Advanced Options #
 
@@ -1865,12 +1865,12 @@ _Availability:_ Linux, Windows, Mac.
 
 ### Temporarily Enabling Disabled Tests ###
 
-To include [disabled tests](#Temporarily_Disabling_Tests.md) in test
+To include [disabled tests](#temporarily-disabling-tests) in test
 execution, just invoke the test program with the
 `--gtest_also_run_disabled_tests` flag or set the
 `GTEST_ALSO_RUN_DISABLED_TESTS` environment variable to a value other
 than `0`.  You can combine this with the
-[--gtest\_filter](#Running_a_Subset_of_the_Tests.md) flag to further select
+[--gtest\-filter](#running-a-subset-of-the_tests) flag to further select
 which disabled tests to run.
 
 _Availability:_ Linux, Windows, Mac; since version 1.3.0.
@@ -2168,11 +2168,11 @@ and you should see an `OUTPUT_DIR` directory being created with files
 `gtest/gtest.h` and `gtest/gtest-all.cc` in it.  These files contain
 everything you need to use Google Test.  Just copy them to anywhere
 you want and you are ready to write tests.  You can use the
-[scripts/test/Makefile](http://code.google.com/p/googletest/source/browse/trunk/scripts/test/Makefile)
+[scripts/test/Makefile](../scripts/test/Makefile)
 file as an example on how to compile your tests against them.
 
 # Where to Go from Here #
 
 Congratulations! You've now learned more advanced Google Test tools and are
 ready to tackle more complex testing tasks. If you want to dive even deeper, you
-can read the [Frequently-Asked Questions](V1_6_FAQ.md).
+can read the [Frequently-Asked Questions](V1_6_FAQ.md).

3rdparty/googletest/googletest/docs/V1_6_FAQ.md

@@ -28,11 +28,11 @@ list can help you decide whether it is for you too.
   * `SCOPED_TRACE` helps you understand the context of an assertion failure when it comes from inside a sub-routine or loop.
   * You can decide which tests to run using name patterns.  This saves time when you want to quickly reproduce a test failure.
   * Google Test can generate XML test result reports that can be parsed by popular continuous build system like Hudson.
-  * Simple things are easy in Google Test, while hard things are possible: in addition to advanced features like [global test environments](http://code.google.com/p/googletest/wiki/V1_6_AdvancedGuide#Global_Set-Up_and_Tear-Down) and tests parameterized by [values](http://code.google.com/p/googletest/wiki/V1_6_AdvancedGuide#Value_Parameterized_Tests) or [types](http://code.google.com/p/googletest/wiki/V1_6_AdvancedGuide#Typed_Tests), Google Test supports various ways for the user to extend the framework -- if Google Test doesn't do something out of the box, chances are that a user can implement the feature using Google Test's public API, without changing Google Test itself.  In particular, you can:
+  * Simple things are easy in Google Test, while hard things are possible: in addition to advanced features like [global test environments](V1_6_AdvancedGuide.md#Global_Set-Up_and_Tear-Down) and tests parameterized by [values](V1_6_AdvancedGuide.md#value-parameterized-tests) or [types](V1_6_AdvancedGuide.md#typed-tests), Google Test supports various ways for the user to extend the framework -- if Google Test doesn't do something out of the box, chances are that a user can implement the feature using Google Test's public API, without changing Google Test itself.  In particular, you can:
-    * expand your testing vocabulary by defining [custom predicates](http://code.google.com/p/googletest/wiki/V1_6_AdvancedGuide#Predicate_Assertions_for_Better_Error_Messages),
+    * expand your testing vocabulary by defining [custom predicates](V1_6_AdvancedGuide.md#predicate-assertions-for-better-error-messages),
-    * teach Google Test how to [print your types](http://code.google.com/p/googletest/wiki/V1_6_AdvancedGuide#Teaching_Google_Test_How_to_Print_Your_Values),
+    * teach Google Test how to [print your types](V1_6_AdvancedGuide.md#teaching-google-test-how-to-print-your-values),
-    * define your own testing macros or utilities and verify them using Google Test's [Service Provider Interface](http://code.google.com/p/googletest/wiki/V1_6_AdvancedGuide#Catching_Failures), and
+    * define your own testing macros or utilities and verify them using Google Test's [Service Provider Interface](V1_6_AdvancedGuide.md#catching-failures), and
-    * reflect on the test cases or change the test output format by intercepting the [test events](http://code.google.com/p/googletest/wiki/V1_6_AdvancedGuide#Extending_Google_Test_by_Handling_Test_Events).
+    * reflect on the test cases or change the test output format by intercepting the [test events](V1_6_AdvancedGuide.md#extending-google-test-by-handling-test-events).
 
 ## I'm getting warnings when compiling Google Test.  Would you fix them? ##
 
@@ -201,7 +201,7 @@ we don't have a convention on the order of the two arguments for
 twice in the implementation, making it even harder to understand and
 maintain. We believe the benefit doesn't justify the cost.
 
-Finally, with the growth of Google Mock's [matcher](http://code.google.com/p/googlemock/wiki/CookBook#Using_Matchers_in_Google_Test_Assertions) library, we are
+Finally, with the growth of Google Mock's [matcher](../../CookBook.md#using-matchers-in-google-test-assertions) library, we are
 encouraging people to use the unified `EXPECT_THAT(value, matcher)`
 syntax more often in tests. One significant advantage of the matcher
 approach is that matchers can be easily combined to form new matchers,
@@ -409,7 +409,7 @@ If necessary, you can continue to derive test fixtures from a derived fixture.
 Google Test has no limit on how deep the hierarchy can be.
 
 For a complete example using derived test fixtures, see
-[sample5](http://code.google.com/p/googletest/source/browse/trunk/samples/sample5_unittest.cc).
+[sample5](../samples/sample5_unittest.cc).
 
 ## My compiler complains "void value not ignored as it ought to be." What does this mean? ##
 
@@ -748,7 +748,7 @@ EXPECT_TRUE(internal::Func(12345));
 
 ## I would like to run a test several times with different parameters. Do I need to write several similar copies of it? ##
 
-No. You can use a feature called [value-parameterized tests](V1_6_AdvancedGuide#Value_Parameterized_Tests.md) which
+No. You can use a feature called [value-parameterized tests](V1_6_AdvancedGuide.md#Value_Parameterized_Tests) which
 lets you repeat your tests with different parameters, without defining it more than once.
 
 ## How do I test a file that defines main()? ##
@@ -798,6 +798,7 @@ reference global and/or local variables, and can be:
   * a compound statement.
 
 > Some examples are shown here:
+
 ```
 // A death test can be a simple function call.
 TEST(MyDeathTest, FunctionCall) {
@@ -842,7 +843,7 @@ expression syntax
 (http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions).
 On Windows, it uses a limited variant of regular expression
 syntax. For more details, see the
-[regular expression syntax](V1_6_AdvancedGuide#Regular_Expression_Syntax.md).
+[regular expression syntax](V1_6_AdvancedGuide.md#Regular_Expression_Syntax).
 
 ## I have a fixture class Foo, but TEST\_F(Foo, Bar) gives me error "no matching function for call to Foo::Foo()". Why? ##
 
@@ -949,7 +950,7 @@ using gtest-md.vcproj instead of gtest.vcproj.
 
 ## I put my tests in a library and Google Test doesn't run them. What's happening? ##
 Have you read a
-[warning](http://code.google.com/p/googletest/wiki/V1_6_Primer#Important_note_for_Visual_C++_users) on
+[warning](V1_6_Primer.md#important-note-for-visual-c-users) on
 the Google Test Primer page?
 
 ## I want to use Google Test with Visual Studio but don't know where to start. ##
@@ -988,7 +989,7 @@ you can use the _horrible_ hack of sniffing your executable name
 ## Google Test defines a macro that clashes with one defined by another library. How do I deal with that? ##
 
 In C++, macros don't obey namespaces.  Therefore two libraries that
-both define a macro of the same name will clash if you #include both
+both define a macro of the same name will clash if you `#include` both
 definitions.  In case a Google Test macro clashes with another
 library, you can force Google Test to rename its macro to avoid the
 conflict.
@@ -1034,4 +1035,4 @@ not enough information in your question):
   * the name and version of your compiler,
   * the complete command line flags you give to your compiler,
   * the complete compiler error messages (if the question is about compilation),
-  * the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.
+  * the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.

3rdparty/googletest/googletest/docs/V1_6_Primer.md

@@ -146,7 +146,7 @@ but it's no longer necessary since v1.6.0 (if `<<` is supported, it
 will be called to print the arguments when the assertion fails;
 otherwise Google Test will attempt to print them in the best way it
 can. For more details and how to customize the printing of the
-arguments, see this Google Mock [recipe](http://code.google.com/p/googlemock/wiki/CookBook#Teaching_Google_Mock_How_to_Print_Your_Values).).
+arguments, see this Google Mock [recipe](../../googlemock/docs/CookBook.md#teaching-google-mock-how-to-print-your-values).).
 
 These assertions can work with a user-defined type, but only if you define the
 corresponding comparison operator (e.g. `==`, `<`, etc).  If the corresponding
@@ -255,7 +255,7 @@ To create a fixture, just:
   1. Derive a class from `::testing::Test` . Start its body with `protected:` or `public:` as we'll want to access fixture members from sub-classes.
   1. Inside the class, declare any objects you plan to use.
   1. If necessary, write a default constructor or `SetUp()` function to prepare the objects for each test. A common mistake is to spell `SetUp()` as `Setup()` with a small `u` - don't let that happen to you.
-  1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](http://code.google.com/p/googletest/wiki/V1_6_FAQ#Should_I_use_the_constructor/destructor_of_the_test_fixture_or_t).
+  1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](V1_6_FAQ.md#should-i-use-the-constructordestructor-of-the-test-fixture-or-the-set-uptear-down-function).
   1. If needed, define subroutines for your tests to share.
 
 When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to
@@ -498,4 +498,4 @@ is currently _unsafe_ to use Google Test assertions from two threads
 concurrently on other systems (e.g. Windows).  In most tests this is
 not an issue as usually the assertions are done in the main thread. If
 you want to help, you can volunteer to implement the necessary
-synchronization primitives in `gtest-port.h` for your platform.
+synchronization primitives in `gtest-port.h` for your platform.

3rdparty/googletest/googletest/docs/V1_6_PumpManual.md

@@ -161,7 +161,7 @@ exp ::= simple_expression_in_Python_syntax
 
 ## Code ##
 
-You can find the source code of Pump in [scripts/pump.py](http://code.google.com/p/googletest/source/browse/trunk/scripts/pump.py). It is still
+You can find the source code of Pump in [scripts/pump.py](../scripts/pump.py). It is still
 very unpolished and lacks automated tests, although it has been
 successfully used many times. If you find a chance to use it in your
 project, please let us know what you think!  We also welcome help on
@@ -174,4 +174,4 @@ You can find real-world applications of Pump in [Google Test](http://www.google.
 ## Tips ##
 
   * If a meta variable is followed by a letter or digit, you can separate them using `[[]]`, which inserts an empty string. For example `Foo$j[[]]Helper` generate `Foo1Helper` when `j` is 1.
-  * To avoid extra-long Pump source lines, you can break a line anywhere you want by inserting `[[]]` followed by a new line. Since any new-line character next to `[[` or `]]` is ignored, the generated code won't contain this new line.
+  * To avoid extra-long Pump source lines, you can break a line anywhere you want by inserting `[[]]` followed by a new line. Since any new-line character next to `[[` or `]]` is ignored, the generated code won't contain this new line.

3rdparty/googletest/googletest/docs/V1_6_Samples.md

@@ -1,14 +1,14 @@
 If you're like us, you'd like to look at some Google Test sample code.  The
-[samples folder](http://code.google.com/p/googletest/source/browse/#svn/trunk/samples) has a number of well-commented samples showing how to use a
+[samples folder](../samples) has a number of well-commented samples showing how to use a
 variety of Google Test features.
 
-  * [Sample #1](http://code.google.com/p/googletest/source/browse/trunk/samples/sample1_unittest.cc) shows the basic steps of using Google Test to test C++ functions.
+  * [Sample #1](../samples/sample1_unittest.cc) shows the basic steps of using Google Test to test C++ functions.
-  * [Sample #2](http://code.google.com/p/googletest/source/browse/trunk/samples/sample2_unittest.cc) shows a more complex unit test for a class with multiple member functions.
+  * [Sample #2](../samples/sample2_unittest.cc) shows a more complex unit test for a class with multiple member functions.
-  * [Sample #3](http://code.google.com/p/googletest/source/browse/trunk/samples/sample3_unittest.cc) uses a test fixture.
+  * [Sample #3](../samples/sample3_unittest.cc) uses a test fixture.
-  * [Sample #4](http://code.google.com/p/googletest/source/browse/trunk/samples/sample4_unittest.cc) is another basic example of using Google Test.
+  * [Sample #4](../samples/sample4_unittest.cc) is another basic example of using Google Test.
-  * [Sample #5](http://code.google.com/p/googletest/source/browse/trunk/samples/sample5_unittest.cc) teaches how to reuse a test fixture in multiple test cases by deriving sub-fixtures from it.
+  * [Sample #5](../samples/sample5_unittest.cc) teaches how to reuse a test fixture in multiple test cases by deriving sub-fixtures from it.
-  * [Sample #6](http://code.google.com/p/googletest/source/browse/trunk/samples/sample6_unittest.cc) demonstrates type-parameterized tests.
+  * [Sample #6](../samples/sample6_unittest.cc) demonstrates type-parameterized tests.
-  * [Sample #7](http://code.google.com/p/googletest/source/browse/trunk/samples/sample7_unittest.cc) teaches the basics of value-parameterized tests.
+  * [Sample #7](../samples/sample7_unittest.cc) teaches the basics of value-parameterized tests.
-  * [Sample #8](http://code.google.com/p/googletest/source/browse/trunk/samples/sample8_unittest.cc) shows using `Combine()` in value-parameterized tests.
+  * [Sample #8](../samples/sample8_unittest.cc) shows using `Combine()` in value-parameterized tests.
-  * [Sample #9](http://code.google.com/p/googletest/source/browse/trunk/samples/sample9_unittest.cc) shows use of the listener API to modify Google Test's console output and the use of its reflection API to inspect test results.
+  * [Sample #9](../samples/sample9_unittest.cc) shows use of the listener API to modify Google Test's console output and the use of its reflection API to inspect test results.
-  * [Sample #10](http://code.google.com/p/googletest/source/browse/trunk/samples/sample10_unittest.cc) shows use of the listener API to implement a primitive memory leak checker.
+  * [Sample #10](../samples/sample10_unittest.cc) shows use of the listener API to implement a primitive memory leak checker.

3rdparty/googletest/googletest/docs/V1_7_AdvancedGuide.md

@@ -123,7 +123,7 @@ c is 10<br>
 
 **Notes:**
 
-  1. If you see a compiler error "no matching function to call" when using `ASSERT_PRED*` or `EXPECT_PRED*`, please see [this](http://code.google.com/p/googletest/wiki/V1_7_FAQ#The_compiler_complains_%22no_matching_function_to_call%22) for how to resolve it.
+  1. If you see a compiler error "no matching function to call" when using `ASSERT_PRED*` or `EXPECT_PRED*`, please see [this](V1_7_FAQ.md#the-compiler-complains-about-undefined-references-to-some-static-const-member-variables-but-i-did-define-them-in-the-class-body-whats-wrong) for how to resolve it.
   1. Currently we only provide predicate assertions of arity <= 5. If you need a higher-arity assertion, let us know.
 
 _Availability_: Linux, Windows, Mac
@@ -263,7 +263,7 @@ int SmallestPrimeCommonDivisor(int m, int n) { ... }
                                                int n) {
   if (MutuallyPrime(m, n))
     return ::testing::AssertionSuccess();
- 
+
   return ::testing::AssertionFailure()
       << m_expr << " and " << n_expr << " (" << m << " and " << n
       << ") are not mutually prime, " << "as they have a common divisor "
@@ -515,9 +515,9 @@ _death tests_. More generally, any test that checks that a program terminates
 Note that if a piece of code throws an exception, we don't consider it "death"
 for the purpose of death tests, as the caller of the code could catch the exception
 and avoid the crash. If you want to verify exceptions thrown by your code,
-see [Exception Assertions](#Exception_Assertions.md).
+see [Exception Assertions](#exception-assertions).
 
-If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see [Catching Failures](#Catching_Failures.md).
+If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see [Catching Failures](#catching-failures).
 
 ## How to Write a Death Test ##
 
@@ -802,7 +802,7 @@ For example,
 11:   EXPECT_EQ(1, Bar(n));
 12:   EXPECT_EQ(2, Bar(n + 1));
 13: }
-14: 
+14:
 15: TEST(FooTest, Bar) {
 16:   {
 17:     SCOPED_TRACE("A");  // This trace point will be included in
@@ -1197,9 +1197,9 @@ which are all in the `testing` namespace:
 | `Values(v1, v2, ..., vN)`   | Yields values `{v1, v2, ..., vN}`.                                                                                |
 | `ValuesIn(container)` and `ValuesIn(begin, end)` | Yields values from a C-style array, an STL-style container, or an iterator range `[begin, end)`. `container`, `begin`, and `end` can be expressions whose values are determined at run time.  |
 | `Bool()`                    | Yields sequence `{false, true}`.                                                                                  |
-| `Combine(g1, g2, ..., gN)`  | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/internal/gtest-port.h) for more information. |
+| `Combine(g1, g2, ..., gN)`  | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](../include/gtest/internal/gtest-port.h) for more information. |
 
-For more details, see the comments at the definitions of these functions in the [source code](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-param-test.h).
+For more details, see the comments at the definitions of these functions in the [source code](../include/gtest/gtest-param-test.h).
 
 The following statement will instantiate tests from the `FooTest` test case
 each with parameter values `"meeny"`, `"miny"`, and `"moe"`.
@@ -1224,7 +1224,7 @@ names:
   * `InstantiationName/FooTest.HasBlahBlah/1` for `"miny"`
   * `InstantiationName/FooTest.HasBlahBlah/2` for `"moe"`
 
-You can use these names in [--gtest\_filter](#Running_a_Subset_of_the_Tests.md).
+You can use these names in [--gtest\_filter](#running-a-subset-of-the-tests).
 
 This statement will instantiate all tests from `FooTest` again, each
 with parameter values `"cat"` and `"dog"`:
@@ -1247,8 +1247,8 @@ tests in the given test case, whether their definitions come before or
 _after_ the `INSTANTIATE_TEST_CASE_P` statement.
 
 You can see
-[these](http://code.google.com/p/googletest/source/browse/trunk/samples/sample7_unittest.cc)
+[these](../samples/sample7_unittest.cc)
-[files](http://code.google.com/p/googletest/source/browse/trunk/samples/sample8_unittest.cc) for more examples.
+[files](../samples/sample8_unittest.cc) for more examples.
 
 _Availability_: Linux, Windows (requires MSVC 8.0 or above), Mac; since version 1.2.0.
 
@@ -1448,7 +1448,7 @@ two cases to consider:
 
 Both static functions and definitions/declarations in an unnamed namespace are
 only visible within the same translation unit. To test them, you can `#include`
-the entire `.cc` file being tested in your `*_test.cc` file. (#including `.cc`
+the entire `.cc` file being tested in your `*_test.cc` file. (`#include`ing `.cc`
 files is not a good way to reuse code - you should not do this in production
 code!)
 
@@ -1550,7 +1550,7 @@ Test doesn't use exceptions, so how do we test that a piece of code
 generates an expected failure?
 
 `"gtest/gtest-spi.h"` contains some constructs to do this.  After
-#including this header, you can use
+`#include`ing this header, you can use
 
 | `EXPECT_FATAL_FAILURE(`_statement, substring_`);` |
 |:--------------------------------------------------|
@@ -1644,8 +1644,8 @@ _Availability:_ Linux, Windows, Mac; since v1.4.0.
 ## Defining Event Listeners ##
 
 To define a event listener, you subclass either
-[testing::TestEventListener](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#855)
+[testing::TestEventListener](../include/gtest/gtest.h#L855)
-or [testing::EmptyTestEventListener](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#905).
+or [testing::EmptyTestEventListener](../include/gtest/gtest.h#L905).
 The former is an (abstract) interface, where <i>each pure virtual method<br>
 can be overridden to handle a test event</i> (For example, when a test
 starts, the `OnTestStart()` method will be called.). The latter provides
@@ -1654,10 +1654,10 @@ subclass only needs to override the methods it cares about.
 
 When an event is fired, its context is passed to the handler function
 as an argument. The following argument types are used:
-  * [UnitTest](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#1007) reflects the state of the entire test program,
+  * [UnitTest](../include/gtest/gtest.h#L1007) reflects the state of the entire test program,
-  * [TestCase](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#689) has information about a test case, which can contain one or more tests,
+  * [TestCase](../include/gtest/gtest.h#L689) has information about a test case, which can contain one or more tests,
-  * [TestInfo](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#599) contains the state of a test, and
+  * [TestInfo](../include/gtest/gtest.h#L599) contains the state of a test, and
-  * [TestPartResult](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-test-part.h#42) represents the result of a test assertion.
+  * [TestPartResult](../include/gtest/gtest-test-part.h#L42) represents the result of a test assertion.
 
 An event handler function can examine the argument it receives to find
 out interesting information about the event and the test program's
@@ -1693,7 +1693,7 @@ state.  Here's an example:
 
 To use the event listener you have defined, add an instance of it to
 the Google Test event listener list (represented by class
-[TestEventListeners](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#929)
+[TestEventListeners](../include/gtest/gtest.h#L929)
 - note the "s" at the end of the name) in your
 `main()` function, before calling `RUN_ALL_TESTS()`:
 ```
@@ -1721,7 +1721,7 @@ event listener list and delete it. You can do so by adding one line:
 
 Now, sit back and enjoy a completely different output from your
 tests. For more details, you can read this
-[sample](http://code.google.com/p/googletest/source/browse/trunk/samples/sample9_unittest.cc).
+[sample](../samples/sample9_unittest.cc).
 
 You may append more than one listener to the list. When an `On*Start()`
 or `OnTestPartResult()` event is fired, the listeners will receive it in
@@ -1746,7 +1746,7 @@ failures. This ensures that failures generated by the latter are
 attributed to the right test by the former.
 
 We have a sample of failure-raising listener
-[here](http://code.google.com/p/googletest/source/browse/trunk/samples/sample10_unittest.cc).
+[here](../samples/sample10_unittest.cc).
 
 # Running Test Programs: Advanced Options #
 
@@ -1866,12 +1866,12 @@ _Availability:_ Linux, Windows, Mac.
 
 ### Temporarily Enabling Disabled Tests ###
 
-To include [disabled tests](#Temporarily_Disabling_Tests.md) in test
+To include [disabled tests](#temporarily-disabling-tests) in test
 execution, just invoke the test program with the
 `--gtest_also_run_disabled_tests` flag or set the
 `GTEST_ALSO_RUN_DISABLED_TESTS` environment variable to a value other
 than `0`.  You can combine this with the
-[--gtest\_filter](#Running_a_Subset_of_the_Tests.md) flag to further select
+[--gtest\_filter](#running-a-subset-of-the-tests) flag to further select
 which disabled tests to run.
 
 _Availability:_ Linux, Windows, Mac; since version 1.3.0.
@@ -2171,11 +2171,11 @@ and you should see an `OUTPUT_DIR` directory being created with files
 `gtest/gtest.h` and `gtest/gtest-all.cc` in it.  These files contain
 everything you need to use Google Test.  Just copy them to anywhere
 you want and you are ready to write tests.  You can use the
-[scripts/test/Makefile](http://code.google.com/p/googletest/source/browse/trunk/scripts/test/Makefile)
+[scripts/test/Makefile](../scripts/test/Makefile)
 file as an example on how to compile your tests against them.
 
 # Where to Go from Here #
 
 Congratulations! You've now learned more advanced Google Test tools and are
 ready to tackle more complex testing tasks. If you want to dive even deeper, you
-can read the [Frequently-Asked Questions](V1_7_FAQ.md).
+can read the [Frequently-Asked Questions](V1_7_FAQ.md).

3rdparty/googletest/googletest/docs/V1_7_FAQ.md

@@ -28,11 +28,11 @@ list can help you decide whether it is for you too.
   * `SCOPED_TRACE` helps you understand the context of an assertion failure when it comes from inside a sub-routine or loop.
   * You can decide which tests to run using name patterns.  This saves time when you want to quickly reproduce a test failure.
   * Google Test can generate XML test result reports that can be parsed by popular continuous build system like Hudson.
-  * Simple things are easy in Google Test, while hard things are possible: in addition to advanced features like [global test environments](http://code.google.com/p/googletest/wiki/V1_7_AdvancedGuide#Global_Set-Up_and_Tear-Down) and tests parameterized by [values](http://code.google.com/p/googletest/wiki/V1_7_AdvancedGuide#Value_Parameterized_Tests) or [types](http://code.google.com/p/googletest/wiki/V1_7_AdvancedGuide#Typed_Tests), Google Test supports various ways for the user to extend the framework -- if Google Test doesn't do something out of the box, chances are that a user can implement the feature using Google Test's public API, without changing Google Test itself.  In particular, you can:
+  * Simple things are easy in Google Test, while hard things are possible: in addition to advanced features like [global test environments](V1_7_AdvancedGuide.md#global-set-up-and-tear-down) and tests parameterized by [values](V1_7_AdvancedGuide.md#value-parameterized-tests) or [types](V1_7_AdvancedGuide.md#typed-tests), Google Test supports various ways for the user to extend the framework -- if Google Test doesn't do something out of the box, chances are that a user can implement the feature using Google Test's public API, without changing Google Test itself.  In particular, you can:
-    * expand your testing vocabulary by defining [custom predicates](http://code.google.com/p/googletest/wiki/V1_7_AdvancedGuide#Predicate_Assertions_for_Better_Error_Messages),
+    * expand your testing vocabulary by defining [custom predicates](V1_7_AdvancedGuide.md#predicate-assertions-for-better-error-messages),
-    * teach Google Test how to [print your types](http://code.google.com/p/googletest/wiki/V1_7_AdvancedGuide#Teaching_Google_Test_How_to_Print_Your_Values),
+    * teach Google Test how to [print your types](V1_7_AdvancedGuide.md#teaching-google-test-how-to-print-your-values),
-    * define your own testing macros or utilities and verify them using Google Test's [Service Provider Interface](http://code.google.com/p/googletest/wiki/V1_7_AdvancedGuide#Catching_Failures), and
+    * define your own testing macros or utilities and verify them using Google Test's [Service Provider Interface](V1_7_AdvancedGuide.md#catching-failures), and
-    * reflect on the test cases or change the test output format by intercepting the [test events](http://code.google.com/p/googletest/wiki/V1_7_AdvancedGuide#Extending_Google_Test_by_Handling_Test_Events).
+    * reflect on the test cases or change the test output format by intercepting the [test events](V1_7_AdvancedGuide.md#extending-google-test-by-handling-test-events).
 
 ## I'm getting warnings when compiling Google Test.  Would you fix them? ##
 
@@ -201,7 +201,7 @@ we don't have a convention on the order of the two arguments for
 twice in the implementation, making it even harder to understand and
 maintain. We believe the benefit doesn't justify the cost.
 
-Finally, with the growth of Google Mock's [matcher](http://code.google.com/p/googlemock/wiki/CookBook#Using_Matchers_in_Google_Test_Assertions) library, we are
+Finally, with the growth of Google Mock's [matcher](../../CookBook.md#using-matchers-in-google-test-assertions) library, we are
 encouraging people to use the unified `EXPECT_THAT(value, matcher)`
 syntax more often in tests. One significant advantage of the matcher
 approach is that matchers can be easily combined to form new matchers,
@@ -409,7 +409,7 @@ If necessary, you can continue to derive test fixtures from a derived fixture.
 Google Test has no limit on how deep the hierarchy can be.
 
 For a complete example using derived test fixtures, see
-[sample5](http://code.google.com/p/googletest/source/browse/trunk/samples/sample5_unittest.cc).
+[sample5](../samples/sample5_unittest.cc).
 
 ## My compiler complains "void value not ignored as it ought to be." What does this mean? ##
 
@@ -748,7 +748,7 @@ EXPECT_TRUE(internal::Func(12345));
 
 ## I would like to run a test several times with different parameters. Do I need to write several similar copies of it? ##
 
-No. You can use a feature called [value-parameterized tests](V1_7_AdvancedGuide#Value_Parameterized_Tests.md) which
+No. You can use a feature called [value-parameterized tests](V1_7_AdvancedGuide.md#Value_Parameterized_Tests) which
 lets you repeat your tests with different parameters, without defining it more than once.
 
 ## How do I test a file that defines main()? ##
@@ -798,6 +798,7 @@ reference global and/or local variables, and can be:
   * a compound statement.
 
 > Some examples are shown here:
+
 ```
 // A death test can be a simple function call.
 TEST(MyDeathTest, FunctionCall) {
@@ -842,7 +843,7 @@ expression syntax
 (http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions).
 On Windows, it uses a limited variant of regular expression
 syntax. For more details, see the
-[regular expression syntax](V1_7_AdvancedGuide#Regular_Expression_Syntax.md).
+[regular expression syntax](V1_7_AdvancedGuide.md#Regular_Expression_Syntax).
 
 ## I have a fixture class Foo, but TEST\_F(Foo, Bar) gives me error "no matching function for call to Foo::Foo()". Why? ##
 
@@ -949,7 +950,7 @@ using gtest-md.vcproj instead of gtest.vcproj.
 
 ## I put my tests in a library and Google Test doesn't run them. What's happening? ##
 Have you read a
-[warning](http://code.google.com/p/googletest/wiki/V1_7_Primer#Important_note_for_Visual_C++_users) on
+[warning](V1_7_Primer.md#important-note-for-visual-c-users) on
 the Google Test Primer page?
 
 ## I want to use Google Test with Visual Studio but don't know where to start. ##
@@ -988,7 +989,7 @@ you can use the _horrible_ hack of sniffing your executable name
 ## Google Test defines a macro that clashes with one defined by another library. How do I deal with that? ##
 
 In C++, macros don't obey namespaces.  Therefore two libraries that
-both define a macro of the same name will clash if you #include both
+both define a macro of the same name will clash if you `#include` both
 definitions.  In case a Google Test macro clashes with another
 library, you can force Google Test to rename its macro to avoid the
 conflict.
@@ -1053,7 +1054,7 @@ TEST_F(CoolTest, DoSomething) {
 ## How do I build Google Testing Framework with Xcode 4? ##
 
 If you try to build Google Test's Xcode project with Xcode 4.0 or later, you may encounter an error message that looks like
-"Missing SDK in target gtest\_framework: /Developer/SDKs/MacOSX10.4u.sdk". That means that Xcode does not support the SDK the project is targeting. See the Xcode section in the [README](http://code.google.com/p/googletest/source/browse/trunk/README) file on how to resolve this.
+"Missing SDK in target gtest\_framework: /Developer/SDKs/MacOSX10.4u.sdk". That means that Xcode does not support the SDK the project is targeting. See the Xcode section in the [README](../../README.MD) file on how to resolve this.
 
 ## My question is not covered in your FAQ! ##
 
@@ -1078,4 +1079,4 @@ not enough information in your question):
   * the name and version of your compiler,
   * the complete command line flags you give to your compiler,
   * the complete compiler error messages (if the question is about compilation),
-  * the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.
+  * the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.

3rdparty/googletest/googletest/docs/V1_7_Primer.md

@@ -146,7 +146,7 @@ but it's no longer necessary since v1.6.0 (if `<<` is supported, it
 will be called to print the arguments when the assertion fails;
 otherwise Google Test will attempt to print them in the best way it
 can. For more details and how to customize the printing of the
-arguments, see this Google Mock [recipe](http://code.google.com/p/googlemock/wiki/CookBook#Teaching_Google_Mock_How_to_Print_Your_Values).).
+arguments, see this Google Mock [recipe](../../googlemock/docs/CookBook.md#teaching-google-mock-how-to-print-your-values).).
 
 These assertions can work with a user-defined type, but only if you define the
 corresponding comparison operator (e.g. `==`, `<`, etc).  If the corresponding
@@ -255,7 +255,7 @@ To create a fixture, just:
   1. Derive a class from `::testing::Test` . Start its body with `protected:` or `public:` as we'll want to access fixture members from sub-classes.
   1. Inside the class, declare any objects you plan to use.
   1. If necessary, write a default constructor or `SetUp()` function to prepare the objects for each test. A common mistake is to spell `SetUp()` as `Setup()` with a small `u` - don't let that happen to you.
-  1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](http://code.google.com/p/googletest/wiki/V1_7_FAQ#Should_I_use_the_constructor/destructor_of_the_test_fixture_or_t).
+  1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](V1_7_FAQ.md#should-i-use-the-constructordestructor-of-the-test-fixture-or-the-set-uptear-down-function).
   1. If needed, define subroutines for your tests to share.
 
 When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to
@@ -498,4 +498,4 @@ is currently _unsafe_ to use Google Test assertions from two threads
 concurrently on other systems (e.g. Windows).  In most tests this is
 not an issue as usually the assertions are done in the main thread. If
 you want to help, you can volunteer to implement the necessary
-synchronization primitives in `gtest-port.h` for your platform.
+synchronization primitives in `gtest-port.h` for your platform.

3rdparty/googletest/googletest/docs/V1_7_PumpManual.md

@@ -161,7 +161,7 @@ exp ::= simple_expression_in_Python_syntax
 
 ## Code ##
 
-You can find the source code of Pump in [scripts/pump.py](http://code.google.com/p/googletest/source/browse/trunk/scripts/pump.py). It is still
+You can find the source code of Pump in [scripts/pump.py](../scripts/pump.py). It is still
 very unpolished and lacks automated tests, although it has been
 successfully used many times. If you find a chance to use it in your
 project, please let us know what you think!  We also welcome help on
@@ -174,4 +174,4 @@ You can find real-world applications of Pump in [Google Test](http://www.google.
 ## Tips ##
 
   * If a meta variable is followed by a letter or digit, you can separate them using `[[]]`, which inserts an empty string. For example `Foo$j[[]]Helper` generate `Foo1Helper` when `j` is 1.
-  * To avoid extra-long Pump source lines, you can break a line anywhere you want by inserting `[[]]` followed by a new line. Since any new-line character next to `[[` or `]]` is ignored, the generated code won't contain this new line.
+  * To avoid extra-long Pump source lines, you can break a line anywhere you want by inserting `[[]]` followed by a new line. Since any new-line character next to `[[` or `]]` is ignored, the generated code won't contain this new line.

3rdparty/googletest/googletest/docs/V1_7_Samples.md

@@ -1,14 +1,14 @@
 If you're like us, you'd like to look at some Google Test sample code.  The
-[samples folder](http://code.google.com/p/googletest/source/browse/#svn/trunk/samples) has a number of well-commented samples showing how to use a
+[samples folder](../samples) has a number of well-commented samples showing how to use a
 variety of Google Test features.
 
-  * [Sample #1](http://code.google.com/p/googletest/source/browse/trunk/samples/sample1_unittest.cc) shows the basic steps of using Google Test to test C++ functions.
+  * [Sample #1](../samples/sample1_unittest.cc) shows the basic steps of using Google Test to test C++ functions.
-  * [Sample #2](http://code.google.com/p/googletest/source/browse/trunk/samples/sample2_unittest.cc) shows a more complex unit test for a class with multiple member functions.
+  * [Sample #2](../samples/sample2_unittest.cc) shows a more complex unit test for a class with multiple member functions.
-  * [Sample #3](http://code.google.com/p/googletest/source/browse/trunk/samples/sample3_unittest.cc) uses a test fixture.
+  * [Sample #3](../samples/sample3_unittest.cc) uses a test fixture.
-  * [Sample #4](http://code.google.com/p/googletest/source/browse/trunk/samples/sample4_unittest.cc) is another basic example of using Google Test.
+  * [Sample #4](../samples/sample4_unittest.cc) is another basic example of using Google Test.
-  * [Sample #5](http://code.google.com/p/googletest/source/browse/trunk/samples/sample5_unittest.cc) teaches how to reuse a test fixture in multiple test cases by deriving sub-fixtures from it.
+  * [Sample #5](../samples/sample5_unittest.cc) teaches how to reuse a test fixture in multiple test cases by deriving sub-fixtures from it.
-  * [Sample #6](http://code.google.com/p/googletest/source/browse/trunk/samples/sample6_unittest.cc) demonstrates type-parameterized tests.
+  * [Sample #6](../samples/sample6_unittest.cc) demonstrates type-parameterized tests.
-  * [Sample #7](http://code.google.com/p/googletest/source/browse/trunk/samples/sample7_unittest.cc) teaches the basics of value-parameterized tests.
+  * [Sample #7](../samples/sample7_unittest.cc) teaches the basics of value-parameterized tests.
-  * [Sample #8](http://code.google.com/p/googletest/source/browse/trunk/samples/sample8_unittest.cc) shows using `Combine()` in value-parameterized tests.
+  * [Sample #8](../samples/sample8_unittest.cc) shows using `Combine()` in value-parameterized tests.
-  * [Sample #9](http://code.google.com/p/googletest/source/browse/trunk/samples/sample9_unittest.cc) shows use of the listener API to modify Google Test's console output and the use of its reflection API to inspect test results.
+  * [Sample #9](../samples/sample9_unittest.cc) shows use of the listener API to modify Google Test's console output and the use of its reflection API to inspect test results.
-  * [Sample #10](http://code.google.com/p/googletest/source/browse/trunk/samples/sample10_unittest.cc) shows use of the listener API to implement a primitive memory leak checker.
+  * [Sample #10](../samples/sample10_unittest.cc) shows use of the listener API to implement a primitive memory leak checker.

3rdparty/googletest/googletest/include/gtest/gtest.h

@@ -1372,39 +1372,38 @@ namespace internal {
 // frame size of CmpHelperEQ. This helps reduce the overhead of some sanitizers
 // when calling EXPECT_* in a tight loop.
 template <typename T1, typename T2>
-AssertionResult CmpHelperEQFailure(const char* expected_expression,
+AssertionResult CmpHelperEQFailure(const char* lhs_expression,
-                                   const char* actual_expression,
+                                   const char* rhs_expression,
-                                   const T1& expected, const T2& actual) {
+                                   const T1& lhs, const T2& rhs) {
-  return EqFailure(expected_expression,
+  return EqFailure(lhs_expression,
-                   actual_expression,
+                   rhs_expression,
-                   FormatForComparisonFailureMessage(expected, actual),
+                   FormatForComparisonFailureMessage(lhs, rhs),
-                   FormatForComparisonFailureMessage(actual, expected),
+                   FormatForComparisonFailureMessage(rhs, lhs),
                    false);
 }
 
 // The helper function for {ASSERT|EXPECT}_EQ.
 template <typename T1, typename T2>
-AssertionResult CmpHelperEQ(const char* expected_expression,
+AssertionResult CmpHelperEQ(const char* lhs_expression,
-                            const char* actual_expression,
+                            const char* rhs_expression,
-                            const T1& expected,
+                            const T1& lhs,
-                            const T2& actual) {
+                            const T2& rhs) {
 GTEST_DISABLE_MSC_WARNINGS_PUSH_(4389 /* signed/unsigned mismatch */)
-  if (expected == actual) {
+  if (lhs == rhs) {
     return AssertionSuccess();
   }
 GTEST_DISABLE_MSC_WARNINGS_POP_()
 
-  return CmpHelperEQFailure(expected_expression, actual_expression, expected,
+  return CmpHelperEQFailure(lhs_expression, rhs_expression, lhs, rhs);
-                            actual);
 }
 
 // With this overloaded version, we allow anonymous enums to be used
 // in {ASSERT|EXPECT}_EQ when compiled with gcc 4, as anonymous enums
 // can be implicitly cast to BiggestInt.
-GTEST_API_ AssertionResult CmpHelperEQ(const char* expected_expression,
+GTEST_API_ AssertionResult CmpHelperEQ(const char* lhs_expression,
-                                       const char* actual_expression,
+                                       const char* rhs_expression,
-                                       BiggestInt expected,
+                                       BiggestInt lhs,
-                                       BiggestInt actual);
+                                       BiggestInt rhs);
 
 // The helper class for {ASSERT|EXPECT}_EQ.  The template argument
 // lhs_is_null_literal is true iff the first argument to ASSERT_EQ()
@@ -1415,12 +1414,11 @@ class EqHelper {
  public:
   // This templatized version is for the general case.
   template <typename T1, typename T2>
-  static AssertionResult Compare(const char* expected_expression,
+  static AssertionResult Compare(const char* lhs_expression,
-                                 const char* actual_expression,
+                                 const char* rhs_expression,
-                                 const T1& expected,
+                                 const T1& lhs,
-                                 const T2& actual) {
+                                 const T2& rhs) {
-    return CmpHelperEQ(expected_expression, actual_expression, expected,
+    return CmpHelperEQ(lhs_expression, rhs_expression, lhs, rhs);
-                       actual);
   }
 
   // With this overloaded version, we allow anonymous enums to be used
@@ -1429,12 +1427,11 @@ class EqHelper {
   //
   // Even though its body looks the same as the above version, we
   // cannot merge the two, as it will make anonymous enums unhappy.
-  static AssertionResult Compare(const char* expected_expression,
+  static AssertionResult Compare(const char* lhs_expression,
-                                 const char* actual_expression,
+                                 const char* rhs_expression,
-                                 BiggestInt expected,
+                                 BiggestInt lhs,
-                                 BiggestInt actual) {
+                                 BiggestInt rhs) {
-    return CmpHelperEQ(expected_expression, actual_expression, expected,
+    return CmpHelperEQ(lhs_expression, rhs_expression, lhs, rhs);
-                       actual);
   }
 };
 
@@ -1449,37 +1446,36 @@ class EqHelper<true> {
   // EXPECT_EQ(false, a_bool).
   template <typename T1, typename T2>
   static AssertionResult Compare(
-      const char* expected_expression,
+      const char* lhs_expression,
-      const char* actual_expression,
+      const char* rhs_expression,
-      const T1& expected,
+      const T1& lhs,
-      const T2& actual,
+      const T2& rhs,
       // The following line prevents this overload from being considered if T2
       // is not a pointer type.  We need this because ASSERT_EQ(NULL, my_ptr)
       // expands to Compare("", "", NULL, my_ptr), which requires a conversion
       // to match the Secret* in the other overload, which would otherwise make
       // this template match better.
       typename EnableIf<!is_pointer<T2>::value>::type* = 0) {
-    return CmpHelperEQ(expected_expression, actual_expression, expected,
+    return CmpHelperEQ(lhs_expression, rhs_expression, lhs, rhs);
-                       actual);
   }
 
   // This version will be picked when the second argument to ASSERT_EQ() is a
   // pointer, e.g. ASSERT_EQ(NULL, a_pointer).
   template <typename T>
   static AssertionResult Compare(
-      const char* expected_expression,
+      const char* lhs_expression,
-      const char* actual_expression,
+      const char* rhs_expression,
       // We used to have a second template parameter instead of Secret*.  That
       // template parameter would deduce to 'long', making this a better match
       // than the first overload even without the first overload's EnableIf.
       // Unfortunately, gcc with -Wconversion-null warns when "passing NULL to
       // non-pointer argument" (even a deduced integral argument), so the old
       // implementation caused warnings in user code.
-      Secret* /* expected (NULL) */,
+      Secret* /* lhs (NULL) */,
-      T* actual) {
+      T* rhs) {
-    // We already know that 'expected' is a null pointer.
+    // We already know that 'lhs' is a null pointer.
-    return CmpHelperEQ(expected_expression, actual_expression,
+    return CmpHelperEQ(lhs_expression, rhs_expression,
-                       static_cast<T*>(NULL), actual);
+                       static_cast<T*>(NULL), rhs);
   }
 };
 
@@ -1538,18 +1534,18 @@ GTEST_IMPL_CMP_HELPER_(GT, >);
 // The helper function for {ASSERT|EXPECT}_STREQ.
 //
 // INTERNAL IMPLEMENTATION - DO NOT USE IN A USER PROGRAM.
-GTEST_API_ AssertionResult CmpHelperSTREQ(const char* expected_expression,
+GTEST_API_ AssertionResult CmpHelperSTREQ(const char* s1_expression,
-                                          const char* actual_expression,
+                                          const char* s2_expression,
-                                          const char* expected,
+                                          const char* s1,
-                                          const char* actual);
+                                          const char* s2);
 
 // The helper function for {ASSERT|EXPECT}_STRCASEEQ.
 //
 // INTERNAL IMPLEMENTATION - DO NOT USE IN A USER PROGRAM.
-GTEST_API_ AssertionResult CmpHelperSTRCASEEQ(const char* expected_expression,
+GTEST_API_ AssertionResult CmpHelperSTRCASEEQ(const char* s1_expression,
-                                              const char* actual_expression,
+                                              const char* s2_expression,
-                                              const char* expected,
+                                              const char* s1,
-                                              const char* actual);
+                                              const char* s2);
 
 // The helper function for {ASSERT|EXPECT}_STRNE.
 //
@@ -1571,10 +1567,10 @@ GTEST_API_ AssertionResult CmpHelperSTRCASENE(const char* s1_expression,
 // Helper function for *_STREQ on wide strings.
 //
 // INTERNAL IMPLEMENTATION - DO NOT USE IN A USER PROGRAM.
-GTEST_API_ AssertionResult CmpHelperSTREQ(const char* expected_expression,
+GTEST_API_ AssertionResult CmpHelperSTREQ(const char* s1_expression,
-                                          const char* actual_expression,
+                                          const char* s2_expression,
-                                          const wchar_t* expected,
+                                          const wchar_t* s1,
-                                          const wchar_t* actual);
+                                          const wchar_t* s2);
 
 // Helper function for *_STRNE on wide strings.
 //
@@ -1632,28 +1628,28 @@ namespace internal {
 //
 // INTERNAL IMPLEMENTATION - DO NOT USE IN A USER PROGRAM.
 template <typename RawType>
-AssertionResult CmpHelperFloatingPointEQ(const char* expected_expression,
+AssertionResult CmpHelperFloatingPointEQ(const char* lhs_expression,
-                                         const char* actual_expression,
+                                         const char* rhs_expression,
-                                         RawType expected,
+                                         RawType lhs_value,
-                                         RawType actual) {
+                                         RawType rhs_value) {
-  const FloatingPoint<RawType> lhs(expected), rhs(actual);
+  const FloatingPoint<RawType> lhs(lhs_value), rhs(rhs_value);
 
   if (lhs.AlmostEquals(rhs)) {
     return AssertionSuccess();
   }
 
-  ::std::stringstream expected_ss;
+  ::std::stringstream lhs_ss;
-  expected_ss << std::setprecision(std::numeric_limits<RawType>::digits10 + 2)
+  lhs_ss << std::setprecision(std::numeric_limits<RawType>::digits10 + 2)
-              << expected;
+         << lhs_value;
 
-  ::std::stringstream actual_ss;
+  ::std::stringstream rhs_ss;
-  actual_ss << std::setprecision(std::numeric_limits<RawType>::digits10 + 2)
+  rhs_ss << std::setprecision(std::numeric_limits<RawType>::digits10 + 2)
-            << actual;
+         << rhs_value;
 
-  return EqFailure(expected_expression,
+  return EqFailure(lhs_expression,
-                   actual_expression,
+                   rhs_expression,
-                   StringStreamToString(&expected_ss),
+                   StringStreamToString(&lhs_ss),
-                   StringStreamToString(&actual_ss),
+                   StringStreamToString(&rhs_ss),
                    false);
 }
 
@@ -1879,12 +1875,12 @@ class TestWithParam : public Test, public WithParamInterface<T> {
 
 // Macros for testing equalities and inequalities.
 //
-//    * {ASSERT|EXPECT}_EQ(expected, actual): Tests that expected == actual
+//    * {ASSERT|EXPECT}_EQ(v1, v2): Tests that v1 == v2
-//    * {ASSERT|EXPECT}_NE(v1, v2):           Tests that v1 != v2
+//    * {ASSERT|EXPECT}_NE(v1, v2): Tests that v1 != v2
-//    * {ASSERT|EXPECT}_LT(v1, v2):           Tests that v1 < v2
+//    * {ASSERT|EXPECT}_LT(v1, v2): Tests that v1 < v2
-//    * {ASSERT|EXPECT}_LE(v1, v2):           Tests that v1 <= v2
+//    * {ASSERT|EXPECT}_LE(v1, v2): Tests that v1 <= v2
-//    * {ASSERT|EXPECT}_GT(v1, v2):           Tests that v1 > v2
+//    * {ASSERT|EXPECT}_GT(v1, v2): Tests that v1 > v2
-//    * {ASSERT|EXPECT}_GE(v1, v2):           Tests that v1 >= v2
+//    * {ASSERT|EXPECT}_GE(v1, v2): Tests that v1 >= v2
 //
 // When they are not, Google Test prints both the tested expressions and
 // their actual values.  The values must be compatible built-in types,
@@ -1906,8 +1902,8 @@ class TestWithParam : public Test, public WithParamInterface<T> {
 //   are related, not how their content is related.  To compare two C
 //   strings by content, use {ASSERT|EXPECT}_STR*().
 //
-//   3. {ASSERT|EXPECT}_EQ(expected, actual) is preferred to
+//   3. {ASSERT|EXPECT}_EQ(v1, v2) is preferred to
-//   {ASSERT|EXPECT}_TRUE(expected == actual), as the former tells you
+//   {ASSERT|EXPECT}_TRUE(v1 == v2), as the former tells you
 //   what the actual value is when it fails, and similarly for the
 //   other comparisons.
 //
@@ -1923,12 +1919,12 @@ class TestWithParam : public Test, public WithParamInterface<T> {
 //   ASSERT_LT(i, array_size);
 //   ASSERT_GT(records.size(), 0) << "There is no record left.";
 
-#define EXPECT_EQ(expected, actual) \
+#define EXPECT_EQ(val1, val2) \
   EXPECT_PRED_FORMAT2(::testing::internal:: \
-                      EqHelper<GTEST_IS_NULL_LITERAL_(expected)>::Compare, \
+                      EqHelper<GTEST_IS_NULL_LITERAL_(val1)>::Compare, \
-                      expected, actual)
+                      val1, val2)
-#define EXPECT_NE(expected, actual) \
+#define EXPECT_NE(val1, val2) \
-  EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperNE, expected, actual)
+  EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperNE, val1, val2)
 #define EXPECT_LE(val1, val2) \
   EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperLE, val1, val2)
 #define EXPECT_LT(val1, val2) \
@@ -1938,10 +1934,10 @@ class TestWithParam : public Test, public WithParamInterface<T> {
 #define EXPECT_GT(val1, val2) \
   EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperGT, val1, val2)
 
-#define GTEST_ASSERT_EQ(expected, actual) \
+#define GTEST_ASSERT_EQ(val1, val2) \
   ASSERT_PRED_FORMAT2(::testing::internal:: \
-                      EqHelper<GTEST_IS_NULL_LITERAL_(expected)>::Compare, \
+                      EqHelper<GTEST_IS_NULL_LITERAL_(val1)>::Compare, \
-                      expected, actual)
+                      val1, val2)
 #define GTEST_ASSERT_NE(val1, val2) \
   ASSERT_PRED_FORMAT2(::testing::internal::CmpHelperNE, val1, val2)
 #define GTEST_ASSERT_LE(val1, val2) \
@@ -1996,29 +1992,29 @@ class TestWithParam : public Test, public WithParamInterface<T> {
 //
 // These macros evaluate their arguments exactly once.
 
-#define EXPECT_STREQ(expected, actual) \
+#define EXPECT_STREQ(s1, s2) \
-  EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperSTREQ, expected, actual)
+  EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperSTREQ, s1, s2)
 #define EXPECT_STRNE(s1, s2) \
   EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperSTRNE, s1, s2)
-#define EXPECT_STRCASEEQ(expected, actual) \
+#define EXPECT_STRCASEEQ(s1, s2) \
-  EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperSTRCASEEQ, expected, actual)
+  EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperSTRCASEEQ, s1, s2)
 #define EXPECT_STRCASENE(s1, s2)\
   EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperSTRCASENE, s1, s2)
 
-#define ASSERT_STREQ(expected, actual) \
+#define ASSERT_STREQ(s1, s2) \
-  ASSERT_PRED_FORMAT2(::testing::internal::CmpHelperSTREQ, expected, actual)
+  ASSERT_PRED_FORMAT2(::testing::internal::CmpHelperSTREQ, s1, s2)
 #define ASSERT_STRNE(s1, s2) \
   ASSERT_PRED_FORMAT2(::testing::internal::CmpHelperSTRNE, s1, s2)
-#define ASSERT_STRCASEEQ(expected, actual) \
+#define ASSERT_STRCASEEQ(s1, s2) \
-  ASSERT_PRED_FORMAT2(::testing::internal::CmpHelperSTRCASEEQ, expected, actual)
+  ASSERT_PRED_FORMAT2(::testing::internal::CmpHelperSTRCASEEQ, s1, s2)
 #define ASSERT_STRCASENE(s1, s2)\
   ASSERT_PRED_FORMAT2(::testing::internal::CmpHelperSTRCASENE, s1, s2)
 
 // Macros for comparing floating-point numbers.
 //
-//    * {ASSERT|EXPECT}_FLOAT_EQ(expected, actual):
+//    * {ASSERT|EXPECT}_FLOAT_EQ(val1, val2):
 //         Tests that two float values are almost equal.
-//    * {ASSERT|EXPECT}_DOUBLE_EQ(expected, actual):
+//    * {ASSERT|EXPECT}_DOUBLE_EQ(val1, val2):
 //         Tests that two double values are almost equal.
 //    * {ASSERT|EXPECT}_NEAR(v1, v2, abs_error):
 //         Tests that v1 and v2 are within the given distance to each other.
@@ -2028,21 +2024,21 @@ class TestWithParam : public Test, public WithParamInterface<T> {
 // FloatingPoint template class in gtest-internal.h if you are
 // interested in the implementation details.
 
-#define EXPECT_FLOAT_EQ(expected, actual)\
+#define EXPECT_FLOAT_EQ(val1, val2)\
   EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperFloatingPointEQ<float>, \
-                      expected, actual)
+                      val1, val2)
 
-#define EXPECT_DOUBLE_EQ(expected, actual)\
+#define EXPECT_DOUBLE_EQ(val1, val2)\
   EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperFloatingPointEQ<double>, \
-                      expected, actual)
+                      val1, val2)
 
-#define ASSERT_FLOAT_EQ(expected, actual)\
+#define ASSERT_FLOAT_EQ(val1, val2)\
   ASSERT_PRED_FORMAT2(::testing::internal::CmpHelperFloatingPointEQ<float>, \
-                      expected, actual)
+                      val1, val2)
 
-#define ASSERT_DOUBLE_EQ(expected, actual)\
+#define ASSERT_DOUBLE_EQ(val1, val2)\
   ASSERT_PRED_FORMAT2(::testing::internal::CmpHelperFloatingPointEQ<double>, \
-                      expected, actual)
+                      val1, val2)
 
 #define EXPECT_NEAR(val1, val2, abs_error)\
   EXPECT_PRED_FORMAT3(::testing::internal::DoubleNearPredFormat, \

3rdparty/googletest/googletest/include/gtest/internal/gtest-port.h

@@ -287,7 +287,7 @@
 # define GTEST_FLAG_PREFIX_DASH_ "gtest-"
 # define GTEST_FLAG_PREFIX_UPPER_ "GTEST_"
 # define GTEST_NAME_ "Google Test"
-# define GTEST_PROJECT_URL_ "http://code.google.com/p/googletest/"
+# define GTEST_PROJECT_URL_ "https://github.com/google/googletest/"
 #endif  // !defined(GTEST_DEV_EMAIL_)
 
 #if !defined(GTEST_INIT_GOOGLE_TEST_NAME_)
@@ -358,8 +358,9 @@
 # define GTEST_HAS_STD_FUNCTION_ 1
 # define GTEST_HAS_STD_INITIALIZER_LIST_ 1
 # define GTEST_HAS_STD_MOVE_ 1
-# define GTEST_HAS_STD_UNIQUE_PTR_ 1
 # define GTEST_HAS_STD_SHARED_PTR_ 1
+# define GTEST_HAS_STD_TYPE_TRAITS_ 1
+# define GTEST_HAS_STD_UNIQUE_PTR_ 1
 #endif
 
 // C++11 specifies that <tuple> provides std::tuple.
@@ -920,14 +921,14 @@ using ::std::tuple_size;
 #endif  // GTEST_HAS_SEH
 
 #ifdef _MSC_VER
-
 # if GTEST_LINKED_AS_SHARED_LIBRARY
 #  define GTEST_API_ __declspec(dllimport)
 # elif GTEST_CREATE_SHARED_LIBRARY
 #  define GTEST_API_ __declspec(dllexport)
 # endif
-
+#elif __GNUC__ >= 4 || defined(__clang__)
-#endif  // _MSC_VER
+# define GTEST_API_ __attribute__((visibility ("default")))
+#endif // _MSC_VER
 
 #ifndef GTEST_API_
 # define GTEST_API_
@@ -1968,13 +1969,8 @@ class MutexBase {
      extern ::testing::internal::MutexBase mutex
 
 // Defines and statically (i.e. at link time) initializes a static mutex.
-// The initialization list here does not explicitly initialize each field,
-// instead relying on default initialization for the unspecified fields. In
-// particular, the owner_ field (a pthread_t) is not explicitly initialized.
-// This allows initialization to work whether pthread_t is a scalar or struct.
-// The flag -Wmissing-field-initializers must not be specified for this to work.
 #  define GTEST_DEFINE_STATIC_MUTEX_(mutex) \
-     ::testing::internal::MutexBase mutex = { PTHREAD_MUTEX_INITIALIZER, false }
+     ::testing::internal::MutexBase mutex = { PTHREAD_MUTEX_INITIALIZER, false, pthread_t() }
 
 // The Mutex class can only be used for mutexes created at runtime. It
 // shares its API with MutexBase otherwise.

3rdparty/googletest/googletest/scripts/fuse_gtest_files.py

@@ -60,7 +60,10 @@ __author__ = 'wan@google.com (Zhanyong Wan)'
 
 import os
 import re
-import sets
+try:
+  from sets import Set as set  # For Python 2.3 compatibility
+except ImportError:
+  pass
 import sys
 
 # We assume that this file is in the scripts/ directory in the Google
@@ -90,10 +93,10 @@ def VerifyFileExists(directory, relative_path):
   """
 
   if not os.path.isfile(os.path.join(directory, relative_path)):
-    print 'ERROR: Cannot find %s in directory %s.' % (relative_path,
+    print('ERROR: Cannot find %s in directory %s.' % (relative_path,
-                                                      directory)
+                                                      directory))
-    print ('Please either specify a valid project root directory '
+    print('Please either specify a valid project root directory '
-           'or omit it on the command line.')
+          'or omit it on the command line.')
     sys.exit(1)
 
 
@@ -119,11 +122,11 @@ def VerifyOutputFile(output_dir, relative_path):
     # TODO(wan@google.com): The following user-interaction doesn't
     # work with automated processes.  We should provide a way for the
     # Makefile to force overwriting the files.
-    print ('%s already exists in directory %s - overwrite it? (y/N) ' %
+    print('%s already exists in directory %s - overwrite it? (y/N) ' %
-           (relative_path, output_dir))
+          (relative_path, output_dir))
     answer = sys.stdin.readline().strip()
     if answer not in ['y', 'Y']:
-      print 'ABORTED.'
+      print('ABORTED.')
       sys.exit(1)
 
   # Makes sure the directory holding the output file exists; creates
@@ -146,8 +149,8 @@ def ValidateOutputDir(output_dir):
 def FuseGTestH(gtest_root, output_dir):
   """Scans folder gtest_root to generate gtest/gtest.h in output_dir."""
 
-  output_file = file(os.path.join(output_dir, GTEST_H_OUTPUT), 'w')
+  output_file = open(os.path.join(output_dir, GTEST_H_OUTPUT), 'w')
-  processed_files = sets.Set()  # Holds all gtest headers we've processed.
+  processed_files = set()  # Holds all gtest headers we've processed.
 
   def ProcessFile(gtest_header_path):
     """Processes the given gtest header file."""
@@ -159,7 +162,7 @@ def FuseGTestH(gtest_root, output_dir):
     processed_files.add(gtest_header_path)
 
     # Reads each line in the given gtest header.
-    for line in file(os.path.join(gtest_root, gtest_header_path), 'r'):
+    for line in open(os.path.join(gtest_root, gtest_header_path), 'r'):
       m = INCLUDE_GTEST_FILE_REGEX.match(line)
       if m:
         # It's '#include "gtest/..."' - let's process it recursively.
@@ -175,7 +178,7 @@ def FuseGTestH(gtest_root, output_dir):
 def FuseGTestAllCcToFile(gtest_root, output_file):
   """Scans folder gtest_root to generate gtest/gtest-all.cc in output_file."""
 
-  processed_files = sets.Set()
+  processed_files = set()
 
   def ProcessFile(gtest_source_file):
     """Processes the given gtest source file."""
@@ -187,7 +190,7 @@ def FuseGTestAllCcToFile(gtest_root, output_file):
     processed_files.add(gtest_source_file)
 
     # Reads each line in the given gtest source file.
-    for line in file(os.path.join(gtest_root, gtest_source_file), 'r'):
+    for line in open(os.path.join(gtest_root, gtest_source_file), 'r'):
       m = INCLUDE_GTEST_FILE_REGEX.match(line)
       if m:
         if 'include/' + m.group(1) == GTEST_SPI_H_SEED:
@@ -218,7 +221,7 @@ def FuseGTestAllCcToFile(gtest_root, output_file):
 def FuseGTestAllCc(gtest_root, output_dir):
   """Scans folder gtest_root to generate gtest/gtest-all.cc in output_dir."""
 
-  output_file = file(os.path.join(output_dir, GTEST_ALL_CC_OUTPUT), 'w')
+  output_file = open(os.path.join(output_dir, GTEST_ALL_CC_OUTPUT), 'w')
   FuseGTestAllCcToFile(gtest_root, output_file)
   output_file.close()
 
@@ -242,7 +245,7 @@ def main():
     # fuse_gtest_files.py GTEST_ROOT_DIR OUTPUT_DIR
     FuseGTest(sys.argv[1], sys.argv[2])
   else:
-    print __doc__
+    print(__doc__)
     sys.exit(1)
 
 

3rdparty/googletest/googletest/src/gtest-internal-inl.h

@@ -1032,7 +1032,7 @@ class TestResultAccessor {
 #if GTEST_CAN_STREAM_RESULTS_
 
 // Streams test results to the given port on the given host machine.
-class StreamingListener : public EmptyTestEventListener {
+class GTEST_API_ StreamingListener : public EmptyTestEventListener {
  public:
   // Abstract base class for writing strings to a socket.
   class AbstractSocketWriter {

3rdparty/googletest/googletest/src/gtest-port.cc

@@ -58,6 +58,11 @@
 # include <sys/procfs.h>
 #endif  // GTEST_OS_QNX
 
+#if GTEST_OS_AIX
+# include <procinfo.h>
+# include <sys/types.h>
+#endif  // GTEST_OS_AIX
+
 #include "gtest/gtest-spi.h"
 #include "gtest/gtest-message.h"
 #include "gtest/internal/gtest-internal.h"
@@ -146,6 +151,19 @@ size_t GetThreadCount() {
   }
 }
 
+#elif GTEST_OS_AIX
+
+size_t GetThreadCount() {
+  struct procentry64 entry;
+  pid_t pid = getpid();
+  int status = getprocs64(&entry, sizeof(entry), NULL, 0, &pid, 1);
+  if (status == 1) {
+    return entry.pi_thcount;
+  } else {
+    return 0;
+  }
+}
+
 #else
 
 size_t GetThreadCount() {

3rdparty/googletest/googletest/src/gtest-printers.cc

@@ -339,12 +339,7 @@ void PrintTo(const wchar_t* s, ostream* os) {
     *os << "NULL";
   } else {
     *os << ImplicitCast_<const void*>(s) << " pointing to ";
-#ifndef __OS2__
     PrintCharsAsStringTo(s, std::wcslen(s), os);
-#else
-    // OS/2 gcc does not declare wcslen() in std namesapce.
-    PrintCharsAsStringTo(s, wcslen(s), os);
-#endif
   }
 }
 #endif  // wchar_t is native

3rdparty/googletest/googletest/src/gtest.cc

@@ -1301,41 +1301,41 @@ std::vector<std::string> SplitEscapedString(const std::string& str) {
 // and their values, as strings.  For example, for ASSERT_EQ(foo, bar)
 // where foo is 5 and bar is 6, we have:
 //
-//   expected_expression: "foo"
+//   lhs_expression: "foo"
-//   actual_expression:   "bar"
+//   rhs_expression: "bar"
-//   expected_value:      "5"
+//   lhs_value:      "5"
-//   actual_value:        "6"
+//   rhs_value:      "6"
 //
 // The ignoring_case parameter is true iff the assertion is a
-// *_STRCASEEQ*.  When it's true, the string " (ignoring case)" will
+// *_STRCASEEQ*.  When it's true, the string "Ignoring case" will
 // be inserted into the message.
-AssertionResult EqFailure(const char* expected_expression,
+AssertionResult EqFailure(const char* lhs_expression,
-                          const char* actual_expression,
+                          const char* rhs_expression,
-                          const std::string& expected_value,
+                          const std::string& lhs_value,
-                          const std::string& actual_value,
+                          const std::string& rhs_value,
                           bool ignoring_case) {
   Message msg;
-  msg << "Value of: " << actual_expression;
+  msg << "      Expected: " << lhs_expression;
-  if (actual_value != actual_expression) {
+  if (lhs_value != lhs_expression) {
-    msg << "\n  Actual: " << actual_value;
+    msg << "\n      Which is: " << lhs_value;
+  }
+  msg << "\nTo be equal to: " << rhs_expression;
+  if (rhs_value != rhs_expression) {
+    msg << "\n      Which is: " << rhs_value;
   }
 
-  msg << "\nExpected: " << expected_expression;
   if (ignoring_case) {
-    msg << " (ignoring case)";
+    msg << "\nIgnoring case";
-  }
-  if (expected_value != expected_expression) {
-    msg << "\nWhich is: " << expected_value;
   }
 
-  if (!expected_value.empty() && !actual_value.empty()) {
+  if (!lhs_value.empty() && !rhs_value.empty()) {
-    const std::vector<std::string> expected_lines =
+    const std::vector<std::string> lhs_lines =
-        SplitEscapedString(expected_value);
+        SplitEscapedString(lhs_value);
-    const std::vector<std::string> actual_lines =
+    const std::vector<std::string> rhs_lines =
-        SplitEscapedString(actual_value);
+        SplitEscapedString(rhs_value);
-    if (expected_lines.size() > 1 || actual_lines.size() > 1) {
+    if (lhs_lines.size() > 1 || rhs_lines.size() > 1) {
       msg << "\nWith diff:\n"
-          << edit_distance::CreateUnifiedDiff(expected_lines, actual_lines);
+          << edit_distance::CreateUnifiedDiff(lhs_lines, rhs_lines);
     }
   }
 
@@ -1434,18 +1434,18 @@ namespace internal {
 
 // The helper function for {ASSERT|EXPECT}_EQ with int or enum
 // arguments.
-AssertionResult CmpHelperEQ(const char* expected_expression,
+AssertionResult CmpHelperEQ(const char* lhs_expression,
-                            const char* actual_expression,
+                            const char* rhs_expression,
-                            BiggestInt expected,
+                            BiggestInt lhs,
-                            BiggestInt actual) {
+                            BiggestInt rhs) {
-  if (expected == actual) {
+  if (lhs == rhs) {
     return AssertionSuccess();
   }
 
-  return EqFailure(expected_expression,
+  return EqFailure(lhs_expression,
-                   actual_expression,
+                   rhs_expression,
-                   FormatForComparisonFailureMessage(expected, actual),
+                   FormatForComparisonFailureMessage(lhs, rhs),
-                   FormatForComparisonFailureMessage(actual, expected),
+                   FormatForComparisonFailureMessage(rhs, lhs),
                    false);
 }
 
@@ -1484,34 +1484,34 @@ GTEST_IMPL_CMP_HELPER_(GT, > )
 #undef GTEST_IMPL_CMP_HELPER_
 
 // The helper function for {ASSERT|EXPECT}_STREQ.
-AssertionResult CmpHelperSTREQ(const char* expected_expression,
+AssertionResult CmpHelperSTREQ(const char* lhs_expression,
-                               const char* actual_expression,
+                               const char* rhs_expression,
-                               const char* expected,
+                               const char* lhs,
-                               const char* actual) {
+                               const char* rhs) {
-  if (String::CStringEquals(expected, actual)) {
+  if (String::CStringEquals(lhs, rhs)) {
     return AssertionSuccess();
   }
 
-  return EqFailure(expected_expression,
+  return EqFailure(lhs_expression,
-                   actual_expression,
+                   rhs_expression,
-                   PrintToString(expected),
+                   PrintToString(lhs),
-                   PrintToString(actual),
+                   PrintToString(rhs),
                    false);
 }
 
 // The helper function for {ASSERT|EXPECT}_STRCASEEQ.
-AssertionResult CmpHelperSTRCASEEQ(const char* expected_expression,
+AssertionResult CmpHelperSTRCASEEQ(const char* lhs_expression,
-                                   const char* actual_expression,
+                                   const char* rhs_expression,
-                                   const char* expected,
+                                   const char* lhs,
-                                   const char* actual) {
+                                   const char* rhs) {
-  if (String::CaseInsensitiveCStringEquals(expected, actual)) {
+  if (String::CaseInsensitiveCStringEquals(lhs, rhs)) {
     return AssertionSuccess();
   }
 
-  return EqFailure(expected_expression,
+  return EqFailure(lhs_expression,
-                   actual_expression,
+                   rhs_expression,
-                   PrintToString(expected),
+                   PrintToString(lhs),
-                   PrintToString(actual),
+                   PrintToString(rhs),
                    true);
 }
 
@@ -1866,18 +1866,18 @@ bool String::WideCStringEquals(const wchar_t * lhs, const wchar_t * rhs) {
 }
 
 // Helper function for *_STREQ on wide strings.
-AssertionResult CmpHelperSTREQ(const char* expected_expression,
+AssertionResult CmpHelperSTREQ(const char* lhs_expression,
-                               const char* actual_expression,
+                               const char* rhs_expression,
-                               const wchar_t* expected,
+                               const wchar_t* lhs,
-                               const wchar_t* actual) {
+                               const wchar_t* rhs) {
-  if (String::WideCStringEquals(expected, actual)) {
+  if (String::WideCStringEquals(lhs, rhs)) {
     return AssertionSuccess();
   }
 
-  return EqFailure(expected_expression,
+  return EqFailure(lhs_expression,
-                   actual_expression,
+                   rhs_expression,
-                   PrintToString(expected),
+                   PrintToString(lhs),
-                   PrintToString(actual),
+                   PrintToString(rhs),
                    false);
 }
 
@@ -2930,6 +2930,8 @@ bool ShouldUseColor(bool stdout_is_tty) {
         String::CStringEquals(term, "xterm-256color") ||
         String::CStringEquals(term, "screen") ||
         String::CStringEquals(term, "screen-256color") ||
+        String::CStringEquals(term, "tmux") ||
+        String::CStringEquals(term, "tmux-256color") ||
         String::CStringEquals(term, "rxvt-unicode") ||
         String::CStringEquals(term, "rxvt-unicode-256color") ||
         String::CStringEquals(term, "linux") ||

3rdparty/googletest/googletest/test/gtest-port_test.cc

@@ -75,8 +75,8 @@ TEST(IsXDigitTest, WorksForNarrowAscii) {
 }
 
 TEST(IsXDigitTest, ReturnsFalseForNarrowNonAscii) {
-  EXPECT_FALSE(IsXDigit(static_cast<char>(0x80)));
+  EXPECT_FALSE(IsXDigit('\x80'));
-  EXPECT_FALSE(IsXDigit(static_cast<char>('0' | 0x80)));
+  EXPECT_FALSE(IsXDigit(static_cast<char>('0' | '\x80')));
 }
 
 TEST(IsXDigitTest, WorksForWideAscii) {

3rdparty/googletest/googletest/test/gtest_env_var_test.py

@@ -47,8 +47,8 @@ environ = os.environ.copy()
 
 def AssertEq(expected, actual):
   if expected != actual:
-    print 'Expected: %s' % (expected,)
+    print('Expected: %s' % (expected,))
-    print '  Actual: %s' % (actual,)
+    print('  Actual: %s' % (actual,))
     raise AssertionError
 
 

3rdparty/googletest/googletest/test/gtest_filter_unittest.py

@@ -44,7 +44,10 @@ __author__ = 'wan@google.com (Zhanyong Wan)'
 
 import os
 import re
-import sets
+try:
+  from sets import Set as set  # For Python 2.3 compatibility
+except ImportError:
+  pass
 import sys
 
 import gtest_test_utils
@@ -58,7 +61,7 @@ import gtest_test_utils
 # exception is thrown if the input is anything other than 'True' nor 'False'.
 os.environ['EMPTY_VAR'] = ''
 child = gtest_test_utils.Subprocess(
-    [sys.executable, '-c', 'import os; print \'EMPTY_VAR\' in os.environ'])
+    [sys.executable, '-c', 'import os; print(\'EMPTY_VAR\' in os.environ)'])
 CAN_PASS_EMPTY_ENV = eval(child.output)
 
 
@@ -71,7 +74,7 @@ CAN_PASS_EMPTY_ENV = eval(child.output)
 os.environ['UNSET_VAR'] = 'X'
 del os.environ['UNSET_VAR']
 child = gtest_test_utils.Subprocess(
-    [sys.executable, '-c', 'import os; print \'UNSET_VAR\' not in os.environ'])
+    [sys.executable, '-c', 'import os; print(\'UNSET_VAR\' not in os.environ)'])
 CAN_UNSET_ENV = eval(child.output)
 
 
@@ -243,14 +246,14 @@ class GTestFilterUnitTest(gtest_test_utils.TestCase):
     for slice_var in list_of_sets:
       full_partition.extend(slice_var)
     self.assertEqual(len(set_var), len(full_partition))
-    self.assertEqual(sets.Set(set_var), sets.Set(full_partition))
+    self.assertEqual(set(set_var), set(full_partition))
 
   def AdjustForParameterizedTests(self, tests_to_run):
     """Adjust tests_to_run in case value parameterized tests are disabled."""
 
     global param_tests_present
     if not param_tests_present:
-      return list(sets.Set(tests_to_run) - sets.Set(PARAM_TESTS))
+      return list(set(tests_to_run) - set(PARAM_TESTS))
     else:
       return tests_to_run
 

3rdparty/googletest/googletest/test/gtest_output_test.py

@@ -279,7 +279,7 @@ class GTestOutputTest(gtest_test_utils.TestCase):
   def testOutput(self):
     output = GetOutputOfAllCommands()
 
-    golden_file = open(GOLDEN_PATH, 'rb')
+    golden_file = open(GOLDEN_PATH, 'r')
     # A mis-configured source control system can cause \r appear in EOL
     # sequences when we read the golden file irrespective of an operating
     # system used. Therefore, we need to strip those \r's from newlines

3rdparty/googletest/googletest/test/gtest_output_test_golden_lin.txt

@@ -5,8 +5,8 @@ Value of: false
   Actual: false
 Expected: true
 gtest_output_test_.cc:#: Failure
-Value of: 3
+      Expected: 2
-Expected: 2
+To be equal to: 3
 [==========] Running 66 tests from 29 test cases.
 [----------] Global test environment set-up.
 FooEnvironment::SetUp() called.
@@ -34,21 +34,21 @@ BarEnvironment::SetUp() called.
 [----------] 2 tests from NonfatalFailureTest
 [ RUN      ] NonfatalFailureTest.EscapesStringOperands
 gtest_output_test_.cc:#: Failure
-Value of: actual
+      Expected: kGoldenString
-  Actual: "actual \"string\""
+      Which is: "\"Line"
-Expected: kGoldenString
+To be equal to: actual
-Which is: "\"Line"
+      Which is: "actual \"string\""
 gtest_output_test_.cc:#: Failure
-Value of: actual
+      Expected: golden
-  Actual: "actual \"string\""
+      Which is: "\"Line"
-Expected: golden
+To be equal to: actual
-Which is: "\"Line"
+      Which is: "actual \"string\""
 [  FAILED  ] NonfatalFailureTest.EscapesStringOperands
 [ RUN      ] NonfatalFailureTest.DiffForLongStrings
 gtest_output_test_.cc:#: Failure
-Value of: "Line 2"
+      Expected: golden_str
-Expected: golden_str
+      Which is: "\"Line\0 1\"\nLine 2"
-Which is: "\"Line\0 1\"\nLine 2"
+To be equal to: "Line 2"
 With diff:
 @@ -1,2 @@
 -\"Line\0 1\"
@@ -59,16 +59,16 @@ With diff:
 [ RUN      ] FatalFailureTest.FatalFailureInSubroutine
 (expecting a failure that x should be 1)
 gtest_output_test_.cc:#: Failure
-Value of: x
+      Expected: 1
-  Actual: 2
+To be equal to: x
-Expected: 1
+      Which is: 2
 [  FAILED  ] FatalFailureTest.FatalFailureInSubroutine
 [ RUN      ] FatalFailureTest.FatalFailureInNestedSubroutine
 (expecting a failure that x should be 1)
 gtest_output_test_.cc:#: Failure
-Value of: x
+      Expected: 1
-  Actual: 2
+To be equal to: x
-Expected: 1
+      Which is: 2
 [  FAILED  ] FatalFailureTest.FatalFailureInNestedSubroutine
 [ RUN      ] FatalFailureTest.NonfatalFailureInSubroutine
 (expecting a failure on false)
@@ -107,39 +107,39 @@ This failure is expected, and shouldn't have a trace.
 [ RUN      ] SCOPED_TRACETest.WorksInLoop
 (expected to fail)
 gtest_output_test_.cc:#: Failure
-Value of: n
+      Expected: 2
-  Actual: 1
+To be equal to: n
-Expected: 2
+      Which is: 1
 Google Test trace:
 gtest_output_test_.cc:#: i = 1
 gtest_output_test_.cc:#: Failure
-Value of: n
+      Expected: 1
-  Actual: 2
+To be equal to: n
-Expected: 1
+      Which is: 2
 Google Test trace:
 gtest_output_test_.cc:#: i = 2
 [  FAILED  ] SCOPED_TRACETest.WorksInLoop
 [ RUN      ] SCOPED_TRACETest.WorksInSubroutine
 (expected to fail)
 gtest_output_test_.cc:#: Failure
-Value of: n
+      Expected: 2
-  Actual: 1
+To be equal to: n
-Expected: 2
+      Which is: 1
 Google Test trace:
 gtest_output_test_.cc:#: n = 1
 gtest_output_test_.cc:#: Failure
-Value of: n
+      Expected: 1
-  Actual: 2
+To be equal to: n
-Expected: 1
+      Which is: 2
 Google Test trace:
 gtest_output_test_.cc:#: n = 2
 [  FAILED  ] SCOPED_TRACETest.WorksInSubroutine
 [ RUN      ] SCOPED_TRACETest.CanBeNested
 (expected to fail)
 gtest_output_test_.cc:#: Failure
-Value of: n
+      Expected: 1
-  Actual: 2
+To be equal to: n
-Expected: 1
+      Which is: 2
 Google Test trace:
 gtest_output_test_.cc:#: n = 2
 gtest_output_test_.cc:#: 
@@ -437,9 +437,9 @@ Expected: 1 fatal failure
 [       OK ] TypedTest/0.Success
 [ RUN      ] TypedTest/0.Failure
 gtest_output_test_.cc:#: Failure
-Value of: TypeParam()
+      Expected: 1
-  Actual: 0
+To be equal to: TypeParam()
-Expected: 1
+      Which is: 0
 Expected failure
 [  FAILED  ] TypedTest/0.Failure, where TypeParam = int
 [----------] 2 tests from Unsigned/TypedTestP/0, where TypeParam = unsigned char
@@ -447,10 +447,10 @@ Expected failure
 [       OK ] Unsigned/TypedTestP/0.Success
 [ RUN      ] Unsigned/TypedTestP/0.Failure
 gtest_output_test_.cc:#: Failure
-Value of: TypeParam()
+      Expected: 1U
-  Actual: '\0'
+      Which is: 1
-Expected: 1U
+To be equal to: TypeParam()
-Which is: 1
+      Which is: '\0'
 Expected failure
 [  FAILED  ] Unsigned/TypedTestP/0.Failure, where TypeParam = unsigned char
 [----------] 2 tests from Unsigned/TypedTestP/1, where TypeParam = unsigned int
@@ -458,10 +458,10 @@ Expected failure
 [       OK ] Unsigned/TypedTestP/1.Success
 [ RUN      ] Unsigned/TypedTestP/1.Failure
 gtest_output_test_.cc:#: Failure
-Value of: TypeParam()
+      Expected: 1U
-  Actual: 0
+      Which is: 1
-Expected: 1U
+To be equal to: TypeParam()
-Which is: 1
+      Which is: 0
 Expected failure
 [  FAILED  ] Unsigned/TypedTestP/1.Failure, where TypeParam = unsigned int
 [----------] 4 tests from ExpectFailureTest
@@ -597,18 +597,18 @@ Expected non-fatal failure.
 [----------] 1 test from PrintingFailingParams/FailingParamTest
 [ RUN      ] PrintingFailingParams/FailingParamTest.Fails/0
 gtest_output_test_.cc:#: Failure
-Value of: GetParam()
+      Expected: 1
-  Actual: 2
+To be equal to: GetParam()
-Expected: 1
+      Which is: 2
 [  FAILED  ] PrintingFailingParams/FailingParamTest.Fails/0, where GetParam() = 2
 [----------] 2 tests from PrintingStrings/ParamTest
 [ RUN      ] PrintingStrings/ParamTest.Success/a
 [       OK ] PrintingStrings/ParamTest.Success/a
 [ RUN      ] PrintingStrings/ParamTest.Failure/a
 gtest_output_test_.cc:#: Failure
-Value of: GetParam()
+      Expected: "b"
-  Actual: "a"
+To be equal to: GetParam()
-Expected: "b"
+      Which is: "a"
 Expected failure
 [  FAILED  ] PrintingStrings/ParamTest.Failure/a, where GetParam() = "a"
 [----------] Global test environment tear-down
@@ -678,16 +678,16 @@ Expected fatal failure.
 [ RUN      ] FatalFailureTest.FatalFailureInSubroutine
 (expecting a failure that x should be 1)
 gtest_output_test_.cc:#: Failure
-Value of: x
+      Expected: 1
-  Actual: 2
+To be equal to: x
-Expected: 1
+      Which is: 2
 [  FAILED  ] FatalFailureTest.FatalFailureInSubroutine (? ms)
 [ RUN      ] FatalFailureTest.FatalFailureInNestedSubroutine
 (expecting a failure that x should be 1)
 gtest_output_test_.cc:#: Failure
-Value of: x
+      Expected: 1
-  Actual: 2
+To be equal to: x
-Expected: 1
+      Which is: 2
 [  FAILED  ] FatalFailureTest.FatalFailureInNestedSubroutine (? ms)
 [ RUN      ] FatalFailureTest.NonfatalFailureInSubroutine
 (expecting a failure on false)

3rdparty/googletest/googletest/test/gtest_test_utils.py

@@ -178,7 +178,7 @@ def GetTestExecutablePath(executable_name, build_dir=None):
         'Unable to find the test binary "%s". Please make sure to provide\n'
         'a path to the binary via the --build_dir flag or the BUILD_DIR\n'
         'environment variable.' % path)
-    print >> sys.stderr, message
+    sys.stdout.write(message)
     sys.exit(1)
 
   return path

3rdparty/googletest/googletest/test/gtest_throw_on_failure_test.py

@@ -70,7 +70,7 @@ def SetEnvVar(env_var, value):
 def Run(command):
   """Runs a command; returns True/False if its exit code is/isn't 0."""
 
-  print 'Running "%s". . .' % ' '.join(command)
+  print('Running "%s". . .' % ' '.join(command))
   p = gtest_test_utils.Subprocess(command)
   return p.exited and p.exit_code == 0
 

3rdparty/googletest/googletest/test/gtest_uninitialized_test.py

@@ -46,8 +46,8 @@ def Assert(condition):
 
 def AssertEq(expected, actual):
   if expected != actual:
-    print 'Expected: %s' % (expected,)
+    print('Expected: %s' % (expected,))
-    print '  Actual: %s' % (actual,)
+    print('  Actual: %s' % (actual,))
     raise AssertionError
 
 

3rdparty/googletest/googletest/test/gtest_unittest.cc

@@ -2466,7 +2466,7 @@ TEST(StringAssertionTest, ASSERT_STRCASEEQ) {
 
   ASSERT_STRCASEEQ("", "");
   EXPECT_FATAL_FAILURE(ASSERT_STRCASEEQ("Hi", "hi2"),
-                       "(ignoring case)");
+                       "Ignoring case");
 }
 
 // Tests ASSERT_STRCASENE.
@@ -3260,7 +3260,7 @@ TEST_F(SingleEvaluationTest, ASSERT_STR) {
 
   // failed EXPECT_STRCASEEQ
   EXPECT_NONFATAL_FAILURE(EXPECT_STRCASEEQ(p1_++, p2_++),
-                          "ignoring case");
+                          "Ignoring case");
   EXPECT_EQ(s1_ + 2, p1_);
   EXPECT_EQ(s2_ + 2, p2_);
 }
@@ -3528,35 +3528,35 @@ TEST(AssertionTest, EqFailure) {
       EqFailure("foo", "bar", foo_val, bar_val, false)
       .failure_message());
   EXPECT_STREQ(
-      "Value of: bar\n"
+      "      Expected: foo\n"
-      "  Actual: 6\n"
+      "      Which is: 5\n"
-      "Expected: foo\n"
+      "To be equal to: bar\n"
-      "Which is: 5",
+      "      Which is: 6",
       msg1.c_str());
 
   const std::string msg2(
       EqFailure("foo", "6", foo_val, bar_val, false)
       .failure_message());
   EXPECT_STREQ(
-      "Value of: 6\n"
+      "      Expected: foo\n"
-      "Expected: foo\n"
+      "      Which is: 5\n"
-      "Which is: 5",
+      "To be equal to: 6",
       msg2.c_str());
 
   const std::string msg3(
       EqFailure("5", "bar", foo_val, bar_val, false)
       .failure_message());
   EXPECT_STREQ(
-      "Value of: bar\n"
+      "      Expected: 5\n"
-      "  Actual: 6\n"
+      "To be equal to: bar\n"
-      "Expected: 5",
+      "      Which is: 6",
       msg3.c_str());
 
   const std::string msg4(
       EqFailure("5", "6", foo_val, bar_val, false).failure_message());
   EXPECT_STREQ(
-      "Value of: 6\n"
+      "      Expected: 5\n"
-      "Expected: 5",
+      "To be equal to: 6",
       msg4.c_str());
 
   const std::string msg5(
@@ -3564,10 +3564,11 @@ TEST(AssertionTest, EqFailure) {
                 std::string("\"x\""), std::string("\"y\""),
                 true).failure_message());
   EXPECT_STREQ(
-      "Value of: bar\n"
+      "      Expected: foo\n"
-      "  Actual: \"y\"\n"
+      "      Which is: \"x\"\n"
-      "Expected: foo (ignoring case)\n"
+      "To be equal to: bar\n"
-      "Which is: \"x\"",
+      "      Which is: \"y\"\n"
+      "Ignoring case",
       msg5.c_str());
 }
 
@@ -3579,11 +3580,11 @@ TEST(AssertionTest, EqFailureWithDiff) {
   const std::string msg1(
       EqFailure("left", "right", left, right, false).failure_message());
   EXPECT_STREQ(
-      "Value of: right\n"
+      "      Expected: left\n"
-      "  Actual: 1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n9\\n11\\n12\\n13\\n14\n"
+      "      Which is: "
-      "Expected: left\n"
-      "Which is: "
       "1\\n2XXX\\n3\\n5\\n6\\n7\\n8\\n9\\n10\\n11\\n12XXX\\n13\\n14\\n15\n"
+      "To be equal to: right\n"
+      "      Which is: 1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n9\\n11\\n12\\n13\\n14\n"
       "With diff:\n@@ -1,5 +1,6 @@\n 1\n-2XXX\n+2\n 3\n+4\n 5\n 6\n"
       "@@ -7,8 +8,6 @@\n 8\n 9\n-10\n 11\n-12XXX\n+12\n 13\n 14\n-15\n",
       msg1.c_str());
@@ -3678,9 +3679,9 @@ TEST(ExpectTest, ASSERT_EQ_Double) {
 TEST(AssertionTest, ASSERT_EQ) {
   ASSERT_EQ(5, 2 + 3);
   EXPECT_FATAL_FAILURE(ASSERT_EQ(5, 2*3),
-                       "Value of: 2*3\n"
+                       "      Expected: 5\n"
-                       "  Actual: 6\n"
+                       "To be equal to: 2*3\n"
-                       "Expected: 5");
+                       "      Which is: 6");
 }
 
 // Tests ASSERT_EQ(NULL, pointer).
@@ -3697,7 +3698,7 @@ TEST(AssertionTest, ASSERT_EQ_NULL) {
   // A failure.
   static int n = 0;
   EXPECT_FATAL_FAILURE(ASSERT_EQ(NULL, &n),
-                       "Value of: &n\n");
+                       "To be equal to: &n\n");
 }
 #endif  // GTEST_CAN_COMPARE_NULL
 
@@ -3812,7 +3813,7 @@ void TestEq1(int x) {
 // Tests calling a test subroutine that's not part of a fixture.
 TEST(AssertionTest, NonFixtureSubroutine) {
   EXPECT_FATAL_FAILURE(TestEq1(2),
-                       "Value of: x");
+                       "To be equal to: x");
 }
 
 // An uncopyable class.
@@ -3861,7 +3862,7 @@ TEST(AssertionTest, AssertWorksWithUncopyableObject) {
   EXPECT_FATAL_FAILURE(TestAssertNonPositive(),
     "IsPositiveUncopyable(y) evaluates to false, where\ny evaluates to -1");
   EXPECT_FATAL_FAILURE(TestAssertEqualsUncopyable(),
-    "Value of: y\n  Actual: -1\nExpected: x\nWhich is: 5");
+    "Expected: x\n      Which is: 5\nTo be equal to: y\n      Which is: -1");
 }
 
 // Tests that uncopyable objects can be used in expects.
@@ -3873,7 +3874,7 @@ TEST(AssertionTest, ExpectWorksWithUncopyableObject) {
     "IsPositiveUncopyable(y) evaluates to false, where\ny evaluates to -1");
   EXPECT_EQ(x, x);
   EXPECT_NONFATAL_FAILURE(EXPECT_EQ(x, y),
-    "Value of: y\n  Actual: -1\nExpected: x\nWhich is: 5");
+    "Expected: x\n      Which is: 5\nTo be equal to: y\n      Which is: -1");
 }
 
 enum NamedEnum {
@@ -3885,7 +3886,7 @@ TEST(AssertionTest, NamedEnum) {
   EXPECT_EQ(kE1, kE1);
   EXPECT_LT(kE1, kE2);
   EXPECT_NONFATAL_FAILURE(EXPECT_EQ(kE1, kE2), "Which is: 0");
-  EXPECT_NONFATAL_FAILURE(EXPECT_EQ(kE1, kE2), "Actual: 1");
+  EXPECT_NONFATAL_FAILURE(EXPECT_EQ(kE1, kE2), "Which is: 1");
 }
 
 // The version of gcc used in XCode 2.2 has a bug and doesn't allow
@@ -3949,9 +3950,9 @@ TEST(AssertionTest, AnonymousEnum) {
 
   // ICE's in C++Builder.
   EXPECT_FATAL_FAILURE(ASSERT_EQ(kCaseA, kCaseB),
-                       "Value of: kCaseB");
+                       "To be equal to: kCaseB");
   EXPECT_FATAL_FAILURE(ASSERT_EQ(kCaseA, kCaseC),
-                       "Actual: 42");
+                       "Which is: 42");
 # endif
 
   EXPECT_FATAL_FAILURE(ASSERT_EQ(kCaseA, kCaseC),
@@ -4389,9 +4390,9 @@ TEST(ExpectTest, ExpectFalseWithAssertionResult) {
 TEST(ExpectTest, EXPECT_EQ) {
   EXPECT_EQ(5, 2 + 3);
   EXPECT_NONFATAL_FAILURE(EXPECT_EQ(5, 2*3),
-                          "Value of: 2*3\n"
+                          "      Expected: 5\n"
-                          "  Actual: 6\n"
+                          "To be equal to: 2*3\n"
-                          "Expected: 5");
+                          "      Which is: 6");
   EXPECT_NONFATAL_FAILURE(EXPECT_EQ(5, 2 - 3),
                           "2 - 3");
 }
@@ -4422,7 +4423,7 @@ TEST(ExpectTest, EXPECT_EQ_NULL) {
   // A failure.
   int n = 0;
   EXPECT_NONFATAL_FAILURE(EXPECT_EQ(NULL, &n),
-                          "Value of: &n\n");
+                          "To be equal to: &n\n");
 }
 #endif  // GTEST_CAN_COMPARE_NULL
 
@@ -4538,7 +4539,7 @@ TEST(ExpectTest, EXPECT_ANY_THROW) {
 TEST(ExpectTest, ExpectPrecedence) {
   EXPECT_EQ(1 < 2, true);
   EXPECT_NONFATAL_FAILURE(EXPECT_EQ(true, true && false),
-                          "Value of: true && false");
+                          "To be equal to: true && false");
 }
 
 
@@ -4685,7 +4686,7 @@ TEST(EqAssertionTest, Bool) {
   EXPECT_FATAL_FAILURE({
       bool false_value = false;
       ASSERT_EQ(false_value, true);
-    }, "Value of: true");
+    }, "To be equal to: true");
 }
 
 // Tests using int values in {EXPECT|ASSERT}_EQ.
@@ -4719,10 +4720,10 @@ TEST(EqAssertionTest, WideChar) {
   EXPECT_EQ(L'b', L'b');
 
   EXPECT_NONFATAL_FAILURE(EXPECT_EQ(L'\0', L'x'),
-                          "Value of: L'x'\n"
+                          "      Expected: L'\0'\n"
-                          "  Actual: L'x' (120, 0x78)\n"
+                          "      Which is: L'\0' (0, 0x0)\n"
-                          "Expected: L'\0'\n"
+                          "To be equal to: L'x'\n"
-                          "Which is: L'\0' (0, 0x0)");
+                          "      Which is: L'x' (120, 0x78)");
 
   static wchar_t wchar;
   wchar = L'b';
@@ -4730,7 +4731,7 @@ TEST(EqAssertionTest, WideChar) {
                           "wchar");
   wchar = 0x8119;
   EXPECT_FATAL_FAILURE(ASSERT_EQ(static_cast<wchar_t>(0x8120), wchar),
-                       "Value of: wchar");
+                       "To be equal to: wchar");
 }
 
 // Tests using ::std::string values in {EXPECT|ASSERT}_EQ.
@@ -4759,8 +4760,8 @@ TEST(EqAssertionTest, StdString) {
   static ::std::string str3(str1);
   str3.at(2) = '\0';
   EXPECT_FATAL_FAILURE(ASSERT_EQ(str1, str3),
-                       "Value of: str3\n"
+                       "To be equal to: str3\n"
-                       "  Actual: \"A \\0 in the middle\"");
+                       "      Which is: \"A \\0 in the middle\"");
 }
 
 #if GTEST_HAS_STD_WSTRING
@@ -4880,7 +4881,7 @@ TEST(EqAssertionTest, CharPointer) {
   ASSERT_EQ(p1, p1);
 
   EXPECT_NONFATAL_FAILURE(EXPECT_EQ(p0, p2),
-                          "Value of: p2");
+                          "To be equal to: p2");
   EXPECT_NONFATAL_FAILURE(EXPECT_EQ(p1, p2),
                           "p2");
   EXPECT_FATAL_FAILURE(ASSERT_EQ(reinterpret_cast<char*>(0x1234),
@@ -4902,7 +4903,7 @@ TEST(EqAssertionTest, WideCharPointer) {
   EXPECT_EQ(p0, p0);
 
   EXPECT_NONFATAL_FAILURE(EXPECT_EQ(p0, p2),
-                          "Value of: p2");
+                          "To be equal to: p2");
   EXPECT_NONFATAL_FAILURE(EXPECT_EQ(p1, p2),
                           "p2");
   void* pv3 = (void*)0x1234;  // NOLINT
@@ -6840,6 +6841,12 @@ TEST(ColoredOutputTest, UsesColorsWhenTermSupportsColors) {
   SetEnv("TERM", "screen-256color");  // TERM supports colors.
   EXPECT_TRUE(ShouldUseColor(true));  // Stdout is a TTY.
 
+  SetEnv("TERM", "tmux");  // TERM supports colors.
+  EXPECT_TRUE(ShouldUseColor(true));  // Stdout is a TTY.
+
+  SetEnv("TERM", "tmux-256color");  // TERM supports colors.
+  EXPECT_TRUE(ShouldUseColor(true));  // Stdout is a TTY.
+
   SetEnv("TERM", "rxvt-unicode");  // TERM supports colors.
   EXPECT_TRUE(ShouldUseColor(true));  // Stdout is a TTY.
 

3rdparty/googletest/googletest/test/gtest_xml_output_unittest.py

@@ -64,20 +64,20 @@ EXPECTED_NON_EMPTY_XML = """<?xml version="1.0" encoding="UTF-8"?>
   </testsuite>
   <testsuite name="FailedTest" tests="1" failures="1" disabled="0" errors="0" time="*">
     <testcase name="Fails" status="run" time="*" classname="FailedTest">
-      <failure message="gtest_xml_output_unittest_.cc:*&#x0A;Value of: 2&#x0A;Expected: 1" type=""><![CDATA[gtest_xml_output_unittest_.cc:*
+      <failure message="gtest_xml_output_unittest_.cc:*&#x0A;      Expected: 1&#x0A;To be equal to: 2" type=""><![CDATA[gtest_xml_output_unittest_.cc:*
-Value of: 2
+      Expected: 1
-Expected: 1%(stack)s]]></failure>
+To be equal to: 2%(stack)s]]></failure>
     </testcase>
   </testsuite>
   <testsuite name="MixedResultTest" tests="3" failures="1" disabled="1" errors="0" time="*">
     <testcase name="Succeeds" status="run" time="*" classname="MixedResultTest"/>
     <testcase name="Fails" status="run" time="*" classname="MixedResultTest">
-      <failure message="gtest_xml_output_unittest_.cc:*&#x0A;Value of: 2&#x0A;Expected: 1" type=""><![CDATA[gtest_xml_output_unittest_.cc:*
+      <failure message="gtest_xml_output_unittest_.cc:*&#x0A;      Expected: 1&#x0A;To be equal to: 2" type=""><![CDATA[gtest_xml_output_unittest_.cc:*
-Value of: 2
+      Expected: 1
-Expected: 1%(stack)s]]></failure>
+To be equal to: 2%(stack)s]]></failure>
-      <failure message="gtest_xml_output_unittest_.cc:*&#x0A;Value of: 3&#x0A;Expected: 2" type=""><![CDATA[gtest_xml_output_unittest_.cc:*
+      <failure message="gtest_xml_output_unittest_.cc:*&#x0A;      Expected: 2&#x0A;To be equal to: 3" type=""><![CDATA[gtest_xml_output_unittest_.cc:*
-Value of: 3
+      Expected: 2
-Expected: 2%(stack)s]]></failure>
+To be equal to: 3%(stack)s]]></failure>
     </testcase>
     <testcase name="DISABLED_test" status="notrun" time="*" classname="MixedResultTest"/>
   </testsuite>
@@ -209,7 +209,8 @@ class GTestXMLOutputUnitTest(gtest_xml_test_utils.GTestXMLTestCase):
         'gtest_no_test_unittest')
     try:
       os.remove(output_file)
-    except OSError, e:
+    except OSError:
+      e = sys.exc_info()[1]
       if e.errno != errno.ENOENT:
         raise
 

3rdparty/googletest/googletest/test/gtest_xml_test_utils.py

@@ -101,7 +101,7 @@ class GTestXMLTestCase(gtest_test_utils.TestCase):
     self.assertEquals(
         len(expected_children), len(actual_children),
         'number of child elements differ in element ' + actual_node.tagName)
-    for child_id, child in expected_children.iteritems():
+    for child_id, child in expected_children.items():
       self.assert_(child_id in actual_children,
                    '<%s> is not in <%s> (in element %s)' %
                    (child_id, actual_children, actual_node.tagName))