fix numbering of ordered lists in Markdown

CONTRIBUTING.md

@@ -29,19 +29,19 @@ PR is acceptable as an alternative.
 
 1.  Submit an issue describing your proposed change to the
     [issue tracker](https://github.com/google/googletest).
-1.  Please don't mix more than one logical change per submittal, because it
+2.  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.
+3.  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.  If your proposed change is accepted, and you haven't already done so, sign a
+4.  If your proposed change is accepted, and you haven't already done so, sign a
     Contributor License Agreement (see details above).
-1.  Fork the desired repo, develop and test your code changes.
-1.  Ensure that your code adheres to the existing style in the sample to which
+5.  Fork the desired repo, develop and test your code changes.
+6.  Ensure that your code adheres to the existing style in the sample to which
     you are contributing.
-1.  Ensure that your code has an appropriate set of unit tests which all pass.
-1.  Submit a pull request.
+7.  Ensure that your code has an appropriate set of unit tests which all pass.
+8.  Submit a pull request.
 
 ## The Google Test and Google Mock Communities
 

googlemock/docs/cheat_sheet.md

@@ -581,10 +581,10 @@ which must be a permanent callback.
 **Notes:**
 
 1.  The `MATCHER*` macros cannot be used inside a function or class.
-1.  The matcher body must be *purely functional* (i.e. it cannot have any side
+2.  The matcher body must be *purely functional* (i.e. it cannot have any side
     effect, and the result must not depend on anything other than the value
     being matched and the matcher parameters).
-1.  You can use `PrintToString(x)` to convert a value `x` of any type to a
+3.  You can use `PrintToString(x)` to convert a value `x` of any type to a
     string.
 
 ## Matchers as Test Assertions

googletest/docs/advanced.md

@@ -1150,9 +1150,9 @@ also supports per-test-suite set-up/tear-down. To use it:
 
 1.  In your test fixture class (say `FooTest` ), declare as `static` some member
     variables to hold the shared resources.
-1.  Outside your test fixture class (typically just below it), define those
+2.  Outside your test fixture class (typically just below it), define those
     member variables, optionally giving them initial values.
-1.  In the same test fixture class, define a `static void SetUpTestSuite()`
+3.  In the same test fixture class, define a `static void SetUpTestSuite()`
     function (remember not to spell it as **`SetupTestSuite`** with a small
     `u`!) to set up the shared resources and a `static void TearDownTestSuite()`
     function to tear them down.
@@ -1425,7 +1425,7 @@ To define abstract tests, you should organize your code like this:
 1.  Put the definition of the parameterized test fixture class (e.g. `FooTest`)
     in a header file, say `foo_param_test.h`. Think of this as *declaring* your
     abstract tests.
-1.  Put the `TEST_P` definitions in `foo_param_test.cc`, which includes
+2.  Put the `TEST_P` definitions in `foo_param_test.cc`, which includes
     `foo_param_test.h`. Think of this as *implementing* your abstract tests.
 
 Once they are defined, you can instantiate them by including `foo_param_test.h`,
@@ -1786,10 +1786,10 @@ For technical reasons, there are some caveats:
 
 1.  You cannot stream a failure message to either macro.
 
-1.  `statement` in `EXPECT_FATAL_FAILURE{_ON_ALL_THREADS}()` cannot reference
+2.  `statement` in `EXPECT_FATAL_FAILURE{_ON_ALL_THREADS}()` cannot reference
     local non-static variables or non-static members of `this` object.
 
-1.  `statement` in `EXPECT_FATAL_FAILURE{_ON_ALL_THREADS}()` cannot return a
+3.  `statement` in `EXPECT_FATAL_FAILURE{_ON_ALL_THREADS}()` cannot return a
     value.
 
 ## Registering tests programmatically
@@ -2015,7 +2015,7 @@ when processing an event. There are some restrictions:
 
 1.  You cannot generate any failure in `OnTestPartResult()` (otherwise it will
     cause `OnTestPartResult()` to be called recursively).
-1.  A listener that handles `OnTestPartResult()` is not allowed to generate any
+2.  A listener that handles `OnTestPartResult()` is not allowed to generate any
     failure.
 
 When you add listeners to the listener list, you should put listeners that

googletest/docs/faq.md

@@ -8,7 +8,7 @@ Underscore (`_`) is special, as C++ reserves the following to be used by the
 compiler and the standard library:
 
 1.  any identifier that starts with an `_` followed by an upper-case letter, and
-1.  any identifier that contains two consecutive underscores (i.e. `__`)
+2.  any identifier that contains two consecutive underscores (i.e. `__`)
     *anywhere* in its name.
 
 User code is *prohibited* from using such identifiers.
@@ -22,11 +22,11 @@ contains `_`?
 1.  If `TestSuiteName` starts with an `_` followed by an upper-case letter (say,
     `_Foo`), we end up with `_Foo_TestName_Test`, which is reserved and thus
     invalid.
-1.  If `TestSuiteName` ends with an `_` (say, `Foo_`), we get
+2.  If `TestSuiteName` ends with an `_` (say, `Foo_`), we get
     `Foo__TestName_Test`, which is invalid.
-1.  If `TestName` starts with an `_` (say, `_Bar`), we get
+3.  If `TestName` starts with an `_` (say, `_Bar`), we get
     `TestSuiteName__Bar_Test`, which is invalid.
-1.  If `TestName` ends with an `_` (say, `Bar_`), we get
+4.  If `TestName` ends with an `_` (say, `Bar_`), we get
     `TestSuiteName_Bar__Test`, which is invalid.
 
 So clearly `TestSuiteName` and `TestName` cannot start or end with `_`
@@ -524,8 +524,8 @@ There are several good reasons:
     contaminating others, making debugging difficult. By using fixtures, each
     test has a fresh set of variables that's different (but with the same
     names). Thus, tests are kept independent of each other.
-1.  Global variables pollute the global namespace.
-1.  Test fixtures can be reused via subclassing, which cannot be done easily
+2.  Global variables pollute the global namespace.
+3.  Test fixtures can be reused via subclassing, which cannot be done easily
     with global variables. This is useful if many test suites have something in
     common.
 

googletest/docs/primer.md

@@ -15,26 +15,26 @@ So what makes a good test, and how does googletest fit in? We believe:
     that succeeds or fails as a result of other tests. googletest isolates the
     tests by running each of them on a different object. When a test fails,
     googletest allows you to run it in isolation for quick debugging.
-1.  Tests should be well *organized* and reflect the structure of the tested
+2.  Tests should be well *organized* and reflect the structure of the tested
     code. googletest groups related tests into test suites that can share data
     and subroutines. This common pattern is easy to recognize and makes tests
     easy to maintain. Such consistency is especially helpful when people switch
     projects and start to work on a new code base.
-1.  Tests should be *portable* and *reusable*. Google has a lot of code that is
+3.  Tests should be *portable* and *reusable*. Google has a lot of code that is
     platform-neutral, its tests should also be platform-neutral. googletest
     works on different OSes, with different compilers, with or without
     exceptions, so googletest tests can work with a variety of configurations.
-1.  When tests fail, they should provide as much *information* about the problem
+4.  When tests fail, they should provide as much *information* about the problem
     as possible. googletest doesn't stop at the first test failure. Instead, it
     only stops the current test and continues with the next. You can also set up
     tests that report non-fatal failures after which the current test continues.
     Thus, you can detect and fix multiple bugs in a single run-edit-compile
     cycle.
-1.  The testing framework should liberate test writers from housekeeping chores
+5.  The testing framework should liberate test writers from housekeeping chores
     and let them focus on the test *content*. googletest automatically keeps
     track of all tests defined, and doesn't require the user to enumerate them
     in order to run them.
-1.  Tests should be *fast*. With googletest, you can reuse shared resources
+6.  Tests should be *fast*. With googletest, you can reuse shared resources
     across tests and pay for the set-up/tear-down only once, without making
     tests depend on each other.
 
@@ -245,9 +245,9 @@ To create a test:
 
 1.  Use the `TEST()` macro to define and name a test function, These are
     ordinary C++ functions that don't return a value.
-1.  In this function, along with any valid C++ statements you want to include,
+2.  In this function, along with any valid C++ statements you want to include,
     use the various googletest assertions to check values.
-1.  The test's result is determined by the assertions; if any assertion in the
+3.  The test's result is determined by the assertions; if any assertion in the
     test fails (either fatally or non-fatally), or if the test crashes, the
     entire test fails. Otherwise, it succeeds.
 
@@ -309,16 +309,16 @@ To create a fixture:
 
 1.  Derive a class from `::testing::Test` . Start its body with `protected:` 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
+2.  Inside the class, declare any objects you plan to use.
+3.  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` - Use `override` in C++11 to make sure you
     spelled it correctly
-1.  If necessary, write a destructor or `TearDown()` function to release any
+4.  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
     the [FAQ](faq.md).
-1.  If needed, define subroutines for your tests to share.
+5.  If needed, define subroutines for your tests to share.
 
 When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to
 access objects and subroutines in the test fixture:
@@ -422,11 +422,11 @@ would lead to a segfault when `n` is `NULL`.
 When these tests run, the following happens:
 
 1.  googletest constructs a `QueueTest` object (let's call it `t1` ).
-1.  `t1.SetUp()` initializes `t1` .
-1.  The first test ( `IsEmptyInitially` ) runs on `t1` .
-1.  `t1.TearDown()` cleans up after the test finishes.
-1.  `t1` is destructed.
-1.  The above steps are repeated on another `QueueTest` object, this time
+2.  `t1.SetUp()` initializes `t1` .
+3.  The first test ( `IsEmptyInitially` ) runs on `t1` .
+4.  `t1.TearDown()` cleans up after the test finishes.
+5.  `t1` is destructed.
+6.  The above steps are repeated on another `QueueTest` object, this time
     running the `DequeueWorks` test.
 
 **Availability**: Linux, Windows, Mac.