Skip to content

Commit 5d5c3e7

Browse files
Enable markdownlint rule (MD009) (#40887)
* Create markdownlint.yml * Create markdownlint-problem-matcher.json * Create .markdownlint.json * Update .markdownlint.json * fix violations * fixes * Remove "push" section As advised by @ViktorHofer so it's quite clear it only runs in CI. Co-authored-by: Dan Moseley <[email protected]>
1 parent d1d6ab1 commit 5d5c3e7

File tree

16 files changed

+98
-49
lines changed

16 files changed

+98
-49
lines changed
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
{
2+
"problemMatcher": [
3+
{
4+
"owner": "markdownlint",
5+
"pattern": [
6+
{
7+
"regexp": "^([^:]*):(\\d+):?(\\d+)?\\s([\\w-\\/]*)\\s(.*)$",
8+
"file": 1,
9+
"line": 2,
10+
"column": 3,
11+
"code": 4,
12+
"message": 5
13+
}
14+
]
15+
}
16+
]
17+
}

.github/workflows/markdownlint.yml

+26
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
name: Markdownlint
2+
3+
on:
4+
pull_request:
5+
paths:
6+
- "**/*.md"
7+
- ".markdownlint.json"
8+
- ".github/workflows/markdownlint.yml"
9+
- ".github/workflows/markdownlint-problem-matcher.json"
10+
11+
jobs:
12+
lint:
13+
14+
runs-on: ubuntu-latest
15+
16+
steps:
17+
- uses: actions/checkout@v2
18+
- name: Use Node.js
19+
uses: actions/setup-node@v1
20+
with:
21+
node-version: 12.x
22+
- name: Run Markdownlint
23+
run: |
24+
echo "::add-matcher::.github/workflows/markdownlint-problem-matcher.json"
25+
npm i -g markdownlint-cli
26+
markdownlint "**/*.md"

.markdownlint.json

+6
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,6 @@
1+
{
2+
"default": false,
3+
"MD009": {
4+
"br_spaces": 0
5+
},
6+
}

docs/design/coreclr/jit/lsra-detail.md

+6-6
Original file line numberDiff line numberDiff line change
@@ -341,7 +341,7 @@ After LSRA, the graph has the following properties:
341341
- If a node has both `GTF_SPILL` and `GTF_SPILLED`, the tree node is reloaded prior to using
342342
it (`GTF_SPILLED`) and spilled after it is evaluated (`GTF_SPILL`).
343343

344-
- For normal variables, we can only have both `GTF_SPILL` and `GTF_SPILLED` on uses,
344+
- For normal variables, we can only have both `GTF_SPILL` and `GTF_SPILLED` on uses,
345345
since a def never needs to reload an old value. However, for EH-write-thru variable
346346
defs, this combination of flags has a special meaning. A def of an EH-write-thru variable is
347347
always written to the stack. However, if it is also marked `GTF_SPILLED` it remains live in the
@@ -714,7 +714,7 @@ LinearScanAllocation(List<RefPosition> refPositions)
714714

715715
- The actual resolution, for all edge types, is done by `resolveEdge()`.
716716
Based on the `ResolveType`, it either inserts the move at the top or bottom
717-
of the block.
717+
of the block.
718718
The algorithm for resolution can be found in [[2]](#[2]), though note
719719
that there is a typo: in the last 'if' statement, it should be
720720
"if b != loc(pred(b))" instead of "if b = loc(pred(b))":
@@ -1212,11 +1212,11 @@ term "EH Var" means a `lclVar` marked `lvLiveInOutOfHndlr`):
12121212

12131213
1. For determining whether an EH var should be a candidate for register allocation,
12141214
e.g. if the defs outweight the uses.
1215-
1215+
12161216
- An initial investigation might only consider an EH var as a register candidate if it has a single use. One complication is that we sometimes generate better code for a non-register-candidate local than one that is always spilled (we don't support `RegOptional` defs).
12171217
Thus, it would be better to identify *before* building intervals whether we should consider it a candidate, but the problem with that is that we don't necessarily know at that
12181218
time whether there is a single def. A possible approach:
1219-
1219+
12201220
- Add an `isSingleDef` flag to `Interval`.
12211221
- When allocating a use of a `writeThru` interval:
12221222
- If it's marked `isSingleDef`, allocate as usual.
@@ -1289,7 +1289,7 @@ Issue [\#9896](https://github.com/dotnet/runtime/issues/9896).
12891289

12901290
### Improving Preferencing
12911291

1292-
- Issues [#36454](https://github.com/dotnet/runtime/issues/36454),
1292+
- Issues [#36454](https://github.com/dotnet/runtime/issues/36454),
12931293
[#11260](https://github.com/dotnet/runtime/issues/11260) and
12941294
[#12945](https://github.com/dotnet/runtime/issues/12945)
12951295
involve preferencing for HW intrinsics.
@@ -1299,7 +1299,7 @@ Issue [\#9896](https://github.com/dotnet/runtime/issues/9896).
12991299

13001300
- Issue [#13090](https://github.com/dotnet/runtime/issues/13090) involves a case where anti-preferencing might be useful.
13011301

1302-
- Issue [#10296](https://github.com/dotnet/runtime/issues/10296) may also be related to preferencing, if it is still an issue.
1302+
- Issue [#10296](https://github.com/dotnet/runtime/issues/10296) may also be related to preferencing, if it is still an issue.
13031303

13041304
### Leveraging SSA form
13051305

docs/design/features/DynamicPgo.md

+4-4
Original file line numberDiff line numberDiff line change
@@ -18,7 +18,7 @@ You may already be familiar with the legacy .NET approach to profile feedback, c
1818

1919
## General Idea
2020

21-
Profile based optimization relies heavily on the principle that past behavior is a good predictor of future behavior. Thus observations about past program behavior can steer optimization decisions in profitable directions, so that future program execution is more efficient.
21+
Profile based optimization relies heavily on the principle that past behavior is a good predictor of future behavior. Thus observations about past program behavior can steer optimization decisions in profitable directions, so that future program execution is more efficient.
2222

2323
These observations may come from the recent past, perhaps even from the current execution of a program, or from the distant past. Observations can be from the same version of the program or from different versions.
2424

@@ -174,7 +174,7 @@ The classic paper on profile synthesis is [Ball-Larus](#BL93), which presents a
174174

175175
Profile synthesis is interesting even if instrumented or sampled profile data is available.
176176

177-
First, even in a jitted environment, the JIT may be asked to generate code for methods that have not yet executed, or that have for various reasons bypassed the stage of the system that runs instrumented versions. Profile synthesis can step in and provide provisional profile data.
177+
First, even in a jitted environment, the JIT may be asked to generate code for methods that have not yet executed, or that have for various reasons bypassed the stage of the system that runs instrumented versions. Profile synthesis can step in and provide provisional profile data.
178178

179179
Second, even if profile feedback is available, it may not be as representative as one might like. In particular parts of methods may not have been executed, or may have distorted profiles. Given the linearity of profile data, we can blend together the actual observations with a synthetic profile to produce a hybrid profile, so that our optimizations do not over-react to the actual profile (think of this as a kind of insurance policy: we want to make sure that if program behavior changes and we suddenly veer into un-profiled or thinly profiled areas, we don't fall off some kind of performance cliff). More on this below.
180180

@@ -601,7 +601,7 @@ We likely need to get through at least item 7 to meet our aspirational goals.
601601
4. Enable hot/cold splitting (runtime dependence) for jitted code
602602
5. Implement profile-based block layout (based on "TSP" algorithm above)
603603

604-
We likely need to get through at least item 3 to meet our aspirational goals.
604+
We likely need to get through at least item 3 to meet our aspirational goals.
605605

606606
-----
607607
#### Group 3: Profile Handling by Runtime and JIT
@@ -671,7 +671,7 @@ NET's legacy approach to PGO is called IBC (Instrumented Block Counts). It is av
671671

672672
A special instrumentation mode in crossgen/ngen instructs the JIT to add code to collect per-block counts and (for ngen) also instructs the runtime to track which ngen data structures are accessed at runtime, on a per-assembly basis. This information is externalized from the runtime and can be inspected and manipulated by IBCMerge. It is eventually packaged up and added back to the corresponding assembly, where it can be accessed by a subsequent "optimizing" run of crossgen/ngen. This run makes the per-block data available to the JIT and (for ngen) uses the internal runtime counters to rearrange the runtime data structures so they can be accessed more efficiently. Prejitting can also use the data to determine which methods should be prejitted (so called partial ngen).
673673

674-
The JIT (when prejitting) uses the IBC data much as we propose to use PGO data to optimize the generated code. It also splits methods into hot and cold portions. The runtime leverages IBC data to
674+
The JIT (when prejitting) uses the IBC data much as we propose to use PGO data to optimize the generated code. It also splits methods into hot and cold portions. The runtime leverages IBC data to
675675

676676
The main aspiration of IBC is to improve startup, by ensuring that the important parts of prejitted code and data are compact and can be fetched efficiently from disk.
677677

docs/design/specs/PortablePdb-Metadata.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -556,7 +556,7 @@ The meaning of the _flags_ byte:
556556

557557
The remaining bits are reserved for future use and have currently no meaning.
558558

559-
> The data can be used to find the reference in a file indexing service such as a symbol server.
559+
> The data can be used to find the reference in a file indexing service such as a symbol server.
560560
> For example, the [Simple Symbol Query Protocol](https://github.com/dotnet/symstore/blob/master/docs/specs/Simple_Symbol_Query_Protocol.md) uses a combination of _file-name_, _time-stamp_ and _file-size_ as a [key](https://github.com/dotnet/symstore/blob/master/docs/specs/SSQP_Key_Conventions.md#pe-timestamp-filesize).
561561
> Other services might use the MVID as it uniquely identifies the module.
562562

docs/infra/buildtriage.md

+6-6
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,10 @@
11
## Build Triage Rotation
22

3-
The responsibility of this role is triaging our rolling / official builds, filing issues to track broken tests, submitting changes to dotnet/runtime to work around issues (disabling a test, undoing a PR that broke the build).
3+
The responsibility of this role is triaging our rolling / official builds, filing issues to track broken tests, submitting changes to dotnet/runtime to work around issues (disabling a test, undoing a PR that broke the build).
44

55
In some cases this will require working with core-eng team when the issues are in Helix / Azure / Arcade. This person will also attend CI Council with the infra manager to provide updates on our reliability status.
66

7-
This directly impacts developer productivity and the need to promptly fix such breaks can span across time zones. Hence it will be the collective responsibility of the Scout pool to investigate such breaks.
7+
This directly impacts developer productivity and the need to promptly fix such breaks can span across time zones. Hence it will be the collective responsibility of the Scout pool to investigate such breaks.
88

99
This role will work on a rotation basis. There are six people in the role and each rotation will last for a calendar month.
1010

@@ -22,9 +22,9 @@ We have different dashboards for public (Rolling & PR Builds) and internal build
2222

2323
In addition to the dashboards, official build failure notifications are sent to the internal runtime infrastructure email alias.
2424

25-
For each of these mail notifications, a matching issue should exist (either in the dotnet/runtime repository or in dotnet/core-eng or dotnet/arcade). The person triaging build failures should reply to the email with a link to the issue to let everyone know it is triaged. This guarantees that we are following-up on infrastructure issues immediately. If a build failure's cause isn't trivial to identify, consider looping in dnceng.
25+
For each of these mail notifications, a matching issue should exist (either in the dotnet/runtime repository or in dotnet/core-eng or dotnet/arcade). The person triaging build failures should reply to the email with a link to the issue to let everyone know it is triaged. This guarantees that we are following-up on infrastructure issues immediately. If a build failure's cause isn't trivial to identify, consider looping in dnceng.
2626

27-
Tests are not run during the internal builds. Publishing and signing steps are run only during internal builds. Rolling builds run tests for the full matrix.
27+
Tests are not run during the internal builds. Publishing and signing steps are run only during internal builds. Rolling builds run tests for the full matrix.
2828

2929
For new issues, try to provide a [runfo](https://runfo.azurewebsites.net/) search which will make it easy to isolate repeated instances of that failure.
3030

@@ -34,7 +34,7 @@ Contact @jaredpar if you are having any trouble with runfo, site or utility.
3434

3535
## Ongoing Issues
3636

37-
All the issues causing the builds to fail should be marked with [`blocking-clean-ci`](https://github.com/dotnet/runtime/issues?q=is%3Aissue+is%3Aopen+label%3Ablocking-clean-ci) label.
37+
All the issues causing the builds to fail should be marked with [`blocking-clean-ci`](https://github.com/dotnet/runtime/issues?q=is%3Aissue+is%3Aopen+label%3Ablocking-clean-ci) label.
3838
Any issues causing build breaks in the official build should be marked with [`blocking-clean-official`](https://github.com/dotnet/runtime/issues?q=is%3Aissue+is%3Aopen+label%3Ablocking-clean-official).
3939
It helps in tracking issues effectively.
4040

@@ -50,7 +50,7 @@ The main meta-bug linking to currently tracked issues is [here](https://github.c
5050

5151
## Build Rotation for upcoming months
5252

53-
| Month | Alias |
53+
| Month | Alias |
5454
|-------|-----------|
5555
| September 2020 | @directhex |
5656
| October 2020 | @jkoritzinsky |

docs/pr-guide.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -84,7 +84,7 @@ If you have determined the failure is definitely not caused by changes in your P
8484
* In a follow-up Pull Request, disable the failing test(s) with the corresponding issue link tracking the disable.
8585
* Update the tracking issue with the label `disabled-test`.
8686
* For libraries tests add a [`[ActiveIssue(link)]`](https://github.com/dotnet/arcade/blob/master/src/Microsoft.DotNet.XUnitExtensions/src/Attributes/ActiveIssueAttribute.cs) attribute on the test method. You can narrow the disabling down to runtime variant, flavor, and platform. For an example see [File_AppendAllLinesAsync_Encoded](https://github.com/dotnet/runtime/blob/a259ec2e967d502f82163beba6b84da5319c5e08/src/libraries/System.IO.FileSystem/tests/File/AppendAsync.cs#L899)
87-
* For runtime tests found under `src/tests`, please edit [`issues.targets`](https://github.com/dotnet/runtime/blob/master/src/tests/issues.targets). There are several groups for different types of disable (mono vs. coreclr, different platforms, different scenarios). Add the folder containing the test and issue mimicking any of the samples in the file.
87+
* For runtime tests found under `src/tests`, please edit [`issues.targets`](https://github.com/dotnet/runtime/blob/master/src/tests/issues.targets). There are several groups for different types of disable (mono vs. coreclr, different platforms, different scenarios). Add the folder containing the test and issue mimicking any of the samples in the file.
8888

8989
There are plenty of possible bugs, e.g. race conditions, where a failure might highlight a real problem and it won't manifest again on a retry. Therefore these steps should be followed for every iteration of the PR build, e.g. before retrying/rebuilding.
9090

docs/project/glossary.md

+6-6
Original file line numberDiff line numberDiff line change
@@ -87,13 +87,13 @@ In this document, the following terms are used:
8787

8888
## .NET Runtimes
8989

90-
### .NET Core / .NET
90+
### .NET Core / .NET
9191

92-
.NET Core has been the name for the open source, cross-platform stack that
93-
ASP.NET Core and UWP applications are built on. For more details,
92+
.NET Core has been the name for the open source, cross-platform stack that
93+
ASP.NET Core and UWP applications are built on. For more details,
9494
read [Introducing .NET Core][introducing-net-core].
9595

96-
.NET Core has become future of the platform, and we refer to it just as .NET today.
96+
.NET Core has become future of the platform, and we refer to it just as .NET today.
9797
For more details, read [Introducing .NET 5][introducing-net-5].
9898

9999
### .NET Framework
@@ -143,13 +143,13 @@ Unity - the world's most popular game engine - is scripted by C#, powered by a c
143143
Originally, CoreCLR was the runtime of Silverlight and was designed to run on multiple
144144
platforms, specifically Windows and OS X.
145145

146-
Today, the [CoreCLR runtime](https://github.com/dotnet/runtime/tree/master/src/coreclr)
146+
Today, the [CoreCLR runtime](https://github.com/dotnet/runtime/tree/master/src/coreclr)
147147
is part of unified .NET platform. It is optimized for cloud (e.g. ASP.NET) and
148148
desktop (e.g. WinForms, WPF) scenarios.
149149

150150
## Ahead-Of-Time Compilation (AOT)
151151

152-
Most flavors of .NET runtime come with at least partial AOT compilation. A variety of AOT technologies
152+
Most flavors of .NET runtime come with at least partial AOT compilation. A variety of AOT technologies
153153
with unique characteristics were developed for .NET runtimes over the years.
154154

155155
### ReadyToRun

docs/workflow/using-dotnet-cli.md

+4-4
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11

22
# Using your .NET Runtime build with .NET SDK
33

4-
This walkthrough explains how to run your own app against your local build using only the .NET SDK.
4+
This walkthrough explains how to run your own app against your local build using only the .NET SDK.
55

66
Testing your local build this way is quite realistic - more like a real user. However it takes longer because you have to build the package. Each build can take 10 minutes altogether.
77

@@ -181,9 +181,9 @@ So the steps are:
181181

182182
```cmd
183183
build.cmd clr+libs+host+packs -c release
184-
```
184+
```
185185

186-
If you only changed libraries, `build.cmd libs+host+packs -c release` is a little faster; if you only changed clr, then `build.cmd clr+host+packs -c release`
186+
If you only changed libraries, `build.cmd libs+host+packs -c release` is a little faster; if you only changed clr, then `build.cmd clr+host+packs -c release`
187187

188188
### 2. Delete your local package cache
189189

@@ -197,4 +197,4 @@ rd /s /q c:\localcache
197197
dotnet publish
198198
```
199199

200-
Now your app will use your updated package.
200+
Now your app will use your updated package.

src/libraries/System.Diagnostics.EventLog/src/Messages/readme.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -4,11 +4,11 @@ For more information see https://docs.microsoft.com/en-us/windows/win32/eventlog
44

55
The design of the EventLog class is to allow for the registration of event sources without specifying message files.
66

7-
In the case an event source does not specify it's own message file, EventLog just provides a default message file
7+
In the case an event source does not specify it's own message file, EventLog just provides a default message file
88
with 64K message IDs all that just pass through the first insertion string. This allow the event source to still
99
use IDs for messages, but doesn't require the caller to actually pass a message file in order to achieve this.
1010

11-
The process for producing the message file requires mc.exe and rc.exe which do not work cross-platform, and they
11+
The process for producing the message file requires mc.exe and rc.exe which do not work cross-platform, and they
1212
require a VS install with C++ tools. Since these files rarely (if ever) change, we just use a manual process for
1313
updating this res file.
1414

src/libraries/System.Memory.Data/README.md

+3-3
Original file line numberDiff line numberDiff line change
@@ -2,21 +2,21 @@
22

33
## Binary Data
44
The `BinaryData` type provides a lightweight abstraction for a payload of bytes. It provides convenient helper methods to get out commonly used primitives, such as streams, strings, or bytes. The assumption when converting to and from string is that the encoding is UTF-8.
5-
5+
66
### Data ownership
77
When using the `byte[]` or `ReadOnlyMemory<byte>` constructors or methods, `BinaryData` will wrap the passed in bytes. When using streams, strings, or rich model types that will be serialized as Json, the data is converted into bytes and will be maintained by `BinaryData`. Thus, if you are using bytes to create your instance of `BinaryData`, changes to the underlying data will be reflected in `BinaryData` as it does not copy the bytes.
88

99
### Usage
1010
The main value of this type is its ability to easily convert from string to bytes to stream. This can greatly simplify API surface areas by exposing this type as opposed to numerous overloads or properties.
11-
11+
1212
To/From string:
1313
```C# Snippet:BinaryDataToFromString
1414
var data = new BinaryData("some data");
1515

1616
// ToString will decode the bytes using UTF-8
1717
Console.WriteLine(data.ToString()); // prints "some data"
1818
```
19-
19+
2020
To/From bytes:
2121
```C# Snippet:BinaryDataToFromBytes
2222
byte[] bytes = Encoding.UTF8.GetBytes("some data");

0 commit comments

Comments
 (0)