Googletest export

Add files for GitHub Pages

PiperOrigin-RevId: 357096486
diff --git a/docs/faq.md b/docs/faq.md
index 4491d97..79ca400 100644
--- a/docs/faq.md
+++ b/docs/faq.md
@@ -580,8 +580,6 @@
 }
 ```
 
-gtest-death-test_test.cc contains more examples if you are interested.
-
 ## I have a fixture class `FooTest`, but `TEST_F(FooTest, Bar)` gives me error ``"no matching function for call to `FooTest::FooTest()'"``. Why?
 
 Googletest needs to be able to create objects of your test fixture class, so it
@@ -663,14 +661,15 @@
 match). Admittedly, this is a hack. We'll consider a more permanent solution
 after the fork-and-exec-style death tests are implemented.
 
-## The compiler complains about "no match for 'operator<<'" when I use an assertion. What gives?
+## The compiler complains about `no match for 'operator<<'` when I use an assertion. What gives?
 
 If you use a user-defined type `FooType` in an assertion, you must make sure
 there is an `std::ostream& operator<<(std::ostream&, const FooType&)` function
 defined such that we can print a value of `FooType`.
 
 In addition, if `FooType` is declared in a name space, the `<<` operator also
-needs to be defined in the *same* name space. See abseil.io/tips/49 for details.
+needs to be defined in the *same* name space. See
+[Tip of the Week #49](http://abseil.io/tips/49) for details.
 
 ## How do I suppress the memory leak messages on Windows?
 
@@ -691,10 +690,10 @@
 advise against the practice, and googletest doesn't provide a way to do it.
 
 In general, the recommended way to cause the code to behave differently under
-test is [Dependency Injection](https://en.wikipedia.org/wiki/Dependency_injection). You can inject
+test is [Dependency Injection](http://en.wikipedia.org/wiki/Dependency_injection). You can inject
 different functionality from the test and from the production code. Since your
 production code doesn't link in the for-test logic at all (the
-[`testonly`](https://docs.bazel.build/versions/master/be/common-definitions.html#common.testonly) attribute for BUILD targets helps to ensure
+[`testonly`](http://docs.bazel.build/versions/master/be/common-definitions.html#common.testonly) attribute for BUILD targets helps to ensure
 that), there is no danger in accidentally running it.
 
 However, if you *really*, *really*, *really* have no choice, and if you follow
diff --git a/docs/gmock_cook_book.md b/docs/gmock_cook_book.md
index 0578a8b..432d308 100644
--- a/docs/gmock_cook_book.md
+++ b/docs/gmock_cook_book.md
@@ -1452,6 +1452,8 @@
 
 Use `Pair` when comparing maps or other associative containers.
 
+{% raw %}
+
 ```cpp
 using testing::ElementsAre;
 using testing::Pair;
@@ -1460,6 +1462,8 @@
   EXPECT_THAT(m, ElementsAre(Pair("a", 1), Pair("b", 2), Pair("c", 3)));
 ```
 
+{% endraw %}
+
 **Tips:**
 
 *   `ElementsAre*()` can be used to match *any* container that implements the
@@ -2244,7 +2248,7 @@
 latter. So, you can invoke something whose type is *not* exactly the same as the
 mock function, as long as it's safe to do so - nice, huh?
 
-**`Note:`{.escaped}**
+Note that:
 
 *   The action takes ownership of the callback and will delete it when the
     action itself is destructed.
@@ -2330,7 +2334,7 @@
   foo.ComplexJob(20);  // Invokes Job2(5, 'a').
 ```
 
-**`Note:`{.escaped}**
+Note that:
 
 *   The action takes ownership of the callback and will delete it when the
     action itself is destructed.
@@ -2875,8 +2879,8 @@
 #### Legacy workarounds for move-only types {#LegacyMoveOnly}
 
 Support for move-only function arguments was only introduced to gMock in April
-2017. In older code, you may encounter the following workaround for the lack of
-this feature (it is no longer necessary - we're including it just for
+of 2017. In older code, you may encounter the following workaround for the lack
+of this feature (it is no longer necessary - we're including it just for
 reference):
 
 ```cpp
diff --git a/docs/pkgconfig.md b/docs/pkgconfig.md
index b9bef3f..768e9b4 100644
--- a/docs/pkgconfig.md
+++ b/docs/pkgconfig.md
@@ -145,4 +145,4 @@
 
 which contains the correct sysroot now. For a more comprehensive guide to also
 including `${CHOST}` in build system calls, see the excellent tutorial by Diego
-Elio Pettenò: https://autotools.io/pkgconfig/cross-compiling.html
+Elio Pettenò: <https://autotools.io/pkgconfig/cross-compiling.html>