Merge remote-tracking branch 'upstream/master' into primer_md_table_update

googlemock/docs/cook_book.md

 ## Googletest Mocking (gMock) Cookbook
 
-<!-- GOOGLETEST_CM0011 DO NOT DELETE -->
+<!-- GOOGLETEST_CM0012 DO NOT DELETE -->
 
 You can find recipes for using gMock here. If you haven't yet, please read
 [this](for_dummies.md) first to make sure you understand the basics.
@@ -154,7 +154,7 @@ class MockStack : public StackInterface<Elem> {
 #### Mocking Non-virtual Methods {#MockingNonVirtualMethods}
 
 gMock can mock non-virtual functions to be used in Hi-perf dependency
-injection.<!-- GOOGLETEST_CM0016 DO NOT DELETE -->.
+injection.<!-- GOOGLETEST_CM0017 DO NOT DELETE -->.
 
 In this case, instead of sharing a common base class with the real class, your
 mock class will be *unrelated* to the real class, but contain methods with the
@@ -1455,7 +1455,7 @@ mock object and gMock.
 
 #### Knowing When to Expect {#UseOnCall}
 
-<!-- GOOGLETEST_CM0017 DO NOT DELETE -->
+<!-- GOOGLETEST_CM0018 DO NOT DELETE -->
 
 **`ON_CALL`** is likely the *single most under-utilized construct* in gMock.
 

googlemock/docs/for_dummies.md

 ## Googletest Mocking (gMock) for Dummies {#GMockForDummies}
 
-<!-- GOOGLETEST_CM0012 DO NOT DELETE -->
+<!-- GOOGLETEST_CM0013 DO NOT DELETE -->
 
 ### What Is gMock?
 
@@ -499,7 +499,7 @@ always return 100 as `n++` is only evaluated once. Similarly, `Return(new Foo)`
 will create a new `Foo` object when the `EXPECT_CALL()` is executed, and will
 return the same pointer every time. If you want the side effect to happen every
 time, you need to define a custom action, which we'll teach in the
-[cook book](http://<!-- GOOGLETEST_CM0011 DO NOT DELETE -->).
+[cook book](http://<!-- GOOGLETEST_CM0012 DO NOT DELETE -->).
 
 Time for another quiz! What do you think the following means?
 

googlemock/docs/gmock_faq.md

 ## Legacy gMock FAQ {#GMockFaq}
 
-<!-- GOOGLETEST_CM0020 DO NOT DELETE -->
+<!-- GOOGLETEST_CM0021 DO NOT DELETE -->
 
 ### When I call a method on my mock object, the method for the real object is invoked instead. What's the problem?
 

googletest/README.md

@@ -174,9 +174,9 @@ We list the most frequently used macros below. For a complete list, see file
 ### Multi-threaded Tests
 
 Google Test is thread-safe where the pthread library is available. After
-`#include "gtest/gtest.h"`, you can check the `GTEST_IS_THREADSAFE` macro to see
-whether this is the case (yes if the macro is `#defined` to 1, no if it's
-undefined.).
+`#include "gtest/gtest.h"`, you can check the
+`GTEST_IS_THREADSAFE` macro to see whether this is the case (yes if the macro is
+`#defined` to 1, no if it's undefined.).
 
 If Google Test doesn't correctly detect whether pthread is available in your
 environment, you can force it with

googletest/docs/advanced.md

 # Advanced googletest Topics
 
-<!-- GOOGLETEST_CM0015 DO NOT DELETE -->
+<!-- GOOGLETEST_CM0016 DO NOT DELETE -->
 
 ## Introduction
 
@@ -385,7 +385,7 @@ using ::testing::StartsWith;
 ```
 
 Read this
-[recipe](https://github.com/google/googletest/blob/master/googlemock/docs/cook_book.md#using-matchers-in-googletest-assertions)
+[recipe](../../googlemock/docs/cook_book.md#using-matchers-in-googletest-assertions)
 in the gMock Cookbook for more details.
 
 gMock has a rich set of matchers. You can do many things googletest cannot do

googletest/docs/faq.md

 # Googletest FAQ
 
-<!-- GOOGLETEST_CM0013 DO NOT DELETE -->
+<!-- GOOGLETEST_CM0014 DO NOT DELETE -->
 
 ## Why should test suite names and test names not contain underscore?
 
@@ -332,7 +332,7 @@ You may still want to use `SetUp()/TearDown()` in the following cases:
 *   In the body of a constructor (or destructor), it's not possible to use the
     `ASSERT_xx` macros. Therefore, if the set-up operation could cause a fatal
     test failure that should prevent the test from running, it's necessary to
-    use `abort` <!-- GOOGLETEST_CM0014 DO NOT DELETE --> and abort the whole test executable,
+    use `abort` <!-- GOOGLETEST_CM0015 DO NOT DELETE --> and abort the whole test executable,
     or to use `SetUp()` instead of a constructor.
 *   If the tear-down operation could throw an exception, you must use
     `TearDown()` as opposed to the destructor, as throwing in a destructor leads

googletest/docs/pkgconfig.md

-## Using GoogleTest from various build systems ##
+## Using GoogleTest from various build systems
 
 GoogleTest comes with pkg-config files that can be used to determine all
 necessary flags for compiling and linking to GoogleTest (and GoogleMock).
 Pkg-config is a standardised plain-text format containing
 
-  * the includedir (-I) path
-  * necessary macro (-D) definitions
-  * further required flags (-pthread)
-  * the library (-L) path
-  * the library (-l) to link to
+*   the includedir (-I) path
+*   necessary macro (-D) definitions
+*   further required flags (-pthread)
+*   the library (-L) path
+*   the library (-l) to link to
 
-All current build systems support pkg-config in one way or another. For
-all examples here we assume you want to compile the sample
+All current build systems support pkg-config in one way or another. For all
+examples here we assume you want to compile the sample
 `samples/sample3_unittest.cc`.
 
-
-### CMake ###
+### CMake
 
 Using `pkg-config` in CMake is fairly easy:
 
-``` cmake
+```cmake
 cmake_minimum_required(VERSION 3.0)
 
 cmake_policy(SET CMP0048 NEW)
@@ -43,11 +42,10 @@ that all libraries have been compiled with threading enabled. In addition,
 GoogleTest might also require `-pthread` in the compiling step, and as such
 splitting the pkg-config `Cflags` variable into include dirs and macros for
 `target_compile_definitions()` might still miss this). The same recommendation
-goes for using `_LDFLAGS` over the more commonplace `_LIBRARIES`, which
-happens to discard `-L` flags and `-pthread`.
-
+goes for using `_LDFLAGS` over the more commonplace `_LIBRARIES`, which happens
+to discard `-L` flags and `-pthread`.
 
-### Autotools ###
+### Autotools
 
 Finding GoogleTest in Autoconf and using it from Automake is also fairly easy:
 
@@ -77,8 +75,7 @@ testapp_CXXFLAGS = $(GTEST_CFLAGS)
 testapp_LDADD = $(GTEST_LIBS)
 ```
 
-
-### Meson ###
+### Meson
 
 Meson natively uses pkgconfig to query dependencies:
 
@@ -96,13 +93,12 @@ testapp = executable(
 test('first_and_only_test', testapp)
 ```
 
+### Plain Makefiles
 
-### Plain Makefiles ###
+Since `pkg-config` is a small Unix command-line utility, it can be used in
+handwritten `Makefile`s too:
 
-Since `pkg-config` is a small Unix command-line utility, it can be used
-in handwritten `Makefile`s too:
-
-``` Makefile
+```Makefile
 GTEST_CFLAGS = `pkg-config --cflags gtest_main`
 GTEST_LIBS = `pkg-config --libs gtest_main`
 
@@ -120,12 +116,11 @@ testapp.o: samples/sample3_unittest.cc
   $(CXX) $(CPPFLAGS) $(CXXFLAGS) $< -c -o $@ $(GTEST_CFLAGS)
 ```
 
-
-### Help! pkg-config can't find GoogleTest! ###
+### Help! pkg-config can't find GoogleTest!
 
 Let's say you have a `CMakeLists.txt` along the lines of the one in this
-tutorial and you try to run `cmake`. It is very possible that you get a
-failure along the lines of:
+tutorial and you try to run `cmake`. It is very possible that you get a failure
+along the lines of:
 
 ```
 -- Checking for one of the modules 'gtest_main'
@@ -135,9 +130,9 @@ CMake Error at /usr/share/cmake/Modules/FindPkgConfig.cmake:640 (message):
 
 These failures are common if you installed GoogleTest yourself and have not
 sourced it from a distro or other package manager. If so, you need to tell
-pkg-config where it can find the `.pc` files containing the information.
-Say you installed GoogleTest to `/usr/local`, then it might be that the
-`.pc` files are installed under `/usr/local/lib64/pkgconfig`. If you set
+pkg-config where it can find the `.pc` files containing the information. Say you
+installed GoogleTest to `/usr/local`, then it might be that the `.pc` files are
+installed under `/usr/local/lib64/pkgconfig`. If you set
 
 ```
 export PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig

googletest/docs/primer.md

@@ -164,7 +164,7 @@ you'll get a compiler error. We used to require the arguments to support the
 `<<` is supported, it will be called to print the arguments when the assertion
 fails; otherwise googletest will attempt to print them in the best way it can.
 For more details and how to customize the printing of the arguments, see
-[documentation](https://github.com/google/googletest/blob/master/googlemock/docs/cook_book.md#teaching-gmock-how-to-print-your-values)
+[documentation](../../googlemock/docs/cook_book.md#teaching-gmock-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). Since this is