Markdown emphasis corrections (#5588)

* Add markdown formatting to extras/formatting.sh

* Correct formatting in markdown

* Warn on unrecognized argument in formatting script

* Print all diffs in formatting script

* Correct markdown emph formatting

* Don't format markdown by default

---------

Co-authored-by: Yong He <[email protected]>

CONTRIBUTION.md

@@ -243,7 +243,7 @@ Here are a few highlights
 1. Don't use the STL containers, iostreams, or the built-in C++ RTTI system.
 1. Don't use the C++ variants of C headers (e.g., use `<stdio.h>` instead of `<cstdio>`).
 1. Don't use exceptions for non-fatal errors (and even then support a build flag to opt out of exceptions).
-1. Types should use UpperCamelCase, values should use lowerCamelCase, and macros should use SCREAMING_SNAKE_CASE with a prefix `SLANG_`.
+1. Types should use UpperCamelCase, values should use lowerCamelCase, and macros should use `SCREAMING_SNAKE_CASE` with a prefix `SLANG_`.
 1. Global variables should have a `g` prefix, non-const static class members can have an `s` prefix, constant data (in the sense of static const) should have a `k` prefix, and an `m_` prefix on member variables and a `_` prefix on member functions are allowed.
 1. Prefixes based on types (e.g., p for pointers) should never be used.
 1. In function parameter lists, an `in`, `out`, or `io` prefix can be added to a parameter name to indicate whether a pointer/reference/buffer is intended to be used for input, output, or both input and output.

docs/64bit-type-support.md

@@ -20,9 +20,9 @@ Overview
 
 The Slang language supports 64 bit built in types. Such as
 
-* double
-* uint64_t
-* int64_t
+* `double`
+* `uint64_t`
+* `int64_t`
 
 This also applies to vector and matrix versions of these types. 
 
@@ -125,8 +125,8 @@ D3D12    | FXC/DXBC         |      No        |          No        |   2
 
 2) uint64_t support requires https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/hlsl-shader-model-6-0-features-for-direct3d-12, so DXBC is not a target.
 
-The intrinsics available on uint64_t type are `abs`, `min`, `max`, `clamp` and `countbits`.
-The intrinsics available on uint64_t type are `abs`, `min`, `max` and `clamp`.
+The intrinsics available on `uint64_t` type are `abs`, `min`, `max`, `clamp` and `countbits`.
+The intrinsics available on `uint64_t` type are `abs`, `min`, `max` and `clamp`.
 
 GLSL
 ====

docs/cpu-target.md

@@ -52,9 +52,9 @@ SLANG_HOST_CPP_SOURCE,     ///< C++ code for `host` style
 
 Using the `-target` command line option
 
-* C_SOURCE: c
-* CPP_SOURCE: cpp,c++,cxx
-* HOST_CPP_SOURCE: host-cpp,host-c++,host-cxx
+* `C_SOURCE`: c
+* `CPP_SOURCE`: cpp,c++,cxx
+* `HOST_CPP_SOURCE`: host-cpp,host-c++,host-cxx
 
 Note! Output of C source is not currently supported.
 
@@ -70,11 +70,11 @@ SLANG_OBJECT_CODE,              ///< Object code that can be used for later link
 
 Using the `-target` command line option
 
-* EXECUTABLE: exe, executable
-* SHADER_SHARED_LIBRARY: sharedlib, sharedlibrary, dll
-* SHADER_HOST_CALLABLE: callable, host-callable
-* OBJECT_CODE: object-conde
-* HOST_HOST_CALLABLE: host-host-callable
+* `EXECUTABLE`: exe, executable
+* `SHADER_SHARED_LIBRARY`: sharedlib, sharedlibrary, dll
+* `SHADER_HOST_CALLABLE`: callable, host-callable
+* `OBJECT_CODE`: object-conde
+* `HOST_HOST_CALLABLE`: host-host-callable
 
 Using `host-callable` types from the the command line, other than to test such code compile and can be loaded for host execution.
 

docs/cuda-target.md

@@ -256,7 +256,7 @@ If this fails - the prelude include of `cuda_fp16.h` will most likely fail on NV
 
 CUDA has the `__half` and `__half2` types defined in `cuda_fp16.h`. The `__half2` can produce results just as quickly as doing the same operation on `__half` - in essence for some operations `__half2` is [SIMD](https://en.wikipedia.org/wiki/SIMD) like. The half implementation in Slang tries to take advantage of this optimization.
 
-Since Slang supports up to 4 wide vectors Slang has to build on CUDAs half support. The types _`_half3` and `__half4` are implemented in `slang-cuda-prelude.h` for this reason. It is worth noting that `__half3` is made up of a `__half2` and a `__half`. As `__half2` is 4 byte aligned, this means `__half3` is actually 8 bytes, rather than 6 bytes that might be expected.
+Since Slang supports up to 4 wide vectors Slang has to build on CUDAs half support. The types `__half3` and `__half4` are implemented in `slang-cuda-prelude.h` for this reason. It is worth noting that `__half3` is made up of a `__half2` and a `__half`. As `__half2` is 4 byte aligned, this means `__half3` is actually 8 bytes, rather than 6 bytes that might be expected.
 
 One area where this optimization isn't fully used is in comparisons - as in effect Slang treats all the vector/matrix half comparisons as if they are scalar. This could be perhaps be improved on in the future. Doing so would require using features that are not directly available in the CUDA headers.
 
@@ -265,7 +265,7 @@ Wave Intrinsics
 
 There is broad support for [HLSL Wave intrinsics](https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/hlsl-shader-model-6-0-features-for-direct3d-12), including support for [SM 6.5 intrinsics](https://microsoft.github.io/DirectX-Specs/d3d/HLSL_ShaderModel6_5.html).
 
-Most Wave intrinsics will work with vector, matrix or scalar types of typical built in types - uint, int, float, double, uint64_t, int64_t.
+Most Wave intrinsics will work with vector, matrix or scalar types of typical built in types - `uint`, `int`, `float`, `double`, `uint64_t`, `int64_t`.
 
 The support is provided via both the Slang core module as well as the Slang CUDA prelude found in 'prelude/slang-cuda-prelude.h'. Many Wave intrinsics are not directly applicable within CUDA which supplies a more low level mechanisms. The implementation of most Wave functions work most optimally if a 'Wave' where all lanes are used. If all lanes from index 0 to pow2(n) -1  are used (which is also true if all lanes are used) a binary reduction is typically applied. If this is not the case the implementation fallsback on a slow path which is linear in the number of active lanes, and so is typically significantly less performant.
 

docs/design/experimental.md

@@ -31,7 +31,7 @@ Adding Experimental Interfaces
 
 When the above recommendations cannot be followed, as with features that are expected to be iterated on or are regarded as temporary, there are additional recommendations.
 
-Interfaces that are expected to change must be marked "_Experimental" in their class name and in their UUID name.
+Interfaces that are expected to change must be marked `_Experimental` in their class name and in their UUID name.
 
 For example,