Merge pull request #4927 from dotnet/MasterToMain

.github/ISSUE_TEMPLATE/suggest-a-new-rule.md

@@ -7,7 +7,7 @@ assignees: ''
 
 ---
 
-<!-- Please refer to https://github.com/dotnet/roslyn-analyzers/blob/master/GuidelinesForNewRules.md -->
+<!-- Please refer to https://github.com/dotnet/roslyn-analyzers/blob/main/GuidelinesForNewRules.md -->
 
 ### Describe the problem you are trying to solve
 

.github/PULL_REQUEST_TEMPLATE.md

@@ -2,7 +2,7 @@
 
 Make sure you have read the contribution guidelines: 
 - https://docs.microsoft.com/contribute/dotnet/dotnet-contribute-code-analysis#contribute-docs-for-caxxxx-rules
-- https://github.com/dotnet/roslyn-analyzers/blob/master/GuidelinesForNewRules.md
+- https://github.com/dotnet/roslyn-analyzers/blob/main/GuidelinesForNewRules.md
 
 If your Pull Request is doing one of the following:
 
@@ -12,6 +12,6 @@ If your Pull Request is doing one of the following:
 
 Then, make sure to run `msbuild /t:pack /v:m` in the repository root; otherwise, the CI build will fail.
 
-Note: Consider merging the PR base branch (`2.9.x`, `master`, or `release/*`) into your branch before you run the pack command to reduce merge conflicts.
+Note: Consider merging the PR base branch (`2.9.x`, `main`, or `release/*`) into your branch before you run the pack command to reduce merge conflicts.
 
 -->

GuidelinesForNewRules.md

@@ -19,7 +19,7 @@
    You can refer to the [official documentation](https://docs.microsoft.com/visualstudio/code-quality/code-analysis-for-managed-code-warnings) for all released CA rules by rule category.
 
 4. Documentation requirements:
-   1. **New CA rule must be documented**: Each rule ID `CAxxxx` is automatically assigned the help link `https://docs.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/caxxxx`. The documentation for this page is populated from `caxxxx.md` file at [dotnet/docs quality-rules folder](https://github.com/dotnet/docs/tree/master/docs/fundamentals/code-analysis/quality-rules). For example, `CA1000` is documented at [ca1000.md](https://github.com/dotnet/docs/tree/master/docs/fundamentals/code-analysis/quality-rules/ca1000.md) file. Documenting a new rule is primarily ensuring a PR is sent to `dotnet/docs` repo to add `caxxxx.md` file for the new rule. Detailed steps are given below.
+   1. **New CA rule must be documented**: Each rule ID `CAxxxx` is automatically assigned the help link `https://docs.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/caxxxx`. The documentation for this page is populated from `caxxxx.md` file at [dotnet/docs quality-rules folder](https://github.com/dotnet/docs/tree/main/docs/fundamentals/code-analysis/quality-rules). For example, `CA1000` is documented at [ca1000.md](https://github.com/dotnet/docs/tree/main/docs/fundamentals/code-analysis/quality-rules/ca1000.md) file. Documenting a new rule is primarily ensuring a PR is sent to `dotnet/docs` repo to add `caxxxx.md` file for the new rule. Detailed steps are given below.
    2. **Documentation PR must be submitted within ONE WEEK of the rule implementation being merged**. Note that we will communicate this requirement on each PR contributing a new CA rule. We reserve the right to revert the rule implementation PR if this documentation requirement is not met.
 
 ## Guidelines for creating documentation PR

PostReleaseActivities.md

@@ -22,7 +22,7 @@ Please follow the below steps after publishing analyzer NuGet packages from this
 
 ## Steps to generate Release Notes
 
-1. Checkout the sources for the release branch locally. This would normally be the master branch.
+1. Checkout the sources for the release branch locally. This would normally be the main branch.
 2. Build.
 3. Ensure that nuget.exe is on path.
 4. Generate notes: Switch to the output directory, say `artifacts\bin\ReleaseNotesUtil\Debug\netcoreapp3.1` and execute `GenDiffNotes.cmd` to generate release notes.  Example command line for v2.9.4 to v2.9.5: `GenDiffNotes.cmd C:\scratch nuget.org 2.9.4 2.9.5`.

README.md

@@ -2,7 +2,7 @@
 
 |          |Windows Debug|Windows Release|Ubuntu Debug|Ubuntu Release|
 |:--------:|:-----------:|:-------------:|:----------:|:------------:|
-|**master**| [![Build Status](https://dev.azure.com/dnceng/public/_apis/build/status/dotnet/roslyn-analyzers/roslyn-analyzers-CI?branchName=master&jobName=Windows&configuration=Windows%20Debug&label=build)](https://dev.azure.com/dnceng/public/_build/latest?definitionId=457&branchName=master) [![codecov](https://codecov.io/gh/dotnet/roslyn-analyzers/branch/master/graph/badge.svg)](https://codecov.io/gh/dotnet/roslyn-analyzers) | [![Build Status](https://dev.azure.com/dnceng/public/_apis/build/status/dotnet/roslyn-analyzers/roslyn-analyzers-CI?branchName=master&jobName=Windows&configuration=Windows%20Release&label=build)](https://dev.azure.com/dnceng/public/_build/latest?definitionId=457&branchName=master) | [![Build Status](https://dev.azure.com/dnceng/public/_apis/build/status/dotnet/roslyn-analyzers/roslyn-analyzers-CI?branchName=master&jobName=Ubuntu&configuration=Ubuntu%20Debug&label=build)](https://dev.azure.com/dnceng/public/_build/latest?definitionId=457&branchName=master) | [![Build Status](https://dev.azure.com/dnceng/public/_apis/build/status/dotnet/roslyn-analyzers/roslyn-analyzers-CI?branchName=master&jobName=Ubuntu&configuration=Ubuntu%20Release&label=build)](https://dev.azure.com/dnceng/public/_build/latest?definitionId=457&branchName=master) |
+|**main**| [![Build Status](https://dev.azure.com/dnceng/public/_apis/build/status/dotnet/roslyn-analyzers/roslyn-analyzers-CI?branchName=main&jobName=Windows&configuration=Windows%20Debug&label=build)](https://dev.azure.com/dnceng/public/_build/latest?definitionId=457&branchName=main) [![codecov](https://codecov.io/gh/dotnet/roslyn-analyzers/branch/main/graph/badge.svg)](https://codecov.io/gh/dotnet/roslyn-analyzers) | [![Build Status](https://dev.azure.com/dnceng/public/_apis/build/status/dotnet/roslyn-analyzers/roslyn-analyzers-CI?branchName=main&jobName=Windows&configuration=Windows%20Release&label=build)](https://dev.azure.com/dnceng/public/_build/latest?definitionId=457&branchName=main) | [![Build Status](https://dev.azure.com/dnceng/public/_apis/build/status/dotnet/roslyn-analyzers/roslyn-analyzers-CI?branchName=main&jobName=Ubuntu&configuration=Ubuntu%20Debug&label=build)](https://dev.azure.com/dnceng/public/_build/latest?definitionId=457&branchName=main) | [![Build Status](https://dev.azure.com/dnceng/public/_apis/build/status/dotnet/roslyn-analyzers/roslyn-analyzers-CI?branchName=main&jobName=Ubuntu&configuration=Ubuntu%20Release&label=build)](https://dev.azure.com/dnceng/public/_build/latest?definitionId=457&branchName=main) |
 
 ## What is Roslyn?
 
@@ -130,7 +130,7 @@ Created by summer 2015 interns [Zoë Petard](https://github.com/zoepetard), [Jes
 
 The MetaCompilation Analyzer is an analyzer that functions as a tutorial to teach users how to write an analyzer. It uses diagnostics and code fixes to guide the user through the various steps required to create a simple analyzer. It is designed for novice analyzer developers who have some previous programming experience.
 
-For instructions on using this tutorial, see [Instructions](https://github.com/dotnet/roslyn-analyzers/blob/master/src/MetaCompilation.Analyzers/Core/ReadMe.md#instructions).
+For instructions on using this tutorial, see [Instructions](https://github.com/dotnet/roslyn-analyzers/blob/main/src/MetaCompilation.Analyzers/Core/ReadMe.md#instructions).
 
 ## Getting Started
 

azure-pipelines-microbuild.yml

@@ -1,6 +1,5 @@
 # Branches that trigger a build on commit
 trigger:
-  - master
   - main
   - release/*
   - 2.9.x

azure-pipelines.yml

@@ -1,13 +1,11 @@
 # Branches that trigger a build on commit
 trigger:
-- master
 - main
 - release/*
 - 2.9.x
 
 # Branch(es) that trigger(s) build(s) on PR
 pr:
-- master
 - main
 - release/*
 - 2.9.x

docs/Analyzer Configuration.md

@@ -208,7 +208,7 @@ Option Values: Names of null check validation methods (separated by `|`) that va
 Allowed method name formats:
 
   1. Method name only (includes all methods with the name, regardless of the containing type or namespace).
-  2. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/master/spec/documentation-comments.md#id-string-format)
+  2. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/main/spec/documentation-comments.md#id-string-format)
      with an optional `M:` prefix.
 
 Default Value: _None_
@@ -232,7 +232,7 @@ Option Values: Names of additional string formatting methods (separated by `|`).
 Allowed method name formats:
 
   1. Method name only (includes all methods with the name, regardless of the containing type or namespace).
-  2. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/master/spec/documentation-comments.md#id-string-format)
+  2. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/main/spec/documentation-comments.md#id-string-format)
      with an optional `M:` prefix.
 
 Default Value: _None_
@@ -315,9 +315,9 @@ Allowed symbol name formats:
 
   1. Symbol name (includes all symbols with the name, regardless of the containing type or namespace).
   2. Symbol name ending with a wildcard symbol (includes all symbols whose name starts with the given name, regardless of the containing type or namespace).
-  3. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/master/spec/documentation-comments.md#id-string-format).
+  3. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/main/spec/documentation-comments.md#id-string-format).
     Note that each symbol name requires a symbol kind prefix, such as `M:` prefix for methods, `T:` prefix for types, `N:` prefix for namespaces, etc.
-  4. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/master/spec/documentation-comments.md#id-string-format) and ending with the wildcard symbol.
+  4. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/main/spec/documentation-comments.md#id-string-format) and ending with the wildcard symbol.
     Note that each symbol name requires a symbol kind prefix, such as `M:` prefix for methods, `T:` prefix for types, `N:` prefix for namespaces, etc.
   5. `.ctor` for constructors and `.cctor` for static constructors.
 
@@ -346,8 +346,8 @@ Allowed symbol name formats:
 
   1. Type name only (includes all types with the name, regardless of the containing type or namespace).
   2. Type name only ending with the wildcard symbol (includes all types whose name starts with the given name, regardless of the containing type or namespace).
-  3. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/master/spec/documentation-comments.md#id-string-format) with an optional `T:` prefix.
-  4. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/master/spec/documentation-comments.md#id-string-format) with an optional `T:` prefix and ending with the wildcard symbol.
+  3. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/main/spec/documentation-comments.md#id-string-format) with an optional `T:` prefix.
+  4. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/main/spec/documentation-comments.md#id-string-format) with an optional `T:` prefix and ending with the wildcard symbol.
 
 Default Value: _None_
 
@@ -394,7 +394,7 @@ Option Values: Names of symbols (separated by `|`) that are disallowed in the co
 Allowed symbol name formats:
 
   1. Symbol name only (includes all symbols with the name, regardless of the containing type or namespace).
-  2. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/master/spec/documentation-comments.md#id-string-format).
+  2. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/main/spec/documentation-comments.md#id-string-format).
      Note that each symbol name requires a symbol kind prefix, such as `M:` prefix for methods, `T:` prefix for types, `N:` prefix for namespaces, etc.
   3. `.ctor` for constructors and `.cctor` for static constructors.
 
@@ -635,7 +635,7 @@ Option Values: List (separated by `|`) of type names with their required suffix
 Allowed type name formats:
 
   1. Type name only (includes all types with the name, regardless of the containing type or namespace).
-  2. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/master/spec/documentation-comments.md#id-string-format) with an optional `T:` prefix.
+  2. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/main/spec/documentation-comments.md#id-string-format) with an optional `T:` prefix.
 
 Default Value: _None_
 
@@ -657,7 +657,7 @@ Option Values: List (separated by `|`) of interface names with their required ge
 Allowed interface formats:
 
   1. Interface name only (includes all interfaces with the name, regardless of the containing type or namespace).
-  2. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/master/spec/documentation-comments.md#id-string-format) with an optional `T:` prefix.
+  2. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/main/spec/documentation-comments.md#id-string-format) with an optional `T:` prefix.
 
 Default Value: _None_
 
@@ -679,7 +679,7 @@ Allowed symbol name formats:
 
   1. Type or namespace name (includes all types with the name, regardless of the containing type or namespace and all types whose namespace contains the name).
   2. Type or namespace name ending with a wildcard symbol (includes all types whose name starts with the given name, regardless of the containing type or namespace and all types whose namespace contains the name).
-  3. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/master/spec/documentation-comments.md#id-string-format) with an optional `T:` prefix for types or `N:` prefix for namespaces.
+  3. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/main/spec/documentation-comments.md#id-string-format) with an optional `T:` prefix for types or `N:` prefix for namespaces.
   4. Fully qualified type or namespace name with an optional `T:` prefix for type or `N:` prefix for namespace and ending with the wildcard symbol (includes all types whose fully qualified name starts with the given suffix).
 
 Default Value: `N:System.*` (note that this value is always automatically added to the value provided)
@@ -731,7 +731,7 @@ Option Values: Names of additional methods (separated by `|`).
 Allowed method name formats:
 
   1. Method name only (includes all methods with the name, regardless of the containing type or namespace).
-  2. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/master/spec/documentation-comments.md#id-string-format)
+  2. Fully qualified names in the [symbol's documentation ID format](https://github.com/dotnet/csharplang/blob/main/spec/documentation-comments.md#id-string-format)
      with an optional `M:` prefix.
 
 Default Value: _None_

docs/Documenting your analyzers.md

@@ -8,7 +8,7 @@ We recommend that you provide reference documentation for each of your analyzers
 
     The rationale for this suggestion is that you might have other documents you want to put in your `docs` directory. Keeping the reference pages together in their own subdirectory makes them easier to distinguish from your other documentation. The more analyzer project authors that follow this convention, the easier it will be for analyzer users to find the documentation they need. It will also make it easier for tools that want to search,  aggregate, or otherwise process the documentation pages from multiple analyzer projects.  
 
-3. Make a copy of the [Rule reference page template](https://github.com/Microsoft/sarif-sdk/blob/master/docs/Rule%20reference%20page%20template.md) in your `docs/reference` directory, and name it according to the following convention:
+3. Make a copy of the [Rule reference page template](https://github.com/Microsoft/sarif-sdk/blob/main/docs/Rule%20reference%20page%20template.md) in your `docs/reference` directory, and name it according to the following convention:
 
     `<MessageId>_<Name>.md`
 
@@ -36,7 +36,7 @@ any facility your company might provide for registering URIs.
 your `DiagnosticDescriptor`  to the (preferably stable) URI you provided.
 
 **Note** Some analyzers produce diagnostics with more than one rule id.
-For example, the [`EquatableAnalyzer`](https://github.com/dotnet/roslyn-analyzers/blob/master/src/Microsoft.ApiDesignGuidelines.Analyzers/Core/EquatableAnalyzer.cs) in [`Microsoft.ApiDesignGuidelines.Analyzers`](https://github.com/dotnet/roslyn-analyzers/tree/master/src/Microsoft.ApiDesignGuidelines.Analyzers)
+For example, the [`EquatableAnalyzer`](https://github.com/dotnet/roslyn-analyzers/blob/main/src/Microsoft.ApiDesignGuidelines.Analyzers/Core/EquatableAnalyzer.cs) in [`Microsoft.ApiDesignGuidelines.Analyzers`](https://github.com/dotnet/roslyn-analyzers/tree/main/src/Microsoft.ApiDesignGuidelines.Analyzers)
 produces diagnostics with two rule ids:
 `CA1066` ("Implement IEquatable\<T> when overriding Object.Equals")
 and `CA1067` ("Override Object.Equals when implementing IEquatable\<T>").

docs/FxCopPort/Porting FxCop Rules to Roslyn.md

@@ -30,7 +30,7 @@ In the remainder of this document, we explain the principles we used to decide h
 
 ## Analyzer packages
 
-The list of all the rules that ship in VS, along with certain other FxCop/Roslyn rules that we know of, is captured in the file [RulesInventory.csv](https://github.com/dotnet/roslyn-analyzers/blob/master/docs/FxCopPort/RulesInventory.csv) file (which, thanks to GitHub, is searchable). That file also contains our proposed factoring of the analyzers (in the "Proposed Analyzer" column, which perhaps might have been better named "Proposed Analyzer Package").
+The list of all the rules that ship in VS, along with certain other FxCop/Roslyn rules that we know of, is captured in the file [RulesInventory.csv](https://github.com/dotnet/roslyn-analyzers/blob/main/docs/FxCopPort/RulesInventory.csv) file (which, thanks to GitHub, is searchable). That file also contains our proposed factoring of the analyzers (in the "Proposed Analyzer" column, which perhaps might have been better named "Proposed Analyzer Package").
 
 ### API analyzer packages