Enable line-length lint for markdown docs (#1268)

.markdownlint.json

@@ -1,4 +1,8 @@
 {
     "default": true,
-    "line-length": false
+    "MD013":
+    {
+        "code_blocks": false,
+        "tables": false
+    }
 }

INSTALL.md

@@ -5,7 +5,10 @@ build systems for opentelemetry-cpp.
 
 ## Dependencies
 
-You can link OpenTelemetry C++ SDK with libraries provided in [dependencies.md](https://github.com/open-telemetry/opentelemetry-cpp/blob/main/docs/dependencies.md) (complete list of libraries with versions used in our CI can be found [here](https://github.com/open-telemetry/opentelemetry-cpp/blob/main/third_party_release)).
+You can link OpenTelemetry C++ SDK with libraries provided in
+[dependencies.md](https://github.com/open-telemetry/opentelemetry-cpp/blob/main/docs/dependencies.md)
+(complete list of libraries with versions used in our CI can be found
+[here](https://github.com/open-telemetry/opentelemetry-cpp/blob/main/third_party_release)).
 
 ## Build instructions using CMake
 
@@ -23,14 +26,17 @@ You can link OpenTelemetry C++ SDK with libraries provided in [dependencies.md](
   unittests. We use CMake version 3.15.2 in our build system. To install CMake,
   consult the [Installing CMake](https://cmake.org/install/) guide.
 - [GoogleTest](https://github.com/google/googletest) framework to build and run
-  the unittests. Refer to [third_party_release](https://github.com/open-telemetry/opentelemetry-cpp/blob/main/third_party_release#L5)
-  for version of GoogleTest used in CI. To
-  install GoogleTest, consult the [GoogleTest Build
+  the unittests. Refer to
+  [third_party_release](https://github.com/open-telemetry/opentelemetry-cpp/blob/main/third_party_release#L5)
+  for version of GoogleTest used in CI. To install GoogleTest, consult the
+  [GoogleTest Build
   Instructions](https://github.com/google/googletest/blob/master/googletest/README.md#generic-build-instructions).
-- [Google Benchmark](https://github.com/google/benchmark) framework to build and run
-  benchmark tests. Refer to [third_party_release](https://github.com/open-telemetry/opentelemetry-cpp/blob/main/third_party_release#L4)
-  for version of Benchmark used in CI. To install Benchmark,
-  consult the [GoogleBenchmark Build Instructions](https://github.com/google/benchmark#installation).
+- [Google Benchmark](https://github.com/google/benchmark) framework to build and
+  run benchmark tests. Refer to
+  [third_party_release](https://github.com/open-telemetry/opentelemetry-cpp/blob/main/third_party_release#L4)
+  for version of Benchmark used in CI. To install Benchmark, consult the
+  [GoogleBenchmark Build
+  Instructions](https://github.com/google/benchmark#installation).
 - Apart from above core requirements, the Exporters and Propagators have their
   build dependencies which are not covered here. E.g, Otlp Exporter needs
   grpc/protobuf library, Zipkin exporter needs nlohmann-json and libcurl, ETW
@@ -75,9 +81,9 @@ You can link OpenTelemetry C++ SDK with libraries provided in [dependencies.md](
      configuration, the code is compiled without `-fpic` option, so it is not
      suitable for inclusion in shared libraries. To enable the code for
      inclusion in shared libraries, this variable is used.
-   - `-DBUILD_SHARED_LIBS=ON` : To build shared libraries for the targets. Please
-      refer to note [below](#building-shared-libs-for-windows) for Windows DLL
-      support
+   - `-DBUILD_SHARED_LIBS=ON` : To build shared libraries for the targets.
+      Please refer to note [below](#building-shared-libs-for-windows) for
+      Windows DLL support
    - `-DWITH_OTLP=ON` : To enable building Otlp exporter.
    - `-DWITH_PROMETHEUS=ON` : To enable building prometheus exporter.
 
@@ -145,23 +151,25 @@ target_link_libraries(foo PRIVATE ${OPENTELEMETRY_CPP_LIBRARIES})
 ## Build instructions using Bazel
 
 NOTE: Experimental, and not supported for all the components. Make sure the
-[GoogleTest](https://github.com/google/googletest) installation may fail if there is a different version of googletest already installed in system-defined path.
+[GoogleTest](https://github.com/google/googletest) installation may fail if
+there is a different version of googletest already installed in system-defined
+path.
 
 ### Prerequisites for Bazel
 
-- A supported platform (e.g. Windows, macOS or Linux).
-Refer to [Platforms Supported](./README.md#supported-development-platforms)
-for more information.
-- A compatible C++ compiler supporting at least C++11.
-Major compilers are supported.
-Refer to [Supported Compilers](./README.md#supported-c-versions) for more information.
-- [Git](https://git-scm.com/) for fetching opentelemetry-cpp source code from repository.
-To install Git, consult the [Set up Git](https://help.github.com/articles/set-up-git/)
-guide on GitHub.
-- [Bazel](https://www.bazel.build/) for building opentelemetry-cpp API,
-SDK with their unittests. We use 3.7.2 in our build system.
+- A supported platform (e.g. Windows, macOS or Linux). Refer to [Platforms
+Supported](./README.md#supported-development-platforms) for more information.
+- A compatible C++ compiler supporting at least C++11. Major compilers are
+supported. Refer to [Supported Compilers](./README.md#supported-c-versions) for
+more information.
+- [Git](https://git-scm.com/) for fetching opentelemetry-cpp source code from
+repository. To install Git, consult the [Set up
+Git](https://help.github.com/articles/set-up-git/) guide on GitHub.
+- [Bazel](https://www.bazel.build/) for building opentelemetry-cpp API, SDK with
+their unittests. We use 3.7.2 in our build system.
 
-To install Bazel, consult the [Installing Bazel](https://docs.bazel.build/versions/3.7.0/install.html) guide.
+To install Bazel, consult the [Installing
+Bazel](https://docs.bazel.build/versions/3.7.0/install.html) guide.
 
 ### Building as standalone Bazel Project
 
@@ -178,7 +186,8 @@ To install Bazel, consult the [Installing Bazel](https://docs.bazel.build/versio
    $
    ```
 
-2. Navigate to the repository cloned above, download the dependencies and build the source code:
+2. Navigate to the repository cloned above, download the dependencies and build
+   the source code:
 
    ```console
    $ cd opentelemtry-cpp
@@ -252,23 +261,26 @@ cc_library(
 
 ## Building shared libs for Windows
 
-Windows DLL build is not supported. There are some constraints on how C++ DLLs work on
-Windows, specifically we can't safely allocate memory in one DLL and free it in another.
-For now, OpenTelemetry C++ targets need to be statically linked into the Windows applications.
+Windows DLL build is not supported. There are some constraints on how C++ DLLs
+work on Windows, specifically we can't safely allocate memory in one DLL and
+free it in another. For now, OpenTelemetry C++ targets need to be statically
+linked into the Windows applications.
 
 ## Using Package Managers
 
-If you are using [Conan](https://www.conan.io/) to manage your dependencies,
-add [`opentelemetry-cpp/x.y.z`](https://conan.io/center/opentelemetry-cpp) to
-your `conanfile`'s requires, where `x.y.z` is the release version you want to use.
+If you are using [Conan](https://www.conan.io/) to manage your dependencies, add
+[`opentelemetry-cpp/x.y.z`](https://conan.io/center/opentelemetry-cpp) to your
+`conanfile`'s requires, where `x.y.z` is the release version you want to use.
 Please file issues [here](https://github.com/conan-io/conan-center-index/issues)
 if you experience problems with the packages.
 
 If you are using [vcpkg](https://github.com/Microsoft/vcpkg/) on your project
-for external dependencies, then you can install the
-[opentelemetry-cpp package](https://github.com/microsoft/vcpkg/tree/master/ports/opentelemetry-cpp)
-with `vcpkg install opentelemetry-cpp` and follow the then displayed descriptions.
-Please see the vcpkg project for any issues regarding the packaging.
-
-Please note, these packages are not officially provided and maintained by OpenTelemetry C++ project,
-and are just listed here to consolidate all such efforts for ease of developers.
+for external dependencies, then you can install the [opentelemetry-cpp
+package](https://github.com/microsoft/vcpkg/tree/master/ports/opentelemetry-cpp)
+with `vcpkg install opentelemetry-cpp` and follow the then displayed
+descriptions. Please see the vcpkg project for any issues regarding the
+packaging.
+
+Please note, these packages are not officially provided and maintained by
+OpenTelemetry C++ project, and are just listed here to consolidate all such
+efforts for ease of developers.

README.md

@@ -16,8 +16,16 @@ The C++ [OpenTelemetry](https://opentelemetry.io/) client.
 | Metrics | Development  [1]       | N/A                                                                      |
 | Logs    | Experimental [2]       | N/A                                                                      |
 
-* [1]: The development of the metrics API and SDK based on new stable specification is ongoing. The timelines would be available in release milestone. The earlier implementation (based on old specification) can be included in build by setting `ENABLE_METRICS_PREVIEW` preprocessor macro, and is included under `*/_metrics/*` directory. This would be eventually removed once the ongoing implemetation is stable.
-* [2]: The current Log Signal Implementation is Experimental, and will change as the current OpenTelemetry Log specification matures. The current implementation can be included in build by setting `ENABLE_LOGS_PREVIEW` preprocessor macro.
+* [1]: The development of the metrics API and SDK based on new stable
+      specification is ongoing. The timelines would be available in release
+      milestone. The earlier implementation (based on old specification) can be
+      included in build by setting `ENABLE_METRICS_PREVIEW` preprocessor macro,
+      and is included under `*/_metrics/*` directory. This would be eventually
+      removed once the ongoing implemetation is stable.
+* [2]: The current Log Signal Implementation is Experimental, and will change as
+      the current OpenTelemetry Log specification matures. The current
+      implementation can be included in build by setting `ENABLE_LOGS_PREVIEW`
+      preprocessor macro.
 
 ## OpenTelemetry Specification Compatibility Matrix
 
@@ -26,7 +34,8 @@ The C++ [OpenTelemetry](https://opentelemetry.io/) client.
 | 1.0.0       | 1.0.0-rc4    | N/A [1]                 |
 | 1.0.0       | 1.0.0        | N/A                     |
 
-* [1]: We don't have releases for opentelemetry-cpp contrib repo. This may change in future.
+* [1]: We don't have releases for opentelemetry-cpp contrib repo. This may
+      change in future.
 
 ## Supported C++ Versions
 
@@ -66,15 +75,18 @@ having C++ compiler with [supported C++ standards](#supported-c-versions).
 
 ## Dependencies
 
-Please refer to [Dependencies.md](docs/dependencies.md) for OSS Dependencies and license requirements.
+Please refer to [Dependencies.md](docs/dependencies.md) for OSS Dependencies and
+license requirements.
 
 ## Installation
 
 Please refer to [INSTALL.md](./INSTALL.md).
 
 ## Getting Started
 
-As an application owner or the library author, you can find the getting started guide and reference documentation on [opentelemetry-cpp.readthedocs.io](https://opentelemetry-cpp.readthedocs.io/en/latest/)
+As an application owner or the library author, you can find the getting started
+guide and reference documentation on
+[opentelemetry-cpp.readthedocs.io](https://opentelemetry-cpp.readthedocs.io/en/latest/)
 
 The `examples/simple` directory contains a minimal program demonstrating how to
 instrument a small library using a simple `processor` and console `exporter`,

Versioning.md

@@ -19,20 +19,20 @@ buy may not work in applications using `opentelemetry 2.0.0`.
 
 Refer to the [ABI Policy](./docs/abi-policy.md) for more details. To summarise:
 
-* The API is header only, and uses ABI compliant interfaces. However, ABI stability
-  is not guaranteed for SDK.
-* In case of ABI breaking changes, a new `inline namespace` version will
-  be introduced, and the existing linked applications can continue using the older version
-  unless they relink with newer version.
+* The API is header only, and uses ABI compliant interfaces. However, ABI
+  stability is not guaranteed for SDK.
+* In case of ABI breaking changes, a new `inline namespace` version will be
+  introduced, and the existing linked applications can continue using the older
+  version unless they relink with newer version.
 
 ## Release Policy
 
 * Release versions will follow [SemVer 2.0](https://semver.org/).
 * Only a single source package containing the API, SDK, and exporters which are
   required by the specification would be released. All these components are
-  always versioned and released together. For example, any changes in one of the exporter
-  would result in version update of the entire source package even though there is
-  no changes in API, SDK and other exporters.
+  always versioned and released together. For example, any changes in one of the
+  exporter would result in version update of the entire source package even
+  though there is no changes in API, SDK and other exporters.
 * Experimental releases: New (unstable) telemetry signals and features will be
   introduced behind feature flag protected by a preprocessor macro.
 
@@ -65,16 +65,19 @@ Refer to the [ABI Policy](./docs/abi-policy.md) for more details. To summarise:
   allowed to break existing stable interfaces. Feature flags will be removed
   once we have a stable implementation for the signal.
 
-* As an exception, small experimental features in otherwise stable signals/components
-  mayn't necessarily be released under feature flag. These would be flagged as experimental
-  by adding a `NOTE` in it's header file - either at the beginning of file, or as the comment for
-  the experimental API methods. Also, if the complete header is experimental, it would be prefixed
-  as `experimental_`. As an example, the semantic conventions for
-  trace signal is experimental at the time of the writing and is within `experimental_semantic_conventions.h`
-
-* Code under the "*::detail" namespace implements internal details,
-  and is NOT part of public interface. Also, any API not documented in the [public
-  documentation](https://opentelemetry-cpp.readthedocs.io/en/latest/) is NOT part of the public interface.
+* As an exception, small experimental features in otherwise stable
+  signals/components mayn't necessarily be released under feature flag. These
+  would be flagged as experimental by adding a `NOTE` in it's header file -
+  either at the beginning of file, or as the comment for the experimental API
+  methods. Also, if the complete header is experimental, it would be prefixed as
+  `experimental_`. As an example, the semantic conventions for trace signal is
+  experimental at the time of the writing and is within
+  `experimental_semantic_conventions.h`
+
+* Code under the "*::detail" namespace implements internal details, and is NOT
+  part of public interface. Also, any API not documented in the [public
+  documentation](https://opentelemetry-cpp.readthedocs.io/en/latest/) is NOT
+  part of the public interface.
 
 * GitHub releases will be made for all released versions.
 

docs/building-with-stdlib.md

@@ -162,7 +162,9 @@ gcc-7              | C++17             | requires `gsl::span` for `std::span` im
 gcc-9+             | C++20             |
 
 If SDK is compiled without standard library classes, then `nostd::variant`
-implementation internally uses a private snapshot of [Abseil Variant](https://github.com/abseil/abseil-cpp/blob/master/absl/types/variant.h) .
+implementation internally uses a private snapshot of [Abseil
+Variant](https://github.com/abseil/abseil-cpp/blob/master/absl/types/variant.h)
+.
 
 Other modern C++ language features used by OpenTelemetry, e.g.
 `std::string_view` and `std::variant` are available in C++17 standard library.

docs/building-with-vs2019.md

@@ -136,7 +136,8 @@ instructions that detail how to [run build build tools in a docker container](ht
 build tooling. This script installs all build tools and builds all 3rd party
 dependencies from source using [vcpkg package manager](https://vcpkg.io/en/index.html).
 - Launch Visual Studio 2019 IDE.
-- Use `Open a local folder` option to open the folder where you cloned the source code.
+- Use `Open a local folder` option to open the folder where you cloned the
+  source code.
 - Right-click on `CMakeLists.txt` and choose `Generate Cache for opentelemetry-cpp`.
 - In the top bar menu - select `Build -> Build All` to build SDK, Exporters and Tests.
 - You can use [Google Test Adapter](https://marketplace.visualstudio.com/items?itemName=ChristianSoltenborn.GoogleTestAdapter)

docs/cpp-metrics-api-design.md

@@ -139,7 +139,6 @@ private:
 };
 ```
 
-<!-- markdownlint-disable MD013 -->
 ```cpp
 # meter_provider.h
 class MeterProvider
@@ -170,7 +169,7 @@ function.
 This interface consists of a set of **instrument constructors**, and a
 **facility for capturing batches of measurements.**
 
-```cpp
+``` cpp
 # meter.h
 class Meter {
 public:
@@ -258,7 +257,6 @@ private:
   InstrumentationInfo instrumentationInfo_;
 }
 ```
-<!-- markdownlint-enable MD013 -->
 
 ### Meter API Class Design Considerations
 
@@ -354,7 +352,6 @@ call: `instrument.Add(x, labels)`.
 MUST support `RecordBatch` calling (where a single set of labels is applied to
 several metric instruments).
 
-<!-- markdownlint-disable MD013 -->
 ```cpp
 # metric.h
 
@@ -516,15 +513,13 @@ private:
     void (*callback_)(ObserverResult<T>);
 };
 ```
-<!-- markdownlint-enable MD013 -->
 
 The Counter below is an example of one Metric instrument.  It is important to
 note that in the Counter’s add function, it binds the labels to the instrument
 before calling add, then unbinds.  Therefore all interactions with the
 aggregator take place through bound instruments and by extension, the
 BaseBoundInstrument Class.
 
-<!-- markdownlint-disable MD013 -->
 ```cpp
 template <class T>
 class BoundCounter: public BoundSynchronousInstrument{ //override bind?
@@ -599,7 +594,6 @@ class BoundUpDownSumObserver: public AsynchronousInstrument;
 class ValueObserver: public AsynchronousInstrument;
 class BoundValueObserver: public AsynchronousInstrument;
 ```
-<!-- markdownlint-enable MD013 -->
 
 ### Metric Class Design Considerations
 

docs/cpp-metrics-sdk-design.md

@@ -133,7 +133,6 @@ error.**
 
 **Implementation:**
 
-<!-- markdownlint-disable MD013 -->
 ```cpp
 # meter.h / meter.cc
 class Meter : public API::Meter {
@@ -271,9 +270,7 @@ private:
   InstrumentationInfo instrumentationInfo_;
 };
 ```
-<!-- markdownlint-enable MD013 -->
 
-<!-- markdownlint-disable MD013 -->
 ```cpp
 # record.h
 /*
@@ -316,7 +313,6 @@ private:
   nostd::variant<Aggregator<short>, Aggregator<int>, Aggregator<float>, Aggregator<Double>> aggregator_;
 };
 ```
-<!-- markdownlint-enable MD013 -->
 
 Metric instruments created from this Meter class will be stored in a map (or
 another, similar container [needs to be nostd]) called “metrics.” This is

docs/cpp-ostream-exporter-design.md

@@ -101,7 +101,6 @@ want to make the shutdown timeout configurable.
 In the OStreamExporter there is no cleanup to be done, so there is no need to
 use the timeout within the `Shutdown` function as it will never be blocking.
 
-<!-- markdownlint-disable MD013 -->
 ```cpp
 class StreamSpanExporter final : public sdktrace::SpanExporter
 {
@@ -162,7 +161,6 @@ public:
     }
 };
 ```
-<!-- markdownlint-enable MD013 -->
 
 ## MetricsExporter