diff options
122 files changed, 230 insertions, 230 deletions
diff --git a/.github/ISSUE_TEMPLATE/02_api_proposal.md b/.github/ISSUE_TEMPLATE/02_api_proposal.md index 0e03fbdaf0b..d45db1eff4b 100644 --- a/.github/ISSUE_TEMPLATE/02_api_proposal.md +++ b/.github/ISSUE_TEMPLATE/02_api_proposal.md @@ -10,7 +10,7 @@ assignees: '' ## Background and Motivation <!-- -We welcome API proposals! We have a process to evaluate the value and shape of new API. There is an overview of our process [here](https://github.com/dotnet/runtime/blob/master/docs/project/api-review-process.md). This template will help us gather the information we need to start the review process. +We welcome API proposals! We have a process to evaluate the value and shape of new API. There is an overview of our process [here](https://github.com/dotnet/runtime/blob/main/docs/project/api-review-process.md). This template will help us gather the information we need to start the review process. First, please describe the purpose and value of the new API here. --> @@ -25,7 +25,7 @@ namespace System.Collections.Generic + public class HashSet<T> : ICollection<T>, ISet<T>, IReadOnlySet<T> { } ``` -You may find the [Framework Design Guidelines](https://github.com/dotnet/runtime/blob/master/docs/coding-guidelines/framework-design-guidelines-digest.md) helpful. +You may find the [Framework Design Guidelines](https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/framework-design-guidelines-digest.md) helpful. --> ## Usage Examples diff --git a/.github/PULL_REQUEST_TEMPLATE/servicing_pull_request_template.md b/.github/PULL_REQUEST_TEMPLATE/servicing_pull_request_template.md index ae585706a99..6fd461e6fc3 100644 --- a/.github/PULL_REQUEST_TEMPLATE/servicing_pull_request_template.md +++ b/.github/PULL_REQUEST_TEMPLATE/servicing_pull_request_template.md @@ -1,6 +1,6 @@ Fixes Issue <!-- Issue Number --> -Master PR <!-- Link to PR if any that fixed this in the master branch. --> +main PR <!-- Link to PR if any that fixed this in the main branch. --> # Description diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index fd80057e8f3..b5e98f8d909 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -48,7 +48,7 @@ We use and recommend the following workflow: - If your change adds a new API, follow the [API Review Process](docs/project/api-review-process.md). - Clearly state that you are going to take on implementing it, if that's the case. You can request that the issue be assigned to you. Note: The issue filer and the implementer don't have to be the same person. 2. Create a personal fork of the repository on GitHub (if you don't already have one). -3. In your fork, create a branch off of master (`git checkout -b mybranch`). +3. In your fork, create a branch off of main (`git checkout -b mybranch`). - Name the branch so that it clearly communicates your intentions, such as issue-123 or githubhandle-issue. - Branches are useful since they isolate your changes from incoming changes from upstream. They also enable you to create multiple PRs from the same fork. 4. Make and commit your changes to your branch. @@ -58,7 +58,7 @@ We use and recommend the following workflow: 6. Build the repository with your changes. - Make sure that the builds are clean. - Make sure that the tests are all passing, including your new tests. -7. Create a pull request (PR) against the dotnet/runtime repository's **master** branch. +7. Create a pull request (PR) against the dotnet/runtime repository's **main** branch. - State in the description what issue or improvement your change is addressing. - Check if all the Continuous Integration checks are passing. 8. Wait for feedback or approval of your changes from the [area owners](docs/area-owners.md). diff --git a/README.md b/README.md index 71c5ae53085..861ff943990 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # .NET Runtime -[](https://dnceng.visualstudio.com/public/_build/latest?definitionId=686&branchName=master) +[](https://dnceng.visualstudio.com/public/_build/latest?definitionId=686&branchName=main) [](https://gitter.im/dotnet/runtime) [](https://aka.ms/dotnet-discord) diff --git a/THIRD-PARTY-NOTICES.TXT b/THIRD-PARTY-NOTICES.TXT index 8dc999abbc7..b5571e67209 100644 --- a/THIRD-PARTY-NOTICES.TXT +++ b/THIRD-PARTY-NOTICES.TXT @@ -15,7 +15,7 @@ Copyright (c) .NET Foundation. All rights reserved. Licensed under the Apache License, Version 2.0. Available at -https://github.com/dotnet/aspnetcore/blob/master/LICENSE.txt +https://github.com/dotnet/aspnetcore/blob/main/LICENSE.txt License notice for Slicing-by-8 ------------------------------- diff --git a/docs/coding-guidelines/clr-code-guide.md b/docs/coding-guidelines/clr-code-guide.md index ece1900b3f4..0401300c73f 100644 --- a/docs/coding-guidelines/clr-code-guide.md +++ b/docs/coding-guidelines/clr-code-guide.md @@ -105,7 +105,7 @@ Rules can either be imposed by invariants or team policy. Team policy rules are not necessarily less important than invariants. For example, the rule to use [safemath.h][safemath.h] rather that coding your own integer overflow check is a policy rule. But because it deals with security, we'd probably treat it as higher priority than a very obscure (non-security) related bug. -[safemath.h]: https://github.com/dotnet/runtime/blob/master/src/coreclr/inc/safemath.h +[safemath.h]: https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/safemath.h One type of rule you won't find here are purely syntactic "code formatting" rules such as brace placement. While there is value in uniform stylistic conventions, we don't want to "lay down the law" on these to the extent that we do for the more semantic-oriented issues covered here. The rules included in this document are here because breaking them would do one of the following: @@ -238,8 +238,8 @@ The solution is the OBJECTHANDLE. OBJECTHANDLE allocates a location from special Handles are implemented through several layers of abstraction – the "official" interface for public use is the one described here and is exposed through [objecthandle.h][objecthandle.h]. Don't confuse this with [handletable.h][handletable.h] which contains the internals. The CreateHandle() api allocates a new location. ObjectFromHandle() dereferences the handle and returns an up-to-date reference. DestroyHandle() frees the location. -[objecthandle.h]: https://github.com/dotnet/runtime/blob/master/src/coreclr/gc/objecthandle.h -[handletable.h]: https://github.com/dotnet/runtime/blob/master/src/coreclr/gc/handletable.h +[objecthandle.h]: https://github.com/dotnet/runtime/blob/main/src/coreclr/gc/objecthandle.h +[handletable.h]: https://github.com/dotnet/runtime/blob/main/src/coreclr/gc/handletable.h The following code fragment shows how handles are used. In practice, of course, people use GCPROTECT rather than handles for situations this simple. @@ -551,7 +551,7 @@ First, look for a prebaked holder that does what you want. Some common ones are If no existing holder fits your need, make one. If it's your first holder, start by reading [src\inc\holder.h][holder.h]. Decide if you want a holder or a wrapper. If you don't do much with a resource except acquire and release it, use a holder. Otherwise, you want the wrapper since its overloaded operators make it much easier to replace the resource variable with the wrapper. -[holder.h]: https://github.com/dotnet/runtime/blob/master/src/coreclr/inc/holder.h +[holder.h]: https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/holder.h Instantiate the holder or wrapper template with the required parameters. You must supply the data type being managed, the RELEASE function, the default value for uninitialized constructions, the IS_NULL function and the ACQUIRE function. Unless you're implementing a critical section holder, you can probably supply a NOP for ACQUIRE . Most resources can't be meaningfully released and reacquired so it's easier to allocate the resource outside the holder and pass it in through its constructor. For convenience, [holder.h][holder.h] defines a DoNothing<Type> template that creates a NOP ACQUIRE function for any given resource type. There are also convenience templates for writing RELEASE functions. See [holder.h][holder.h] for their definitions and examples of their use. @@ -716,7 +716,7 @@ SString is the abstraction to use for unmanaged strings in CLR code. It is impor This section will provide an overview for SString. For specific details on methods and use, see the file [src\inc\sstring.h][sstring.h]. SString has been in use in our codebase for quite a few years now so examples of its use should be easy to find. -[sstring.h]: https://github.com/dotnet/runtime/blob/master/src/coreclr/inc/sstring.h +[sstring.h]: https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/sstring.h An SString object represents a Unicode string. It has its own buffer which it internally manages. The string buffer is typically not referenced directly by user code; instead the string is manipulated indirectly by methods defined on SString. Ultimately there are several ways to get at the raw string buffer if such functionality is needed to interface to existing APIs. But these should be used only when absolutely necessary. @@ -822,7 +822,7 @@ We used to assign levels manually, but this leads to problems when it comes time Instead we now record the explicit dependencies as a set of rules in the src\inc\CrstTypes.def file and use a tool to automatically assign compatible levels to each Crst type. See CrstTypes.def for a description of the rule syntax and other instructions for updating Crst types. -[crst.h]: https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/crst.h +[crst.h]: https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/crst.h ### <a name="2.6.3"></a>2.6.3 Creating Crsts @@ -1034,7 +1034,7 @@ Here are some immediate tips for working well with the managed-debugging service - GetFoo() - fails if a Foo does not exist. Being non-mutating, this should also be GC_NOTRIGGER. Non-mutating will also make it much easier to DAC-ize. This is what the debugger will call. - and GetOrCreateFoo() that is built around GetFoo(). The rest of the runtime can call this. - The debugger can then just call GetFoo(), and deal with the failure accordingly. -- If you add a new stub (or way to call managed code), make sure that you can source-level step-in (F11) it under the debugger. The debugger is not psychic. A source-level step-in needs to be able to go from the source-line before a call to the source-line after the call, or managed code developers will be very confused. If you make that call transition be a giant 500 line stub, you must cooperate with the debugger for it to know how to step-through it. (This is what StubManagers are all about. See [src\vm\stubmgr.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/stubmgr.h)). Try doing a step-in through your new codepath under the debugger. +- If you add a new stub (or way to call managed code), make sure that you can source-level step-in (F11) it under the debugger. The debugger is not psychic. A source-level step-in needs to be able to go from the source-line before a call to the source-line after the call, or managed code developers will be very confused. If you make that call transition be a giant 500 line stub, you must cooperate with the debugger for it to know how to step-through it. (This is what StubManagers are all about. See [src\vm\stubmgr.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/stubmgr.h)). Try doing a step-in through your new codepath under the debugger. - **Beware of timeouts** : The debugger may completely suspend your process at arbitrary points. In most cases, the debugger will do the right thing (and suspend your timeout too), but not always. For example, if you have some other process waiting for info from the debuggee, it [may hit a timeout](https://docs.microsoft.com/en-us/archive/blogs/jmstall/why-you-sometimes-get-a-bogus-contextswitchdeadlock-mda-under-the-debugger). - **Use CLR synchronization primitives (like Crst)**. In addition to all the reasons listed in the synchronization section, the CLR-aware primitives can cooperate with the debugging services. For example: - The debugger needs to know when threads are modifying sensitive data (which correlates to when the threads lock that data). @@ -1057,7 +1057,7 @@ Here are some immediate tips for working well with the managed-debugging service Because the CLR is ultimately compiled on several different platforms, we have to be careful about the primitive types which are used in our code. Some compilers can have slightly different declarations in standard header files, and different processor word sizes can require values to have different representations on different platforms. -Because of this, we have gathered definition all of the "blessed" CLR types in a single header file, [clrtypes.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/inc/clrtypes.h). In general, you should only use primitive types which are defined in this file. As an exception, you may use built-in primitive types like int and short when precision isn't particularly interesting. +Because of this, we have gathered definition all of the "blessed" CLR types in a single header file, [clrtypes.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/clrtypes.h). In general, you should only use primitive types which are defined in this file. As an exception, you may use built-in primitive types like int and short when precision isn't particularly interesting. The types are grouped into several categories. @@ -1133,7 +1133,7 @@ This item asserts that the thread is in a particular mode or declares that the f #### <a name="2.10.1.5"></a>2.10.1.5 LOADS_TYPE(_loadlevel_) -This item asserts that the function may invoke the loader and cause a type to loaded up to (and including) the indicated loadlevel. Valid load levels are taken from ClassLoadLevel enumerationin [classLoadLevel.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/classloadlevel.h). +This item asserts that the function may invoke the loader and cause a type to loaded up to (and including) the indicated loadlevel. Valid load levels are taken from ClassLoadLevel enumerationin [classLoadLevel.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/classloadlevel.h). The CLR asserts if any attempt is made to load a type past the current limit set by LOADS_TYPE. A call to any function that has a LOADS_TYPE contract is treated as an attempt to load a type up to that limit. @@ -1143,7 +1143,7 @@ These declare whether a function or callee takes any kind of EE or user lock: Cr In TLS we keep track of the current intent (whether to lock), and actual reality (what locks are actually taken). Enforcement occurs as follows: -[contract.h]: https://github.com/dotnet/runtime/blob/master/src/coreclr/inc/contract.h +[contract.h]: https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/contract.h - SCAN - A CANNOT_TAKE_LOCK function calling a CAN_TAKE_LOCK function is illegal (just like THROWS/NOTHROWS) @@ -1258,4 +1258,4 @@ At a high level, DAC is a technique to enable execution of CLR algorithms from o Various tools (most notably the debugger and SOS) rely on portions of the CLR code being properly "DACized". Writing code in this way can be tricky and error-prone. Use the following references for more details: -- The best documentation is in the code itself. See the large comments at the top of [src\inc\daccess.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/inc/daccess.h). +- The best documentation is in the code itself. See the large comments at the top of [src\inc\daccess.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/daccess.h). diff --git a/docs/coding-guidelines/clr-jit-coding-conventions.md b/docs/coding-guidelines/clr-jit-coding-conventions.md index 300ccfc914b..80c0602d9dc 100644 --- a/docs/coding-guidelines/clr-jit-coding-conventions.md +++ b/docs/coding-guidelines/clr-jit-coding-conventions.md @@ -16,7 +16,7 @@ Note that these conventions are different from the CLR C++ Coding Conventions, d > Note: the JIT currently doesn't follow some of these conventions very widely. The non-conformant code should be updated, eventually. -> Note: we now use jit-format to format our code. All changes it makes supersede the conventions in this doc. Please see the [jit-format documentation](https://github.com/dotnet/jitutils/blob/master/doc/formatting.md) for instructions on running jit-format. +> Note: we now use jit-format to format our code. All changes it makes supersede the conventions in this doc. Please see the [jit-format documentation](https://github.com/dotnet/jitutils/blob/main/doc/formatting.md) for instructions on running jit-format. # How to use this document diff --git a/docs/coding-guidelines/project-guidelines.md b/docs/coding-guidelines/project-guidelines.md index bb2e399ee3d..556c9ac6d9a 100644 --- a/docs/coding-guidelines/project-guidelines.md +++ b/docs/coding-guidelines/project-guidelines.md @@ -26,7 +26,7 @@ The following are the properties associated with each build pivot - `$(TargetOS) -> Windows | Linux | OSX | FreeBSD | [defaults to running OS when empty]` - `$(Configuration) -> Release | [defaults to Debug when empty]` - `$(TargetArchitecture) - x86 | x64 | arm | arm64 | [defaults to x64 when empty]` -- `$(RuntimeOS) - win7 | osx10.10 | ubuntu.14.04 | [any other RID OS+version] | [defaults to running OS when empty]` See [RIDs](https://github.com/dotnet/runtime/tree/master/src/libraries/Microsoft.NETCore.Platforms) for more info. +- `$(RuntimeOS) - win7 | osx10.10 | ubuntu.14.04 | [any other RID OS+version] | [defaults to running OS when empty]` See [RIDs](https://github.com/dotnet/runtime/tree/main/src/libraries/Microsoft.NETCore.Platforms) for more info. ## Aggregate build properties Each project will define a set of supported TargetFrameworks @@ -126,7 +126,7 @@ src\<Library Name>\tests - Contains the test code for a library ``` ## ref -Reference assemblies are required for any library that has more than one implementation or uses a facade. A reference assembly is a surface-area-only assembly that represents the public API of the library. To generate a reference assembly source file you can use the [GenAPI tool](https://www.nuget.org/packages/Microsoft.DotNet.BuildTools.GenAPI). If a library is a pure portable library with a single implementation it need not use a reference assembly at all. Instructions on updating reference sources can be found [here](https://github.com/dotnet/runtime/blob/master/docs/coding-guidelines/updating-ref-source.md). +Reference assemblies are required for any library that has more than one implementation or uses a facade. A reference assembly is a surface-area-only assembly that represents the public API of the library. To generate a reference assembly source file you can use the [GenAPI tool](https://www.nuget.org/packages/Microsoft.DotNet.BuildTools.GenAPI). If a library is a pure portable library with a single implementation it need not use a reference assembly at all. Instructions on updating reference sources can be found [here](https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/updating-ref-source.md). In the ref directory for the library there should be at most **one** `.csproj` that contains the latest API for the reference assembly for the library. That project can contain multiple entries in its `TargetFrameworks` property. Ref projects should use `<ProjectReference>` for its dependencies. diff --git a/docs/design/coreclr/botr/botr-faq.md b/docs/design/coreclr/botr/botr-faq.md index 79cd8114968..26560995af4 100644 --- a/docs/design/coreclr/botr/botr-faq.md +++ b/docs/design/coreclr/botr/botr-faq.md @@ -3,7 +3,7 @@ Book of the Runtime (BotR) FAQ # What is the BotR? -The [Book of the Runtime](https://github.com/dotnet/runtime/blob/master/docs/design/coreclr/botr/README.md) is a set of documents that describe components in the CLR and BCL. They are intended to focus more on architecture and invariants and not an annotated description of the codebase. +The [Book of the Runtime](https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/README.md) is a set of documents that describe components in the CLR and BCL. They are intended to focus more on architecture and invariants and not an annotated description of the codebase. It was originally created within Microsoft in ~ 2007, including this document. Developers were responsible to document their feature areas. This helped new devs joining the team and also helped share the product architecture across the team. diff --git a/docs/design/coreclr/botr/corelib.md b/docs/design/coreclr/botr/corelib.md index 6f2ced10c98..a0578c33bb9 100644 --- a/docs/design/coreclr/botr/corelib.md +++ b/docs/design/coreclr/botr/corelib.md @@ -36,7 +36,7 @@ To implement these, we need a way for the CLR to specify and optionally verify t The managed mechanism for calling into native code must also support the special managed calling convention used by `String`'s constructors, where the constructor allocates the memory used by the object (instead of the typical convention where the constructor is called after the GC allocates memory). -The CLR provides a [`mscorlib` binder](https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/binder.cpp) internally, providing a mapping between unmanaged types and fields to managed types and fields. The binder will look up and load classes and allows the calling of managed methods. It also performs simple verification to ensure the correctness of any layout information specified in both managed and native code. The binder ensures that the managed class attempting to load exists in mscorlib, has been loaded, and the field offsets are correct. It also needs the ability to differentiate between method overloads with different signatures. +The CLR provides a [`mscorlib` binder](https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/binder.cpp) internally, providing a mapping between unmanaged types and fields to managed types and fields. The binder will look up and load classes and allows the calling of managed methods. It also performs simple verification to ensure the correctness of any layout information specified in both managed and native code. The binder ensures that the managed class attempting to load exists in mscorlib, has been loaded, and the field offsets are correct. It also needs the ability to differentiate between method overloads with different signatures. # Calling from managed to native code @@ -70,7 +70,7 @@ The preferred types for QCall arguments are primitive types that are efficiently The pointers to common unmanaged EE structures should be wrapped into handle types. This is to make the managed implementation type safe and avoid falling into unsafe C# everywhere. See AssemblyHandle in [vm\qcall.h][qcall] for an example. -[qcall]: https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/qcall.h +[qcall]: https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/qcall.h Passing object references in and out of QCalls is done by wrapping a pointer to a local variable in a handle. It is intentionally cumbersome and should be avoided if reasonably possible. See the `StringHandleOnStack` in the example below. Returning objects, especially strings, from QCalls is the only common pattern where passing the raw objects is widely acceptable. (For reasoning on why this set of restrictions helps make QCalls less prone to GC holes, read the ["GC Holes, FCall, and QCall"](#gcholes) section below.) @@ -112,7 +112,7 @@ Do not replicate the comments into your actual QCall implementation. The QCall entrypoint has to be registered in tables in [vm\ecalllist.h][ecalllist] using `QCFuncEntry` macro. See ["Registering your QCall or FCall Method"](#register) below. -[ecalllist]: https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/ecalllist.h +[ecalllist]: https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/ecalllist.h ```C++ class FooNative @@ -173,7 +173,7 @@ FCalls allow more flexibility in terms of passing object references around, but FCalls require a lot of boilerplate code, too much to describe here. Refer to [fcall.h][fcall] for details. -[fcall]: https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/fcall.h +[fcall]: https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/fcall.h ### <a name="gcholes"></a> GC holes, FCall, and QCall @@ -193,7 +193,7 @@ The managed stack walker needs to be able to find its way from FCalls. It is rel Complex constructs like stack allocated objects with destructors or exception handling in the FCall implementation may confuse the epilog walker. This can lead to GC holes or crashes during stack walking. There is no comprehensive list of what constructs should be avoided to prevent this class of bugs. An FCall implementation that is fine one day may break with the next C++ compiler update. We depend on stress runs and code coverage to find bugs in this area. -Setting a breakpoint inside an FCall implementation may confuse the epilog walker. It leads to an "Invalid breakpoint in a helpermethod frame epilog" assert inside [vm\i386\gmsx86.cpp](https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/i386/gmsx86.cpp). +Setting a breakpoint inside an FCall implementation may confuse the epilog walker. It leads to an "Invalid breakpoint in a helpermethod frame epilog" assert inside [vm\i386\gmsx86.cpp](https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/i386/gmsx86.cpp). ### FCall example – managed @@ -287,7 +287,7 @@ The CLR provides a binder for this purpose. After you define your managed and na In [mscorlib.h][mscorlib.h], use macros ending in "_U" to describe a type, the name of fields in managed code, and the name of fields in a corresponding native data structure. Additionally, you can specify a list of methods, and reference them by name when you attempt to call them later. -[mscorlib.h]: https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/mscorlib.h +[mscorlib.h]: https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/mscorlib.h ``` C++ DEFINE_CLASS_U(SAFE_HANDLE, Interop, SafeHandle, SafeHandle) @@ -349,4 +349,4 @@ For QCalls, look in [qcall.h][qcall] for associated infrastructure, and [ecallli More general infrastructure and some native type definitions can be found in [object.h][object.h]. The binder uses `mscorlib.h` to associate managed and native classes. -[object.h]: https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/object.h +[object.h]: https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/object.h diff --git a/docs/design/coreclr/botr/dac-notes.md b/docs/design/coreclr/botr/dac-notes.md index 497da0616e8..2d2d1511ba7 100644 --- a/docs/design/coreclr/botr/dac-notes.md +++ b/docs/design/coreclr/botr/dac-notes.md @@ -54,7 +54,7 @@ Marshaling Specifics DAC marshaling works through a collection of typedefs, macros and templated types that generally have one meaning in DAC builds and a different meaning in non-DAC builds. You can find these declarations in [src\inc\daccess.h][daccess.h]. You will also find a long comment at the beginning of this file that explains the details necessary to write code that uses the DAC. -[daccess.h]: https://github.com/dotnet/runtime/blob/master/src/coreclr/inc/daccess.h +[daccess.h]: https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/daccess.h An example may be helpful in understanding how marshaling works. The common debugging scenario is represented in the following block diagram: @@ -139,8 +139,8 @@ Even better, in a DAC build, the DAC will automatically marshal variables, data The `GPTR` and `VPTR` macros are common enough to warrant special mention here. Both the way we use these and their external behavior is quite similar to `DPTR`s. Again, marshaling is automatic and transparent. The `VPTR` macro declares a marshaled pointer type for a class with virtual functions. This special macro is necessary because the virtual function table is essentially an implicit extra field. The DAC has to marshal this separately, since the function addresses are all target addresses that the DAC must convert to host addresses. Treating these classes in this way means that the DAC automatically instantiates the correct implementation class, making casts between base and derived types unnecessary. When you declare a `VPTR` type, you must also list it in [vptr_list.h][vptr_list.h]. `__GlobalPtr` types provide base functionality to marshal both global variables and static data members through the `GPTR`, `GVAL`, `SPTR` and `SVAL` macros. The implementation of global variables is almost identical to that of static fields (both use the `__GlobalPtr` class) and require the addition of an entry in [dacvars.h][dacvars.h]. The comments in [daccess.h][daccess.h] and [dacvars.h][dacvars.h] provide more details about declaring these types. -[dacvars.h]: https://github.com/dotnet/runtime/blob/master/src/coreclr/inc/dacvars.h -[vptr_list.h]: https://github.com/dotnet/runtime/blob/master/src/coreclr/inc/vptr_list.h +[dacvars.h]: https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/dacvars.h +[vptr_list.h]: https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/vptr_list.h Global and static values and pointers are interesting because they form the entry points to the target address space (all other uses of the DAC require you to have a target address already). Many of the globals in the runtime are already DACized. It occasionally becomes necessary to make a previously un-DACized (or a newly introduced) global available to the DAC. By using the appropriate macros and [dacvars.h][dacvars.h] entry, you enable a post-build step (DacTableGen.exe run by the build in ndp\clr\src\dacupdatedll) to save the address of the global (from clr.pdb) into a table that is embedded into mscordacwks.dll. The DAC uses this table at run-time to determine where to look in the target address space when the code accesses a global. @@ -205,7 +205,7 @@ When do you need to DACize? Whenever you add a new feature, you will need to consider its debuggability needs and DACize the code to support your feature. You must also ensure that any other changes, such as bug fixes or code clean-up, conform to the DAC rules when necessary. Otherwise, the changes will break the debugger or SOS. If you are simply modifying existing code (as opposed to implementing a new feature), you will generally be able to determine that you need to worry about the DAC when a function you modify includes a `SUPPORTS_DAC` contract. This contract has a few variants such as `SUPPORTS_DAC_WRAPPER` and `LEAF_DAC_CONTRACT`. You can find comments explaining the differences in [contract.h][contract.h]. If you see a number of DAC-specific types in the function, you should assume the code will run in DAC builds. -[contract.h]: https://github.com/dotnet/runtime/blob/master/src/coreclr/inc/contract.h +[contract.h]: https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/contract.h DACizing ensures that code in the engine will work correctly with the DAC. It is important to use the DAC correctly to marshal values from the target to the host. Target addresses used incorrectly from the host (or vice versa) may reference unmapped addresses. If addresses are mapped, the values will be completely unrelated to the values expected. As a result, DACizing mostly involves ensuring that we use `PTR` types for all values that the DAC needs to marshal. Another major task is to ensure that we do not allow invasive code to execute in DAC builds. In practice, this means that we must sometimes refactor code or add `DACCESS_COMPILE` preprocessor directives. We also want to be sure that we add the appropriate `SUPPORTS_DAC` contract. The use of this contract signals to developers that the function works with the DAC. This is important for two reasons: diff --git a/docs/design/coreclr/botr/exceptions.md b/docs/design/coreclr/botr/exceptions.md index 370663852cf..645e189ca81 100644 --- a/docs/design/coreclr/botr/exceptions.md +++ b/docs/design/coreclr/botr/exceptions.md @@ -162,7 +162,7 @@ Throwing an Exception in the CLR is generally a matter of calling COMPlusThrow ( < args > ) -There are a number of overloads, but the idea is to pass the "kind" of the exception to COMPlusThrow. The list of "kinds" is generated by a set of macros operating on [rexcep.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/rexcep.h), and the various "kinds" are kAmbiguousMatchException, kApplicationException, and so forth. Additional arguments (for the overloads) specify resources and substitution text. Generally, the right "kind" is selected by looking for other code that reports a similar error. +There are a number of overloads, but the idea is to pass the "kind" of the exception to COMPlusThrow. The list of "kinds" is generated by a set of macros operating on [rexcep.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/rexcep.h), and the various "kinds" are kAmbiguousMatchException, kApplicationException, and so forth. Additional arguments (for the overloads) specify resources and substitution text. Generally, the right "kind" is selected by looking for other code that reports a similar error. There are some pre-defined convenience variations: diff --git a/docs/design/coreclr/botr/garbage-collection.md b/docs/design/coreclr/botr/garbage-collection.md index 88325a99413..6f97fd3d0db 100644 --- a/docs/design/coreclr/botr/garbage-collection.md +++ b/docs/design/coreclr/botr/garbage-collection.md @@ -327,7 +327,7 @@ Given WKS GC with concurrent GC on (default case), the code flow for a backgroun Resources ========= -- [.NET CLR GC Implementation](https://raw.githubusercontent.com/dotnet/runtime/master/src/coreclr/gc/gc.cpp) +- [.NET CLR GC Implementation](https://raw.githubusercontent.com/dotnet/runtime/main/src/coreclr/gc/gc.cpp) - [The Garbage Collection Handbook: The Art of Automatic Memory Management](http://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795) - [Garbage collection (Wikipedia)](http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)) - [Pro .NET Memory Management](https://prodotnetmemory.com/) diff --git a/docs/design/coreclr/botr/guide-for-porting.md b/docs/design/coreclr/botr/guide-for-porting.md index fec15080c5a..e2aadcf518e 100644 --- a/docs/design/coreclr/botr/guide-for-porting.md +++ b/docs/design/coreclr/botr/guide-for-porting.md @@ -228,7 +228,7 @@ Notable components very machine specific paths. 4. The unwinder. The unwinder is used to unwind stacks on non-Windows platforms. - It is located in https://github.com/dotnet/runtime/tree/master/src/coreclr/unwinder. + It is located in https://github.com/dotnet/runtime/tree/main/src/coreclr/unwinder. 4. System.Private.CoreLib/System.Reflection. There is little to no architecture specific work here that is necessary for bringup. Nice-to-have work involves @@ -267,12 +267,12 @@ there are also architecture specific components. 4. jitsupport.cpp - Depending on how the features of the CPU are exposed, there may need to be code to call OS apis to gather information about CPU features. -5. pal arch directory - https://github.com/dotnet/runtime/tree/master/src/coreclr/pal/src/arch +5. pal arch directory - https://github.com/dotnet/runtime/tree/main/src/coreclr/pal/src/arch This directory primarily contains assembly stubs for architecture specific handling of signals and exceptions. In addition to the PAL source code, there is a comprehensive set of PAL tests located -in https://github.com/dotnet/runtime/tree/master/src/coreclr/pal/tests. +in https://github.com/dotnet/runtime/tree/main/src/coreclr/pal/tests. CLR VM ------ diff --git a/docs/design/coreclr/botr/method-descriptor.md b/docs/design/coreclr/botr/method-descriptor.md index e163a8ca31f..35fa91c8526 100644 --- a/docs/design/coreclr/botr/method-descriptor.md +++ b/docs/design/coreclr/botr/method-descriptor.md @@ -91,7 +91,7 @@ The slot is either in MethodTable or in MethodDesc itself. The location of the s The slot is stored in MethodTable for methods that require efficient lookup via slot index, e.g. virtual methods or methods on generic types. The MethodDesc contains the slot index to allow fast lookup of the entry point in this case. -Otherwise, the slot is part of the MethodDesc itself. This arrangement improves data locality and saves working set. Also, it is not even always possible to preallocate a slot in a MethodTable upfront for dynamically created MethodDescs, such as for methods added by Edit & Continue, instantiations of generic methods or [dynamic methods](https://github.com/dotnet/runtime/blob/master/src/coreclr/System.Private.CoreLib/src/System/Reflection/Emit/DynamicMethod.cs). +Otherwise, the slot is part of the MethodDesc itself. This arrangement improves data locality and saves working set. Also, it is not even always possible to preallocate a slot in a MethodTable upfront for dynamically created MethodDescs, such as for methods added by Edit & Continue, instantiations of generic methods or [dynamic methods](https://github.com/dotnet/runtime/blob/main/src/coreclr/System.Private.CoreLib/src/System/Reflection/Emit/DynamicMethod.cs). MethodDesc Chunks ----------------- diff --git a/docs/design/coreclr/botr/profilability.md b/docs/design/coreclr/botr/profilability.md index ed32066516c..d6207774a34 100644 --- a/docs/design/coreclr/botr/profilability.md +++ b/docs/design/coreclr/botr/profilability.md @@ -225,14 +225,14 @@ It's pretty straightforward where to go, to add or modify methods, and code insp corprof.idl ----------- -All profiling API interfaces and types are defined in [src\inc\corprof.idl](https://github.com/dotnet/runtime/blob/master/src/coreclr/inc/corprof.idl). Go here first to define your types and methods. +All profiling API interfaces and types are defined in [src\inc\corprof.idl](https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/corprof.idl). Go here first to define your types and methods. EEToProfInterfaceImpl.\* ----------------------- -Wrapper around the profiler's implementation of ICorProfilerCallback is located at [src\vm\EEToProfInterfaceImpl.\*](https://github.com/dotnet/runtime/tree/master/src/coreclr/vm). +Wrapper around the profiler's implementation of ICorProfilerCallback is located at [src\vm\EEToProfInterfaceImpl.\*](https://github.com/dotnet/runtime/tree/main/src/coreclr/vm). ProfToEEInterfaceImpl.\* ----------------------- -Implementation of ICorProfilerInfo is located at [src\vm\ProfToEEInterfaceImpl.\*](https://github.com/dotnet/runtime/tree/master/src/coreclr/vm). +Implementation of ICorProfilerInfo is located at [src\vm\ProfToEEInterfaceImpl.\*](https://github.com/dotnet/runtime/tree/main/src/coreclr/vm). diff --git a/docs/design/coreclr/botr/readytorun-format.md b/docs/design/coreclr/botr/readytorun-format.md index 10f2193d495..665e532c6d2 100644 --- a/docs/design/coreclr/botr/readytorun-format.md +++ b/docs/design/coreclr/botr/readytorun-format.md @@ -58,7 +58,7 @@ The limitations of the current format are: # Structures The structures and accompanying constants are defined in the [readytorun.h] -(https://github.com/dotnet/runtime/blob/master/src/coreclr/inc/readytorun.h) header file. +(https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/readytorun.h) header file. Basically the entire R2R executable image is addressed through the READYTORUN_HEADER singleton pointed to by the well-known export RTR_HEADER in the export section of the native executable envelope. diff --git a/docs/design/coreclr/botr/readytorun-overview.md b/docs/design/coreclr/botr/readytorun-overview.md index 98df58ef923..a405f4e9724 100644 --- a/docs/design/coreclr/botr/readytorun-overview.md +++ b/docs/design/coreclr/botr/readytorun-overview.md @@ -67,7 +67,7 @@ Some of this information can be omitted or stored in more efficient form, e.g.: Even for IL or unmanaged native code, there are limits to what compatible changes can be made. For example, deleting a public method is sure to be an incompatible change for any extern code using that method. -Since CIL already has a set of [compatibility rules](https://github.com/dotnet/runtime/blob/master/docs/coding-guidelines/breaking-changes.md), ideally the native format would have the same set of compatibility rules as CIL. Unfortunately, that is difficult to do efficiently in all cases. In those cases we have multiple choices: +Since CIL already has a set of [compatibility rules](https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/breaking-changes.md), ideally the native format would have the same set of compatibility rules as CIL. Unfortunately, that is difficult to do efficiently in all cases. In those cases we have multiple choices: 1. Change the compatibility rules to disallow some changes 2. Never generate native structures for the problematic cases (fall back to CIL techniques) diff --git a/docs/design/coreclr/botr/shared-generics.md b/docs/design/coreclr/botr/shared-generics.md index 0689b0d891d..9c346979f3d 100644 --- a/docs/design/coreclr/botr/shared-generics.md +++ b/docs/design/coreclr/botr/shared-generics.md @@ -111,7 +111,7 @@ When loading information from a slot that is still NULL, the generic code will c - `JIT_GenericHandleClass`: Used to lookup a value in a generic type dictionary. This helper is used by all instance methods on generic types. - `JIT_GenericHandleMethod`: Used to lookup a value in a generic method dictionary. This helper used by all generic methods, or non-generic static methods on generic types. -When generating shared generic code, the JIT knows which slots to use for the various lookups, and the kind of information contained in each slot using the help of the `DictionaryLayout` implementation ([genericdict.cpp](https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/genericdict.cpp)). +When generating shared generic code, the JIT knows which slots to use for the various lookups, and the kind of information contained in each slot using the help of the `DictionaryLayout` implementation ([genericdict.cpp](https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/genericdict.cpp)). ### Dictionary Layouts @@ -148,7 +148,7 @@ Before the dynamic dictionary expansion feature, dictionary layouts were organiz When a bucket gets filled with entries, we would just allocate a new `DictionaryLayout` bucket, and add it to the list. The problem however is that we couldn't resize the generic dictionaries of types or methods, because they are already allocated with a fixed size, and the JIT does not support generating instructions that could indirect into a linked-list of dictionaries. Given that limitation, we could only lookup a generic dictionary for a fixed number of values (the ones associated with the entries of the first `DictionaryLayout` bucket), and were forced to go through a slower runtime helper for additional lookups. -This was acceptable, until we introduced the [ReadyToRun](https://github.com/dotnet/runtime/blob/master/docs/design/coreclr/botr/readytorun-overview.md) and the Tiered Compilation technologies. Slots were getting assigned quickly when used by ReadyToRun code, and when the runtime decided re-jitted certain methods for better performance, it could not in some cases find any remaining "fast lookup slots", and was forced to generate code that goes through the slower runtime helpers. This ended up hurting performance in some scenarios, and a decision was made to not use the fast lookup slots for ReadyToRun code, and instead keep them reserved for re-jitted code. This decision however hurt the ReadyToRun performance, but it was a necessary compromise since we cared more about re-jitted code throughput over R2R throughput. +This was acceptable, until we introduced the [ReadyToRun](https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/readytorun-overview.md) and the Tiered Compilation technologies. Slots were getting assigned quickly when used by ReadyToRun code, and when the runtime decided re-jitted certain methods for better performance, it could not in some cases find any remaining "fast lookup slots", and was forced to generate code that goes through the slower runtime helpers. This ended up hurting performance in some scenarios, and a decision was made to not use the fast lookup slots for ReadyToRun code, and instead keep them reserved for re-jitted code. This decision however hurt the ReadyToRun performance, but it was a necessary compromise since we cared more about re-jitted code throughput over R2R throughput. For this reason, the dynamic dictionary expansion feature was introduced. @@ -165,7 +165,7 @@ The feature is simple in concept: change dictionary layouts from a linked list o The current implementation expands the dictionary layout and the actual dictionaries separately to keep things simple: - - Dictionary layouts are expanded when we are out of empty slots. See implementations of `DictionaryLayout::FindToken()` in [genericdict.cpp](https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/genericdict.cpp). + - Dictionary layouts are expanded when we are out of empty slots. See implementations of `DictionaryLayout::FindToken()` in [genericdict.cpp](https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/genericdict.cpp). - Instantiated type and method dictionaries are expanded lazily on demand whenever any code is attempting to read the value of a slot beyond the size of the dictionary of that type or method. This is done through a call to the helper functions mentioned previously (`JIT_GenericHandleClass` and `JIT_GenericHandleMethod`). The dictionary access codegen is equivalent to the following (both in JITted code and ReadyToRun code): @@ -184,7 +184,7 @@ else This size check is **not** done unconditionally every time we need to read a value from the dictionary, otherwise this would cause a noticeable performance regression. When a dictionary layout is first allocated, we keep track of the initial number of slots that were allocated, and **only** perform the size checks if we are attempting to read the value of a slot beyond those initial number of slots. -Dictionaries on types and methods are expanded by the `Dictionary::GetTypeDictionaryWithSizeCheck()` and `Dictionary::GetMethodDictionaryWithSizeCheck()` helper functions in [genericdict.cpp](https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/genericdict.cpp). +Dictionaries on types and methods are expanded by the `Dictionary::GetTypeDictionaryWithSizeCheck()` and `Dictionary::GetMethodDictionaryWithSizeCheck()` helper functions in [genericdict.cpp](https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/genericdict.cpp). One thing to note regarding types is that they can inherit dictionary pointers from their base types. This means that if we resize the generic dictionary on any given generic type, we will need to propagate the new dictionary pointer to all of its derived types. This propagation is also done in a lazy way whenever the code calls into the `JIT_GenericHandleWorker` helper function with a derived type MethodTable pointer. In that helper, if we find that the dictionary pointer on the base type has been updated, we copy it to the derived type. diff --git a/docs/design/coreclr/botr/stackwalking.md b/docs/design/coreclr/botr/stackwalking.md index 34870a04940..bbd4cbe666a 100644 --- a/docs/design/coreclr/botr/stackwalking.md +++ b/docs/design/coreclr/botr/stackwalking.md @@ -62,7 +62,7 @@ Essentially the stack walker, having decoded the current frame, always has two p When managed code calls into the unmanaged runtime one of several forms of transition Frame is often pushed by the unmanaged target method. This is needed both to record the register state of the calling managed method (so that the stack walker can resume virtual unwinding of managed frames once it has finished enumerating the unmanaged Frames) and in many cases because managed object references are passed as arguments to the unmanaged method and must be reported to the GC in the event of a garbage collection. -A full description of the available Frame types and their uses is beyond the scope of the document. Further details can be found in the [frames.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/frames.h) header file. +A full description of the available Frame types and their uses is beyond the scope of the document. Further details can be found in the [frames.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/frames.h) header file. # Stackwalker Interface @@ -72,11 +72,11 @@ The caller of this method provides three main inputs: 1. Some context indicating the starting point of the walk. This is either an initial register set (for instance if you've suspended the target thread and can call GetThreadContext() on it) or an initial Frame (in cases where you know the code in question is in runtime unmanaged code). Although most stack walks are made from the top of the stack it's possible to start lower down if you can determine the correct starting context. 2. A function pointer and associated context. The function provided is called by the stack walker for each interesting frame (in order from the newest to the oldest). The context value provided is passed to each invocation of the callback so that it can record or build up state during the walk. -3. Flags indicating what sort of frames should trigger a callback. This allows the caller to specify that only pure managed method frames should be reported for instance. For a full list see [threads.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/threads.h) (just above the declaration of StackWalkFramesEx()). +3. Flags indicating what sort of frames should trigger a callback. This allows the caller to specify that only pure managed method frames should be reported for instance. For a full list see [threads.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/threads.h) (just above the declaration of StackWalkFramesEx()). StackWalkFramesEx() returns an enum value that indicates whether the walk terminated normally (got to the stack base and ran out of methods to report), was aborted by one of the callbacks (the callbacks return an enum of the same type to the stack walk to control this) or suffered some other miscellaneous error. -Aside from the context value passed to StackWalkFramesEx(), stack callback functions are passed one other piece of context: the CrawlFrame. This class is defined in [stackwalk.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/stackwalk.h) and contains all sorts of context gathered as the stack walk proceeds. +Aside from the context value passed to StackWalkFramesEx(), stack callback functions are passed one other piece of context: the CrawlFrame. This class is defined in [stackwalk.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/stackwalk.h) and contains all sorts of context gathered as the stack walk proceeds. For instance the CrawlFrame indicates the MethodDesc* for managed frames and the Frame* for unmanaged Frames. It also provides the current register set inferred by virtually unwinding frames up to that point. diff --git a/docs/design/coreclr/botr/type-loader.md b/docs/design/coreclr/botr/type-loader.md index b193c3f15a2..b873d8541a0 100644 --- a/docs/design/coreclr/botr/type-loader.md +++ b/docs/design/coreclr/botr/type-loader.md @@ -166,7 +166,7 @@ These are valid types and apparently `A` depends on `B` and `B` depends on `A`. The loader initially creates the structure(s) representing the type and initializes them with data that can be obtained without loading other types. When this "no-dependencies" work is done, the structure(s) can be referred from other places, usually by sticking pointers to them into another structures. After that the loader progresses in incremental steps and fills the structure(s) with more and more information until it finally arrives at a fully loaded type. In the above example, the base types of `A` and `B` will be approximated by something that does not include the other type, and substituted by the real thing later. -The exact half-loaded state is described by the so-called load level, starting with CLASS\_LOAD\_BEGIN, ending with CLASS\_LOADED, and having a couple of intermediate levels in between. There are rich and useful comments about individual load levels in the [classloadlevel.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/classloadlevel.h) source file. Notice that although types can be saved in NGEN images, the representing structures cannot be simply mapped or blitted into memory and used without additional work called "restoring". The fact that a type came from an NGEN image and needs to be restored is also captured by its load level. +The exact half-loaded state is described by the so-called load level, starting with CLASS\_LOAD\_BEGIN, ending with CLASS\_LOADED, and having a couple of intermediate levels in between. There are rich and useful comments about individual load levels in the [classloadlevel.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/classloadlevel.h) source file. Notice that although types can be saved in NGEN images, the representing structures cannot be simply mapped or blitted into memory and used without additional work called "restoring". The fact that a type came from an NGEN image and needs to be restored is also captured by its load level. See [Design and Implementation of Generics for the .NET Common Language diff --git a/docs/design/coreclr/botr/virtual-stub-dispatch.md b/docs/design/coreclr/botr/virtual-stub-dispatch.md index 43f4f10a080..76a3f2d8242 100644 --- a/docs/design/coreclr/botr/virtual-stub-dispatch.md +++ b/docs/design/coreclr/botr/virtual-stub-dispatch.md @@ -183,6 +183,6 @@ As a result of disabling VSD for virtual instance method calls, every type has a Physical Architecture ===================== -For dispatch token and map implementation details, please see [clr/src/vm/contractImpl.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/contractimpl.h) and [clr/src/vm/contractImpl.cpp](https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/contractimpl.cpp). +For dispatch token and map implementation details, please see [clr/src/vm/contractImpl.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/contractimpl.h) and [clr/src/vm/contractImpl.cpp](https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/contractimpl.cpp). -For virtual stub dispatch implementation details, please see [clr/src/vm/virtualcallstub.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/virtualcallstub.h) and [clr/src/vm/virtualcallstub.cpp](https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/virtualcallstub.cpp). +For virtual stub dispatch implementation details, please see [clr/src/vm/virtualcallstub.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/virtualcallstub.h) and [clr/src/vm/virtualcallstub.cpp](https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/virtualcallstub.cpp). diff --git a/docs/design/coreclr/botr/xplat-minidump-generation.md b/docs/design/coreclr/botr/xplat-minidump-generation.md index 2e871f5f484..add26f58abd 100644 --- a/docs/design/coreclr/botr/xplat-minidump-generation.md +++ b/docs/design/coreclr/botr/xplat-minidump-generation.md @@ -12,7 +12,7 @@ Our solution at this time is to intercept any unhandled exception in the PAL lay We looked at the existing technologies like Breakpad and its derivatives (e.g.: an internal MS version called _msbreakpad_ from the SQL team....). Breakpad generates Windows minidumps but they are not compatible with existing tools like Windbg, etc. Msbreakpad even more so. There is a minidump to Linux core conversion utility but it seems like a wasted extra step. _Breakpad_ does allow the minidump to be generated in-process inside the signal handlers. It restricts the APIs to what was allowed in a "async" signal handler (like SIGSEGV) and has a small subset of the C++ runtime that was also similarly constrained. We also need to add the set of memory regions for the "managed" state which requires loading and using the _DAC_'s (*) enumerate memory interfaces. Loading modules is not allowed in an async signal handler but forking/execve is allowed so launching an utility that loads the _DAC_, enumerates the list of memory regions and writes the dump is the only reasonable option. It would also allow uploading the dump to a server too. -\* The _DAC_ is a special build of parts of the coreclr runtime that allows inspection of the runtime's managed state (stacks, variables, GC state heaps) out of context. One of the many interfaces it provides is [ICLRDataEnumMemoryRegions](https://github.com/dotnet/runtime/blob/master/src/coreclr/debug/daccess/dacimpl.h) which enumerates all the managed state a minidump would require to enable a fruitful debugging experience. +\* The _DAC_ is a special build of parts of the coreclr runtime that allows inspection of the runtime's managed state (stacks, variables, GC state heaps) out of context. One of the many interfaces it provides is [ICLRDataEnumMemoryRegions](https://github.com/dotnet/runtime/blob/main/src/coreclr/debug/daccess/dacimpl.h) which enumerates all the managed state a minidump would require to enable a fruitful debugging experience. _Breakpad_ could have still been used out of context in the generation utility but there seemed no value to their Windows-like minidump format when it would have to be converted to the native Linux core format away because in most scenarios using the platform tools like _lldb_ is necessary. It also adds a coreclr build dependency on Google's _Breakpad_ or SQL's _msbreakpad_ source repo. The only advantage is that the breakpad minidumps may be a little smaller because minidumps memory regions are byte granule and Linux core memory regions need to be page granule. @@ -20,7 +20,7 @@ _Breakpad_ could have still been used out of context in the generation utility b ### Linux ### -Core dump generation is triggered anytime coreclr is going to abort (via [PROCAbort()](https://github.com/dotnet/runtime/blob/master/src/coreclr/pal/src/include/pal/process.h)) the process because of an unhandled managed exception or an async signal like SIGSEGV, SIGILL, SIGFPE, etc. The _createdump_ utility is located in the same directory as libcoreclr.so and is launched with fork/execve. The child _createdump_ process is given permission to ptrace and access to the various special /proc files of the crashing process which waits until _createdump_ finishes. +Core dump generation is triggered anytime coreclr is going to abort (via [PROCAbort()](https://github.com/dotnet/runtime/blob/main/src/coreclr/pal/src/include/pal/process.h)) the process because of an unhandled managed exception or an async signal like SIGSEGV, SIGILL, SIGFPE, etc. The _createdump_ utility is located in the same directory as libcoreclr.so and is launched with fork/execve. The child _createdump_ process is given permission to ptrace and access to the various special /proc files of the crashing process which waits until _createdump_ finishes. The _createdump_ utility starts by using ptrace to enumerate and suspend all the threads in the target process. The process and thread info (status, registers, etc.) is gathered. The auxv entries and _DSO_ info is enumerated. _DSO_ is the in memory data structures that described the shared modules loaded by the target. This memory is needed in the dump by gdb and lldb to enumerate the shared modules loaded and access their symbols. The module memory mappings are gathered from /proc/$pid/maps. None of the program or shared modules memory regions are explicitly added to dump's memory regions. The _DAC_ is loaded and the enumerate memory region interfaces are used to build the memory regions list just like on Windows. The threads stacks and one page of code around the IP are added. The byte sized regions are rounded up to pages and then combined into contiguous regions. diff --git a/docs/design/coreclr/jit/GuardedDevirtualization.md b/docs/design/coreclr/jit/GuardedDevirtualization.md index 84eeaa085f7..4c9f7689693 100644 --- a/docs/design/coreclr/jit/GuardedDevirtualization.md +++ b/docs/design/coreclr/jit/GuardedDevirtualization.md @@ -242,7 +242,7 @@ This is something we'll look into further. ### Interface Calls: The Two Class Case Interface calls on the CLR are implemented via [Virtual Stub Dispatch]( -https://github.com/dotnet/runtime/blob/master/docs/design/coreclr/botr/virtual-stub-dispatch.md +https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/virtual-stub-dispatch.md ) (aka VSD). Calls are made through an indirection cell that initially points at a lookup stub. On the first call, the interface target is identified from the object's method table and the lookup stub is replaced with a dispatch stub that diff --git a/docs/design/coreclr/jit/JitOptimizerPlanningGuide.md b/docs/design/coreclr/jit/JitOptimizerPlanningGuide.md index 598c3e25213..3132147e3bd 100644 --- a/docs/design/coreclr/jit/JitOptimizerPlanningGuide.md +++ b/docs/design/coreclr/jit/JitOptimizerPlanningGuide.md @@ -34,7 +34,7 @@ due to a few well-known issues: optimization change when it is eventually merged. Source/library/runtime changes are in play for TechEmpower and Benchmarks Game both. -Compiler micro-benchmarks (like those in our [test tree](https://github.com/dotnet/runtime/tree/master/src/tests/JIT/Performance/CodeQuality)) +Compiler micro-benchmarks (like those in our [test tree](https://github.com/dotnet/runtime/tree/main/src/tests/JIT/Performance/CodeQuality)) don't share these issues, and adding them as optimizations are implemented is critical for validation and regression prevention; however, micro-benchmarks often aren't as representative of real-world code, and therefore not as diff --git a/docs/design/coreclr/jit/ryujit-overview.md b/docs/design/coreclr/jit/ryujit-overview.md index 110fa5cbe18..192c738f2df 100644 --- a/docs/design/coreclr/jit/ryujit-overview.md +++ b/docs/design/coreclr/jit/ryujit-overview.md @@ -25,9 +25,9 @@ Depending upon the configuration, the EE and JIT may reside in the same or diffe implements the JIT side of the JIT/EE interfaces: * `ICorJitCompiler` – this is the interface that the JIT compiler implements. This interface is defined in -[src/inc/corjit.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/inc/corjit.h) +[src/inc/corjit.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/corjit.h) and its implementation is in -[src/jit/ee_il_dll.cpp](https://github.com/dotnet/runtime/blob/master/src/coreclr/jit/ee_il_dll.cpp). +[src/jit/ee_il_dll.cpp](https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/ee_il_dll.cpp). The following are the key methods on this interface: * `compileMethod` is the main entry point for the JIT. The EE passes it a `ICorJitInfo` object, and the "info" containing the IL, the method header, and various other useful tidbits. @@ -38,9 +38,9 @@ The following are the key methods on this interface: * `ICorJitInfo` – this is the interface that the EE implements. It has many methods defined on it that allow the JIT to look up metadata tokens, traverse type signatures, compute field and vtable offsets, find method entry points, construct string literals, etc. This bulk of this interface is inherited from `ICorDynamicInfo` which is defined in -[src/inc/corinfo.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/inc/corinfo.h). The implementation +[src/inc/corinfo.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/corinfo.h). The implementation is defined in -[src/vm/jitinterface.cpp](https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/jitinterface.cpp). +[src/vm/jitinterface.cpp](https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/jitinterface.cpp). # Internal Representation (IR) @@ -131,7 +131,7 @@ bit vectors. ### Example of Post-Import IR For this snippet of code (extracted from -[src/tests/JIT/CodeGenBringUpTests/DblRoots.cs](https://github.com/dotnet/runtime/blob/master/src/tests/JIT/CodeGenBringUpTests/DblRoots.cs)), with `COMPlus_TieredCompilation=0` and using the DblRoots_ro.csproj project to compile it: +[src/tests/JIT/CodeGenBringUpTests/DblRoots.cs](https://github.com/dotnet/runtime/blob/main/src/tests/JIT/CodeGenBringUpTests/DblRoots.cs)), with `COMPlus_TieredCompilation=0` and using the DblRoots_ro.csproj project to compile it: r1 = (-b + Math.Sqrt(b*b - 4*a*c))/(2*a); @@ -698,11 +698,11 @@ at points where accurate counts are valuable. Currently this happens before and ## Instruction encoding Instruction encoding is performed by the emitter -([emit.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/jit/emit.h)), using the +([emit.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/emit.h)), using the `insGroup`/`instrDesc` representation. The code generator calls methods on the emitter to construct `instrDescs`. The encodings information is captured in the following: -* The "instruction" enumeration itemizes the different instructions available on each target, and is used as an index into the various encoding tables (e.g. `instInfo[]`, `emitInsModeFmtTab[]`) generated from the `instrs{tgt}.h` (e.g., [instrsxarch.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/jit/instrsxarch.h)). +* The "instruction" enumeration itemizes the different instructions available on each target, and is used as an index into the various encoding tables (e.g. `instInfo[]`, `emitInsModeFmtTab[]`) generated from the `instrs{tgt}.h` (e.g., [instrsxarch.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/instrsxarch.h)). * The skeleton encodings are contained in the tables, and then there are methods on the emitter that handle the special encoding constraints for the various instructions, addressing modes, register types, etc. ## GC Info @@ -713,10 +713,10 @@ Reporting of live GC references is done in two ways: * For lclVars with tracked lifetimes, or for expression involving GC references, we report the range over which the reference is live. This is done by the emitter, which adds this information to the instruction group, and which terminates instruction groups when the GC info changes. The tracking of GC reference lifetimes is done via the `GCInfo` class in the JIT. It is declared in -[src/jit/jitgcinfo.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/jit/jitgcinfo.h) (to +[src/jit/jitgcinfo.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/jitgcinfo.h) (to differentiate it from -[src/inc/gcinfo.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/inc/gcinfo.h)), and implemented in -[src/jit/gcinfo.cpp](https://github.com/dotnet/runtime/blob/master/src/coreclr/jit/gcinfo.cpp). +[src/inc/gcinfo.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/gcinfo.h)), and implemented in +[src/jit/gcinfo.cpp](https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/gcinfo.cpp). In a JitDump, the generated GC info can be seen following the "In gcInfoBlockHdrSave()" line. @@ -729,15 +729,15 @@ Debug info consists primarily of two types of information in the JIT: * the `gtLclILoffs` on lclVar references (`GenTreeLclVar`) * The IL offsets are captured during CodeGen by calling `CodeGen::genIPmappingAdd()`, and then written to debug tables by `CodeGen::genIPmappingGen()`. * Mapping of user locals to location (register or stack). This is accomplished via: - * Struct `siVarLoc` (in [compiler.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/jit/compiler.h)) captures the location - * `VarScopeDsc` ([compiler.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/jit/compiler.h)) captures the live range of a local variable in a given location. + * Struct `siVarLoc` (in [compiler.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/compiler.h)) captures the location + * `VarScopeDsc` ([compiler.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/compiler.h)) captures the live range of a local variable in a given location. ## Exception handling Exception handling information is captured in an `EHblkDsc` for each exception handling region. Each region includes the first and last blocks of the try and handler regions, exception type, enclosing region, among other things. Look -at [jiteh.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/jit/jiteh.h) and -[jiteh.cpp](https://github.com/dotnet/runtime/blob/master/src/coreclr/jit/jiteh.cpp), especially, for details. +at [jiteh.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/jiteh.h) and +[jiteh.cpp](https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/jiteh.cpp), especially, for details. Look at `Compiler::fgVerifyHandlerTab()` to see how the exception table constraints are verified. # Reading a JitDump @@ -838,7 +838,7 @@ STMT00000 (IL 0x010... ???) Tree nodes are identified by their `gtTreeID`. This field only exists in DEBUG builds, but is quite useful for debugging, since all tree nodes are created from the routine `gtNewNode` (in -[src/jit/gentree.cpp](https://github.com/dotnet/runtime/blob/master/src/coreclr/jit/gentree.cpp)). If you find a +[src/jit/gentree.cpp](https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/gentree.cpp)). If you find a bad tree and wish to understand how it got corrupted, you can place a conditional breakpoint at the end of `gtNewNode` to see when it is created, and then a data breakpoint on the field that you believe is corrupted. diff --git a/docs/design/coreclr/jit/ryujit-tutorial.md b/docs/design/coreclr/jit/ryujit-tutorial.md index 017a7f14861..3fa6dea3981 100644 --- a/docs/design/coreclr/jit/ryujit-tutorial.md +++ b/docs/design/coreclr/jit/ryujit-tutorial.md @@ -6,7 +6,7 @@ - An implementation of the Common Language Infrastructure [ECMA 335] - Supports multiple languages, including C#, F# and VB - RyuJIT is the "next generation" just in time compiler for .NET -- Sources are at https://github.com/dotnet/runtime/tree/master/src/coreclr/jit +- Sources are at https://github.com/dotnet/runtime/tree/main/src/coreclr/jit #### Notes For context, the .NET runtime has been around since about the turn of the millennium. It is a virtual machine that supports the execution of a number of languages, primarily C#, Visual Basic, and F#. diff --git a/docs/design/coreclr/jit/viewing-jit-dumps.md b/docs/design/coreclr/jit/viewing-jit-dumps.md index 41cc479d411..cef68fdac51 100644 --- a/docs/design/coreclr/jit/viewing-jit-dumps.md +++ b/docs/design/coreclr/jit/viewing-jit-dumps.md @@ -11,7 +11,7 @@ The first thing to do is setup the .NET Core app we want to dump. Here are the s * Cd into `src/coreclr` * Perform a release build of the runtime by passing `release` to the build command. You don't need to build tests, so you can pass `skiptests` to the build command to make it faster. Note: the release build can be skipped, but in order to see optimized code of the core library it is needed. * Perform a debug build of the runtime. Tests aren't needed as in the release build, so you can pass `skiptests` to the build command. Note: the debug build is necessary, so that the JIT recognizes the configuration knobs. -* Install the (latest) [.NET CLI](https://github.com/dotnet/runtime/blob/master/docs/project/dogfooding.md), which we'll use to compile/publish our app. +* Install the (latest) [.NET CLI](https://github.com/dotnet/runtime/blob/main/docs/project/dogfooding.md), which we'll use to compile/publish our app. * `cd` to where you want your app to be placed, and run `dotnet new console`. * Modify your `csproj` file so that it contains a RID (runtime ID) corresponding to the OS you're using in the `<RuntimeIdentifier>` tag. For example, for Windows 10 x64 machine, the project file is: diff --git a/docs/design/features/COM-activation.md b/docs/design/features/COM-activation.md index 409d950f045..4cb22c28aa0 100644 --- a/docs/design/features/COM-activation.md +++ b/docs/design/features/COM-activation.md @@ -49,7 +49,7 @@ The above registration is typically done with the [`RegAsm.exe`](https://docs.mi In .NET Core, our intent will be to avoid a system wide shim library. This decision may add additional cost for deployment scenarios, but will reduce servicing and engineering costs by making deployment more explicit and less magic. -The current .NET Core hosting solutions are described in detail at [Documentation/design-docs/host-components.md](https://github.com/dotnet/runtime/tree/master/docs/design/features/host-components.md). Along with the existing hosts an additional customizable COM activation host library (`comhost.dll`) will be added. This library (henceforth identified as 'shim') will export the required functions for COM class activation and registration and act in a way similar to .NET Framework's `mscoree.dll`. +The current .NET Core hosting solutions are described in detail at [Documentation/design-docs/host-components.md](https://github.com/dotnet/runtime/tree/main/docs/design/features/host-components.md). Along with the existing hosts an additional customizable COM activation host library (`comhost.dll`) will be added. This library (henceforth identified as 'shim') will export the required functions for COM class activation and registration and act in a way similar to .NET Framework's `mscoree.dll`. >[`HRESULT DllGetClassObject(REFCLSID rclsid, REFIID riid, LPVOID *ppv);`](https://docs.microsoft.com/windows/desktop/api/combaseapi/nf-combaseapi-dllgetclassobject) diff --git a/docs/design/features/DynamicPgo.md b/docs/design/features/DynamicPgo.md index bac55ba6d7b..464e87950cb 100644 --- a/docs/design/features/DynamicPgo.md +++ b/docs/design/features/DynamicPgo.md @@ -144,7 +144,7 @@ The implementation for TieredPGO was intentionally kept simple (in part to allow If we want to externalize data for offline analysis or to feed into a subsequent run of the program, we also need to produce some keying data so that the per-method data can be matched up properly later on. -This is surprisingly challenging in .NET as there's not a strong external notion of method identity from one run to the next. We currently rely on token, hash, and il size as keys. Note things like the multi-core JIT must solve similar problems. We will leverage David Wrighton's [dotnet-pgo](https://github.com/dotnet/runtime/blob/master/src/coreclr/tools/dotnet-pgo/dotnet-pgo-experiment.md) work here. +This is surprisingly challenging in .NET as there's not a strong external notion of method identity from one run to the next. We currently rely on token, hash, and il size as keys. Note things like the multi-core JIT must solve similar problems. We will leverage David Wrighton's [dotnet-pgo](https://github.com/dotnet/runtime/blob/main/src/coreclr/tools/dotnet-pgo/dotnet-pgo-experiment.md) work here. We may also wish to externalize flow graphs to allow offline analysis or to allow some kind of fuzzy matching of old profile data in a new version of the program (this is done by MSVC for example). diff --git a/docs/design/features/assemblyloadcontext.md b/docs/design/features/assemblyloadcontext.md index edf0d2fe20c..7e3d5584bd6 100644 --- a/docs/design/features/assemblyloadcontext.md +++ b/docs/design/features/assemblyloadcontext.md @@ -2,7 +2,7 @@ This concept is not new to .NET Core but has existed since the days of .NET Framework (see [this](https://blogs.msdn.microsoft.com/suzcook/2003/05/29/choosing-a-binding-context/) for details) where it operated behind the scenes and not exposed for the developer to interact with, aside from loading your assembly in one based upon the API used to perform the load. -In .NET Core, we have exposed a [managed API surface](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Runtime.Loader/ref/System.Runtime.Loader.cs) that developers can use to interact with it - to inspect loaded assemblies or create their own **LoadContext** instance. Here are some of the scenarios that motivated this work: +In .NET Core, we have exposed a [managed API surface](https://github.com/dotnet/runtime/blob/main/src/libraries/System.Runtime.Loader/ref/System.Runtime.Loader.cs) that developers can use to interact with it - to inspect loaded assemblies or create their own **LoadContext** instance. Here are some of the scenarios that motivated this work: * Ability to load multiple versions of the same assembly within a given process (e.g. for plugin frameworks) * Ability to load assemblies explicitly in a context isolated from that of the application. @@ -48,15 +48,15 @@ If the *Default LoadContext* fallback also did not resolve the load (or was not * **System.Private.CoreLib.dll** is only loaded once, and into the **Default LoadContext**, during the .NET Runtime startup as it is a logical extension of the same. It cannot be loaded into **Custom LoadContext**. * Currently, custom **LoadContext** cannot be unloaded once created. This is a feature we are looking into for a future release. -* If an attempt is made to load a [Ready-To-Run (R2R)](https://github.com/dotnet/runtime/blob/master/docs/design/coreclr/botr/readytorun-overview.md) image from the same location in multiple load context's, then precompiled code can only be used from the first image that got loaded. The subsequent images will have their code JITted. This happens because subsequent loading binaries from the same location results in OS mapping them to the same memory as the previous one was mapped to and thus, could corrupt internal state information required for use precompiled code. +* If an attempt is made to load a [Ready-To-Run (R2R)](https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/readytorun-overview.md) image from the same location in multiple load context's, then precompiled code can only be used from the first image that got loaded. The subsequent images will have their code JITted. This happens because subsequent loading binaries from the same location results in OS mapping them to the same memory as the previous one was mapped to and thus, could corrupt internal state information required for use precompiled code. ## Tests -Tests are present [here](https://github.com/dotnet/runtime/tree/master/src/libraries/System.Runtime.Loader/tests). +Tests are present [here](https://github.com/dotnet/runtime/tree/main/src/libraries/System.Runtime.Loader/tests). ## API Surface -Most of the **AssemblyLoadContext** [API surface](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Runtime.Loader/ref/System.Runtime.Loader.cs) is self-explanatory. Key APIs/Properties, though, are described below: +Most of the **AssemblyLoadContext** [API surface](https://github.com/dotnet/runtime/blob/main/src/libraries/System.Runtime.Loader/ref/System.Runtime.Loader.cs) is self-explanatory. Key APIs/Properties, though, are described below: ### Default @@ -89,4 +89,4 @@ As part of .NET Standard 2.0 effort, certain assembly load APIs off the **Assemb * Assembly.LoadFile - creates a new (anonymous) load context to load the assembly into. * Assembly.Load(byte[]) - creates a new (anonymous) load context to load the assembly into. -If you need to influence the load process or the load context in which assemblies are loaded, please look at the various Load* APIs exposed by **AssemblyLoadContext** [API surface](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Runtime.Loader/ref/System.Runtime.Loader.cs). +If you need to influence the load process or the load context in which assemblies are loaded, please look at the various Load* APIs exposed by **AssemblyLoadContext** [API surface](https://github.com/dotnet/runtime/blob/main/src/libraries/System.Runtime.Loader/ref/System.Runtime.Loader.cs). diff --git a/docs/design/features/code-versioning.md b/docs/design/features/code-versioning.md index 800a77b9951..751378ddf7e 100644 --- a/docs/design/features/code-versioning.md +++ b/docs/design/features/code-versioning.md @@ -327,7 +327,7 @@ to update the active child at either of those levels (ReJIT uses SetActiveILCode 2. Recalculate the active code version for each entrypoint 3. Update the published code version for each entrypoint to match the active code version -In order to do step 3 the `CodeVersionManager` relies on one of three different mechanisms, a `FixupPrecode`, a `JumpStamp`, or backpatching entry point slots. In [method.hpp](https://github.com/dotnet/runtime/blob/master/src/coreclr/vm/method.hpp) these mechanisms are described in the `MethodDesc::IsVersionableWith*()` functions, and all methods have been classified to use at most one of the techniques, based on the `MethodDesc::IsVersionableWith*()` functions. +In order to do step 3 the `CodeVersionManager` relies on one of three different mechanisms, a `FixupPrecode`, a `JumpStamp`, or backpatching entry point slots. In [method.hpp](https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/method.hpp) these mechanisms are described in the `MethodDesc::IsVersionableWith*()` functions, and all methods have been classified to use at most one of the techniques, based on the `MethodDesc::IsVersionableWith*()` functions. ### Thread-safety ### CodeVersionManager is designed for use in a free-threaded environment, in many cases by requiring the caller to acquire a lock before calling. This lock can be acquired by constructing an instance of `CodeVersionManager::LockHolder`. diff --git a/docs/design/features/framework-version-resolution.md b/docs/design/features/framework-version-resolution.md index a1107bc18e3..178f41d2328 100644 --- a/docs/design/features/framework-version-resolution.md +++ b/docs/design/features/framework-version-resolution.md @@ -11,7 +11,7 @@ Each framework reference consists of these values * Version - for example `3.0.1` * Roll-forward setting - for example `Minor` -*In the code the framework reference is represented by an instance of [`fx_reference_t`](https://github.com/dotnet/runtime/blob/master/src/native/corehost/fx_reference.h).* +*In the code the framework reference is represented by an instance of [`fx_reference_t`](https://github.com/dotnet/runtime/blob/main/src/native/corehost/fx_reference.h).* In the `.runtimeconfig.json` these values are defined like this: ``` json diff --git a/docs/design/features/hw-intrinsics.md b/docs/design/features/hw-intrinsics.md index 70aec90f29e..57b379ec18f 100644 --- a/docs/design/features/hw-intrinsics.md +++ b/docs/design/features/hw-intrinsics.md @@ -6,7 +6,7 @@ see https://github.com/dotnet/designs/blob/master/accepted/2018/platform-intrins In discussing the hardware intrinsics, we refer to the target platform, such as X86 or Arm64, as the "platform" and each set of extensions that are implemented as a unit (e.g. AVX2 on X64 or Simd on Arm64) as an "ISA". -There is a design document for the Arm64 intrinsics: https://github.com/dotnet/runtime/blob/master/docs/design/features/arm64-intrinsics.md. It should be updated to reflect current (and ongoing) progress. +There is a design document for the Arm64 intrinsics: https://github.com/dotnet/runtime/blob/main/docs/design/features/arm64-intrinsics.md. It should be updated to reflect current (and ongoing) progress. ## Overview @@ -53,7 +53,7 @@ The JIT depends on the VM and configuration settings to determine what target pl ### Importation -Hardware intrinsics are built on RyuJIT's `NamedIntrinsic` mechanism to identify method calls that should be recognized as intrinsics (see https://github.com/dotnet/runtime/blob/master/src/coreclr/jit/namedintrinsiclist.h). In the incoming IL, intrinsic invocations are just method calls, so the JIT must distinguish intrinsic calls from ordinary call-sites and map them to its IR representation: the `GenTreeHWIntrinsic` node. +Hardware intrinsics are built on RyuJIT's `NamedIntrinsic` mechanism to identify method calls that should be recognized as intrinsics (see https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/namedintrinsiclist.h). In the incoming IL, intrinsic invocations are just method calls, so the JIT must distinguish intrinsic calls from ordinary call-sites and map them to its IR representation: the `GenTreeHWIntrinsic` node. The [Intrinsic] attribute was added to eliminate the need to check each call-site. It [Intrinsic] attribute has a different meaning on each attribute target: diff --git a/docs/design/features/native-hosting.md b/docs/design/features/native-hosting.md index 6b498464bf8..dc5639f9baf 100644 --- a/docs/design/features/native-hosting.md +++ b/docs/design/features/native-hosting.md @@ -18,10 +18,10 @@ App (native or .NET Core both) which needs to use some of the other services pro ## Existing support * **C-style ABI in `coreclr`** -`coreclr` exposes ABI to host the .NET runtime and run managed code already using C-style APIs. See this [header file](https://github.com/dotnet/runtime/blob/master/src/coreclr/hosts/inc/coreclrhost.h) for the exposed functions. +`coreclr` exposes ABI to host the .NET runtime and run managed code already using C-style APIs. See this [header file](https://github.com/dotnet/runtime/blob/main/src/coreclr/hosts/inc/coreclrhost.h) for the exposed functions. This API requires the native host to locate the runtime and to fully specify all startup parameters for the runtime. There's no inherent interoperability between these APIs and the .NET SDK. * **COM-style ABI in `coreclr`** -`coreclr` exposes COM-style ABI to host the .NET runtime and perform a wide range of operations on it. See this [header file](https://github.com/dotnet/runtime/blob/master/src/coreclr/pal/prebuilt/inc/mscoree.h) for more details. +`coreclr` exposes COM-style ABI to host the .NET runtime and perform a wide range of operations on it. See this [header file](https://github.com/dotnet/runtime/blob/main/src/coreclr/pal/prebuilt/inc/mscoree.h) for more details. Similarly to the C-style ABI the COM-style ABI also requires the native host to locate the runtime and to fully specify all startup parameters. There's no inherent interoperability between these APIs and the .NET SDK. The COM-style ABI is deprecated and should not be used going forward. @@ -34,7 +34,7 @@ The native host is still required to locate the `hostfxr` or `hostpolicy` librar ## Scope This document focuses on hosting which cooperates with the .NET SDK and consumes the artifacts produced by building the managed app/libraries directly. It completely ignores the COM-style ABI as it's hard to use from some programming languages. -As such the document explicitly excludes any hosting based on directly loading `coreclr`. Instead it focuses on using the existing .NET Core hosting components in new ways. For details on the .NET Core hosting components see [this document](https://github.com/dotnet/runtime/tree/master/docs/design/features/host-components.md). +As such the document explicitly excludes any hosting based on directly loading `coreclr`. Instead it focuses on using the existing .NET Core hosting components in new ways. For details on the .NET Core hosting components see [this document](https://github.com/dotnet/runtime/tree/main/docs/design/features/host-components.md). ## Longer term vision @@ -105,7 +105,7 @@ Ideally it should be possible to combine the different types of initialization, Lot of other combinations will not be allowed simply as a result of shipping decisions. There's only so much functionality we can fit into any given release, so many combinations will be explicitly disabled to reduce the work necessary to actually ship this. The document below should describe which combinations are allowed in which release. ## High-level proposal -In .NET Core 3.0 the hosting components (see [here](https://github.com/dotnet/runtime/tree/master/docs/design/features/host-components.md)) ships with several hosts. These are binaries which act as the entry points to the .NET Core hosting components/runtime: +In .NET Core 3.0 the hosting components (see [here](https://github.com/dotnet/runtime/tree/main/docs/design/features/host-components.md)) ships with several hosts. These are binaries which act as the entry points to the .NET Core hosting components/runtime: * The "muxer" (`dotnet.exe`) * The `apphost` (`.exe` which is part of the app) * The `comhost` (`.dll` which is part of the app and acts as COM server) @@ -368,9 +368,9 @@ Starts the runtime and returns a function pointer to specified functionality of * `host_context_handle` - handle to the initialized host context. * `type` - the type of runtime functionality requested * `hdt_load_assembly_and_get_function_pointer` - entry point which loads an assembly (with dependencies) and returns function pointer for a specified static method. See below for details (Loading and calling managed components) - * `hdt_com_activation`, `hdt_com_register`, `hdt_com_unregister` - COM activation entry-points - see [COM activation](https://github.com/dotnet/runtime/tree/master/docs/design/features/COM-activation.md) for more details. - * `hdt_load_in_memory_assembly` - IJW entry-point - see [IJW activation](https://github.com/dotnet/runtime/tree/master/docs/design/features/IJW-activation.md) for more details. - * `hdt_winrt_activation` **[.NET 3.\* only]** - WinRT activation entry-point - see [WinRT activation](https://github.com/dotnet/runtime/tree/master/docs/design/features/WinRT-activation.md) for more details. The delegate is not supported for .NET 5 and above. + * `hdt_com_activation`, `hdt_com_register`, `hdt_com_unregister` - COM activation entry-points - see [COM activation](https://github.com/dotnet/runtime/tree/main/docs/design/features/COM-activation.md) for more details. + * `hdt_load_in_memory_assembly` - IJW entry-point - see [IJW activation](https://github.com/dotnet/runtime/tree/main/docs/design/features/IJW-activation.md) for more details. + * `hdt_winrt_activation` **[.NET 3.\* only]** - WinRT activation entry-point - see [WinRT activation](https://github.com/dotnet/runtime/tree/main/docs/design/features/WinRT-activation.md) for more details. The delegate is not supported for .NET 5 and above. * `hdt_get_function_pointer` **[.NET 5 and above]** - entry-point which finds a managed method and returns a function pointer to it. See below for details (Calling managed function). * `delegate` - when successful, the native function pointer to the requested runtime functionality. @@ -488,8 +488,8 @@ One such scenario is a COM host on multiple threads. The app is not running any At the same time it gives the native app (`comhost` in this case) the ability to query and modify runtime properties in between the `hostfxr_initialize...` and `hostfxr_get_runtime_delegate` calls on the `first host context`. ### API usage -The `hostfxr` exports are defined in the [hostfxr.h](https://github.com/dotnet/runtime/blob/master/src/native/corehost/hostfxr.h) header file. -The runtime helper and method signatures for loading managed components are defined in [coreclr_delegates.h](https://github.com/dotnet/runtime/blob/master/src/native/corehost/coreclr_delegates.h) header file. +The `hostfxr` exports are defined in the [hostfxr.h](https://github.com/dotnet/runtime/blob/main/src/native/corehost/hostfxr.h) header file. +The runtime helper and method signatures for loading managed components are defined in [coreclr_delegates.h](https://github.com/dotnet/runtime/blob/main/src/native/corehost/coreclr_delegates.h) header file. Currently we don't plan to ship these files, but it's possible to take them from the repo and use it. diff --git a/docs/design/features/standalone-gc-eventing.md b/docs/design/features/standalone-gc-eventing.md index 899714883b6..edc304c7e34 100644 --- a/docs/design/features/standalone-gc-eventing.md +++ b/docs/design/features/standalone-gc-eventing.md @@ -186,7 +186,7 @@ Tools (specifically PerfView) will want to be enlightened about dynamic events f we want to make this experience nice is up to us, but we will most likely want to ship PerfView support for any dynamic event that we end up shipping with the CLR GC. -[1]: https://github.com/dotnet/runtime/blob/master/src/coreclr/gc/env/etmdummy.h#L5-L57 +[1]: https://github.com/dotnet/runtime/blob/main/src/coreclr/gc/env/etmdummy.h#L5-L57 ### Concrete Example: Porting a single known event to IGCToCLREventSink diff --git a/docs/design/features/standalone-gc-loading.md b/docs/design/features/standalone-gc-loading.md index 2bdc65f830d..3373bf5559f 100644 --- a/docs/design/features/standalone-gc-loading.md +++ b/docs/design/features/standalone-gc-loading.md @@ -23,7 +23,7 @@ some terms that will be used often in this document. such a way that it can be run *out of process*, when debugging .NET code using a debugger. The DAC is used by higher-level components such as SOS (Son of Strike, a windbg/lldb debugger extension for debugging managed code) and the DBI (a COM interface). The full details about the DAC are covered in - [this document](https://github.com/dotnet/runtime/blob/master/docs/design/coreclr/botr/dac-notes.md). + [this document](https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/dac-notes.md). ## Rationale and Goals of a Standalone GC @@ -47,7 +47,7 @@ Worth noting is that the JIT (both RyuJIT and the legacy JIT(s) before it) can b and have realized these same benefits. The existence of an interface and an implementation loadable from shared libraries has enabled RyuJIT in particular to be used as the code generator for both the CoreRT compiler and crossgen, while still being flexible enough to be tested using tools that implement -very non-standard execution engines such as [SuperPMI](https://github.com/dotnet/runtime/blob/master/src/coreclr/ToolBox/superpmi/readme.txt). +very non-standard execution engines such as [SuperPMI](https://github.com/dotnet/runtime/blob/main/src/coreclr/ToolBox/superpmi/readme.txt). The below loading protocol is inspired directly by the JIT loader and many aspects of the GC loader are identical to what the JIT does when loading dynamic shared libraries. diff --git a/docs/pr-guide.md b/docs/pr-guide.md index 7439bd9bafd..92e89e4844a 100644 --- a/docs/pr-guide.md +++ b/docs/pr-guide.md @@ -44,7 +44,7 @@ Validation may fail for several reasons: * It's a known issue listed in our [big tracking issue](https://github.com/dotnet/runtime/issues/702) or tagged `blocking-clean-ci` [(query here)](https://github.com/dotnet/runtime/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Ablocking-clean-ci+) * Its otherwise beyond any reasonable doubt that your code changes could not have caused this. * If the tests pass on rerun, that may suggest it's not related. -* In this situation, you want to re-run but not necessarily rebase on master. +* In this situation, you want to re-run but not necessarily rebase on main. * To rerun just the failed leg(s): * Click on any leg. Navigate through the Azure DevOps UI, find the "..." button and choose "Retry failed legs" * Or, on the GitHub Checks tab choose "re-run failed checks". This will not rebase your change. @@ -55,9 +55,9 @@ Validation may fail for several reasons: * If you have established that it is an unrelated failure, please ensure we have an active issue for it. See the [unrelated failure](#what-to-do-if-you-determine-the-failure-is-unrelated) section below. * Whoever merges the PR should be satisfied that the failure is unrelated, is not introduced by the change, and that we are appropriately tracking it. -### Option 3: The state of the master branch HEAD is bad. +### Option 3: The state of the main branch HEAD is bad. -* This is the very rare case where there was a build break in master, and you got unlucky. Hopefully the break has been fixed, and you want CI to rebase your change and rerun validation. +* This is the very rare case where there was a build break in main, and you got unlucky. Hopefully the break has been fixed, and you want CI to rebase your change and rerun validation. * To rebase and rerun all validation: * Add a comment `/azp run runtime` * Or, click on "re-run all checks" in the GitHub Checks tab @@ -84,7 +84,7 @@ If you have determined the failure is definitely not caused by changes in your P * In a follow-up Pull Request, disable the failing test(s) with the corresponding issue link tracking the disable. * Update the tracking issue with the label `disabled-test`. * 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) - * 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. + * For runtime tests found under `src/tests`, please edit [`issues.targets`](https://github.com/dotnet/runtime/blob/main/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. 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. diff --git a/docs/project/analyzers.md b/docs/project/analyzers.md index b36b1d3c350..d423a6193e1 100644 --- a/docs/project/analyzers.md +++ b/docs/project/analyzers.md @@ -4,11 +4,11 @@ This repo relies on [.NET Compiler Platform analyzers](https://docs.microsoft.co To add an analyzer package to the build: 1. Select a package you want to employ, for example https://www.nuget.org/packages/SonarAnalyzer.CSharp/. This analyzer package's name is `SonarAnalyzer.CSharp` and the latest version as of this edit is `7.15.0.8572`. -2. Add a PackageReference entry to https://github.com/dotnet/runtime/blob/master/eng/Analyzers.props, e.g. +2. Add a PackageReference entry to https://github.com/dotnet/runtime/blob/main/eng/Analyzers.props, e.g. ```XML <PackageReference Include="SonarAnalyzer.CSharp" Version="7.15.0.8572" /> ``` -3. After that point, all builds will employ all rules in that analyzer package that are enabled by default. Rules can be disabled by adding entries to the https://github.com/dotnet/runtime/blob/master/src/libraries/CodeAnalysis.ruleset file, e.g. +3. After that point, all builds will employ all rules in that analyzer package that are enabled by default. Rules can be disabled by adding entries to the https://github.com/dotnet/runtime/blob/main/src/libraries/CodeAnalysis.ruleset file, e.g. ```XML <Rules AnalyzerId="SonarAnalyzer.CSharp" RuleNamespace="SonarAnalyzer.CSharp"> <Rule Id="S1006" Action="None" /> diff --git a/docs/project/breaking-change-process.md b/docs/project/breaking-change-process.md index cb8e83f6f3e..2ac0fa0af60 100644 --- a/docs/project/breaking-change-process.md +++ b/docs/project/breaking-change-process.md @@ -45,6 +45,6 @@ The following are good examples of breaking change issues There are additional documents that you should consult about breaking changes: -* [Breaking changes](https://github.com/dotnet/runtime/blob/master/docs/coding-guidelines/breaking-changes.md) -* [Breaking change definitions](https://github.com/dotnet/runtime/blob/master/docs/coding-guidelines/breaking-change-definitions.md) -* [Breaking change rules](https://github.com/dotnet/runtime/blob/master/docs/coding-guidelines/breaking-change-rules.md) +* [Breaking changes](https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/breaking-changes.md) +* [Breaking change definitions](https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/breaking-change-definitions.md) +* [Breaking change rules](https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/breaking-change-rules.md) diff --git a/docs/project/copyright.md b/docs/project/copyright.md index 3e9ec92e3b1..2333165f3d2 100644 --- a/docs/project/copyright.md +++ b/docs/project/copyright.md @@ -21,7 +21,7 @@ Binary License The following rules are used for determining the binary license: - .NET binary distributions (zips, nuget packages, …) are licensed as MIT (identical to the [.NET source license](https://github.com/dotnet/core/blob/master/LICENSE.TXT)). -- The license link (if there is one) should point to the repository where the file came from, for example: [dotnet/runtime](https://github.com/dotnet/runtime/blob/master/LICENSE.TXT). +- The license link (if there is one) should point to the repository where the file came from, for example: [dotnet/runtime](https://github.com/dotnet/runtime/blob/main/LICENSE.TXT). - If the contained binaries are built from multiple .NET repositories, the license should point to [dotnet/core](https://github.com/dotnet/core/blob/master/LICENSE.TXT). - If the contents are not 100% open source, the distribution should be licensed with the [.NET Library license](https://www.microsoft.com/net/dotnet_library_license.htm). - It is OK for licensing to be asymmetric for a single distribution type. For example, it’s possible that the .NET SDK distribution might be fully open source for Linux but include a closed-source component on Windows. In this case, the SDK would be licensed as MIT on Linux and use the .NET Library License on Windows. It is better to have more open licenses than less. diff --git a/docs/project/dogfooding.md b/docs/project/dogfooding.md index b6de50d2d3f..ed3e2f741cb 100644 --- a/docs/project/dogfooding.md +++ b/docs/project/dogfooding.md @@ -159,7 +159,7 @@ $ bin\Debug\net6.0\win-x64\publish\App.exe --> <!-- BEGIN generated table --> -| Platform | Master | +| Platform | Main | | --- | :---: | | **Windows (x64)** | [![][win-x64-badge-6.0.X]][win-x64-version-6.0.X]<br>[Installer][win-x64-installer-6.0.X] ([Checksum][win-x64-installer-checksum-6.0.X])<br>[zip][win-x64-zip-6.0.X] ([Checksum][win-x64-zip-checksum-6.0.X])<br>[NetHost (zip)][win-x64-nethost-zip-6.0.X]<br>[Symbols (zip)][win-x64-symbols-zip-6.0.X] | | **Windows (x86)** | [![][win-x86-badge-6.0.X]][win-x86-version-6.0.X]<br>[Installer][win-x86-installer-6.0.X] ([Checksum][win-x86-installer-checksum-6.0.X])<br>[zip][win-x86-zip-6.0.X] ([Checksum][win-x86-zip-checksum-6.0.X])<br>[NetHost (zip)][win-x86-nethost-zip-6.0.X]<br>[Symbols (zip)][win-x86-symbols-zip-6.0.X] | diff --git a/docs/project/garbage-collector-guidelines.md b/docs/project/garbage-collector-guidelines.md index 4df6b84dc6e..f14976fe810 100644 --- a/docs/project/garbage-collector-guidelines.md +++ b/docs/project/garbage-collector-guidelines.md @@ -26,7 +26,7 @@ Required Testing: Validation of the behavior of the affected APIs. ## Stress Testing ## Stress testing must run for at least **48 hours** against a debug build. -Stress testing for checked and release builds can be run locally. Please following the instructions described in [gc-stress-run-readme.md](https://github.com/dotnet/runtime/blob/master/docs/workflow/testing/coreclr/gc-stress-run-readme.md). You can also request it on pull requests with The .NET CI infrastructure with the trigger phrase: +Stress testing for checked and release builds can be run locally. Please following the instructions described in [gc-stress-run-readme.md](https://github.com/dotnet/runtime/blob/main/docs/workflow/testing/coreclr/gc-stress-run-readme.md). You can also request it on pull requests with The .NET CI infrastructure with the trigger phrase: ``` @dotnet_bot test <platform> <flavor> gc_reliability_framework diff --git a/docs/project/glossary.md b/docs/project/glossary.md index 59575bffb7c..6581fe2a983 100644 --- a/docs/project/glossary.md +++ b/docs/project/glossary.md @@ -18,13 +18,13 @@ terminology. | CLR | Common Language Runtime. | | COMPlus | An early name for the .NET platform, back when it was envisioned as a successor to the COM platform (hence, "COM+"). Used in various places in the CLR infrastructure, most prominently as a common prefix for the names of internal configuration settings. Note that this is different from the product that eventually ended up being named [COM+](https://msdn.microsoft.com/en-us/library/windows/desktop/ms685978.aspx). | | COR | [Common Object Runtime](http://www.danielmoth.com/Blog/mscorlibdll.aspx). The name of .NET before it was named .NET. | -| CoreFX | Core Framework. Original project name for open source and cross-platform version of [.NET runtime libraries](https://github.com/dotnet/runtime/tree/master/src/libraries) | +| CoreFX | Core Framework. Original project name for open source and cross-platform version of [.NET runtime libraries](https://github.com/dotnet/runtime/tree/main/src/libraries) | | DAC | Data Access Component. An abstraction layer over the internal structures in the runtime. | | EE | Execution Engine. | -| GC | [Garbage Collector](https://github.com/dotnet/runtime/blob/master/docs/design/coreclr/botr/garbage-collection.md). | +| GC | [Garbage Collector](https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/garbage-collection.md). | | IPC | Inter-Process Communication. | -| JIT | [Just-in-Time](https://github.com/dotnet/runtime/blob/master/docs/design/coreclr/jit/ryujit-overview.md) compiler. RyuJIT is the code name for the next generation Just-in-Time(aka "JIT") for the .NET runtime. | -| LCG | Lightweight Code Generation. An early name for [dynamic methods](https://github.com/dotnet/runtime/blob/master/src/coreclr/System.Private.CoreLib/src/System/Reflection/Emit/DynamicMethod.cs). | +| JIT | [Just-in-Time](https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/jit/ryujit-overview.md) compiler. RyuJIT is the code name for the next generation Just-in-Time(aka "JIT") for the .NET runtime. | +| LCG | Lightweight Code Generation. An early name for [dynamic methods](https://github.com/dotnet/runtime/blob/main/src/coreclr/System.Private.CoreLib/src/System/Reflection/Emit/DynamicMethod.cs). | | MD | MetaData. | | MDA | Managed Debugging Assistant - see [details](https://docs.microsoft.com/en-us/dotnet/framework/debug-trace-profile/diagnosing-errors-with-managed-debugging-assistants) (Note: Not in .NET Core, equivalent diagnostic functionality is made available on a case-by-case basis, e.g. [#9418](https://github.com/dotnet/runtime/issues/9418)) | | NGen | Native Image Generator. | @@ -37,7 +37,7 @@ terminology. | R2R | Ready-to-Run. A flavor of native images - command line switch of [crossgen](../workflow/building/coreclr/crossgen.md). | | Redhawk | Codename for experimental minimal managed code runtime that evolved into [CoreRT](https://github.com/dotnet/corert/). | | SOS | [Son of Strike](https://docs.microsoft.com/en-us/archive/blogs/jasonz/sos-debugging-of-the-clr-part-1). The debugging extension for DbgEng based debuggers. Uses the DAC as an abstraction layer for its operation. | -| SuperPMI | JIT component test framework (super fast JIT testing - it mocks/replays EE in EE-JIT interface) - see [SuperPMI details](https://github.com/dotnet/runtime/blob/master/src/coreclr/ToolBox/superpmi/readme.txt). | +| SuperPMI | JIT component test framework (super fast JIT testing - it mocks/replays EE in EE-JIT interface) - see [SuperPMI details](https://github.com/dotnet/runtime/blob/main/src/coreclr/ToolBox/superpmi/readme.txt). | | SVR | The CLR used to be built as two variants, with one called "mscorsvr.dll", to mean the "server" version. In particular, it contained the server GC implementation, which was intended for multi-threaded apps capable of taking advantage of multiple processors. In the .NET Framework 2 release, the two variants were merged into "mscorwks.dll". The WKS version was the default, however the SVR version remained available. | | TPA | Trusted Platform Assemblies used to be a special set of assemblies that comprised the platform assemblies, when it was originally designed. As of today, it is simply the set of assemblies known to constitute the application. | | URT | Universal Runtime. Ancient name for what ended up being .NET, is used in the WinError facility name FACILITY_URT. | @@ -132,7 +132,7 @@ the same time the .NET Framework was first released. Since Microsoft didn't release Rotor as open source, Mono was forced to start from scratch and was thus a complete re-implementation of the .NET Framework with no shared code. -Today, the [Mono VM](https://github.com/dotnet/runtime/tree/master/src/mono) is part +Today, the [Mono VM](https://github.com/dotnet/runtime/tree/main/src/mono) is part of the unified .NET platform. It is optimized for mobile (e.g. Xamarin) and browser (e.g. Blazor) scenarios. "C# powered by Mono" has been scripting engine of choice for a number of game engines. @@ -143,7 +143,7 @@ Unity - the world's most popular game engine - is scripted by C#, powered by a c Originally, CoreCLR was the runtime of Silverlight and was designed to run on multiple platforms, specifically Windows and OS X. -Today, the [CoreCLR runtime](https://github.com/dotnet/runtime/tree/master/src/coreclr) +Today, the [CoreCLR runtime](https://github.com/dotnet/runtime/tree/main/src/coreclr) is part of unified .NET platform. It is optimized for cloud (e.g. ASP.NET) and desktop (e.g. WinForms, WPF) scenarios. diff --git a/docs/project/issue-guide.md b/docs/project/issue-guide.md index 57889edf332..58be6a1eaff 100644 --- a/docs/project/issue-guide.md +++ b/docs/project/issue-guide.md @@ -38,7 +38,7 @@ We use [milestones](https://github.com/dotnet/runtime/milestones) to prioritize We assign each issue to assignee, when the assignee is ready to pick up the work and start working on it. If the issue is not assigned to anyone and you want to pick it up, please say so - we will assign the issue to you. If the issue is already assigned to someone, please coordinate with the assignee before you start working on it. ### Areas -Areas are tracked by labels area-* (e.g. area-System.Collections). Each area typically corresponds to one or more contract assemblies. To view owners for each area in this repository check out the [area-owners.md](https://github.com/dotnet/runtime/blob/master/docs/area-owners.md) page. +Areas are tracked by labels area-* (e.g. area-System.Collections). Each area typically corresponds to one or more contract assemblies. To view owners for each area in this repository check out the [area-owners.md](https://github.com/dotnet/runtime/blob/main/docs/area-owners.md) page. ### Community Partner Experts @@ -81,7 +81,7 @@ Feel free to use other labels if it helps your triage efforts (e.g. **needs more 1. PR has **Assignee** set to author of the PR, if it is non-CoreFX engineer, then area owners are co-assignees * Motivation #1: Area owners are responsible to do code reviews for PRs from external contributors. CoreFX engineers know how to get code reviews from others. * Motivation #2: Assignees will get notifications for anything happening on the PR. -1. [Optional] Set milestone according to the branch the PR is against (master = 5.0, release/3.0 = 3.0, release/2.1 = 2.1.x, etc.) +1. [Optional] Set milestone according to the branch the PR is against (main = 6.0, release/5.0 = 5.0) * Motivation: Easier to track and audit where which fix ended up and if it needs to be ported into another branch (hence reflecting branch the specific PR ended up and not the abstract issue). * Note: This is easily done after merge via simple queries & bulk-edits, you don't have to do this one. 1. Any other labels on PRs are superfluous and not needed (exceptions: **blocked**, **NO MERGE**) diff --git a/docs/project/library-servicing.md b/docs/project/library-servicing.md index b912df3f3d1..fd949d68281 100644 --- a/docs/project/library-servicing.md +++ b/docs/project/library-servicing.md @@ -6,11 +6,11 @@ This document provides the steps necessary after modifying a library in a servic Your first step is to determine whether or not your library has its own package. To do this, go into the root folder for the library you've made changes to. If there is a `pkg` folder there (which should have a `.pkgproj` file inside of it), your library does have its own package. If there is no `pkg` folder there, the library is the part of the shared framework. If it is, then there is nothing that needs to be done. -For example, if you made changes to [Microsoft.Win32.Primitives](https://github.com/dotnet/runtime/tree/master/src/libraries/Microsoft.Win32.Primitives), then you have a `.pkgproj`, and will have to follow the steps in this document. However, if you made changes to [System.Collections](https://github.com/dotnet/runtime/tree/master/src/libraries/System.Collections), then you don't have a `.pkgproj`, and you do not need to do any further work for servicing. +For example, if you made changes to [Microsoft.Win32.Primitives](https://github.com/dotnet/runtime/tree/main/src/libraries/Microsoft.Win32.Primitives), then you have a `.pkgproj`, and will have to follow the steps in this document. However, if you made changes to [System.Collections](https://github.com/dotnet/runtime/tree/main/src/libraries/System.Collections), then you don't have a `.pkgproj`, and you do not need to do any further work for servicing. ## Determine PackageVersion -Each package has a property called `PackageVersion`. When you make a change to a library & ship it, the `PackageVersion` must be bumped. This property could either be in one of two places inside your library's source folder: `Directory.Build.Props` (or dir.props), or the `.pkgproj`. It's also possible that the property is in neither of those files, in which case we're using the default version from [Packaging.props](https://github.com/dotnet/runtime/blob/master/eng/packaging.props#L25) (IMPORTANT - make sure to check the default version from the branch that you're making changes to, not from master). You'll need to increment this package version. If the property is already present in your library's source folder, just increment the patch version by 1 (e.g. `4.6.0` -> `4.6.1`). If it's not present, add it to the library's `Directory.Build.props`, where it is equal to the version in `Packaging.props`, with the patch version incremented by 1. +Each package has a property called `PackageVersion`. When you make a change to a library & ship it, the `PackageVersion` must be bumped. This property could either be in one of two places inside your library's source folder: `Directory.Build.Props` (or dir.props), or the `.pkgproj`. It's also possible that the property is in neither of those files, in which case we're using the default version from [Packaging.props](https://github.com/dotnet/runtime/blob/main/eng/packaging.props#L25) (IMPORTANT - make sure to check the default version from the branch that you're making changes to, not from main). You'll need to increment this package version. If the property is already present in your library's source folder, just increment the patch version by 1 (e.g. `4.6.0` -> `4.6.1`). If it's not present, add it to the library's `Directory.Build.props`, where it is equal to the version in `Packaging.props`, with the patch version incremented by 1. Note that it's possible that somebody else has already incremented the package version since our last release. If this is the case, you don't need to increment it yourself. To confirm, check [Nuget.org](https://www.nuget.org/) to see if there is already a published version of your package with the same package version. If so, the `PackageVersion` must be incremented. If not, there's still a possibility that the version should be bumped, in the event that we've already built the package with its current version in an official build, but haven't released it publicly yet. If you see that the `PackageVersion` has been changed in the last 1-2 months, but don't see a matching package in Nuget.org, contact somebody on the servicing team for guidance. @@ -41,12 +41,12 @@ eg. ## Update the package index -If you incremented the `AssemblyVersion` in the last step, you'll also need to add an entry to [packageIndex.json](https://github.com/dotnet/runtime/blob/master/src/libraries/pkg/Microsoft.Private.PackageBaseline/packageIndex.json). Find the entry for your library in that file (again, making sure you're in the correct release branch), then find the subsection labeled `AssemblyVersionInPackageVersion`. There, add an entry that maps your new `AssemblyVersion` to your new `PackageVersion`. For an example, see [this PR](https://github.com/dotnet/runtime/commit/d0e4dcc7ebf008e7b6835cafbd03878c3a0e75f8#diff-ec9fd7a62cb0c494d86029014940382cR107), where we bumped the `PackageVersion` of `Microsoft.Diagnostics.Tracing.EventSource` from `2.0.0` to `2.0.1`, and bumped the `AssemblyVersion` from `2.0.0.0` to `2.0.1.0`. Therefore, we added an entry to `packageIndex.json` of the form `"2.0.1.0": "2.0.1"`. +If you incremented the `AssemblyVersion` in the last step, you'll also need to add an entry to [packageIndex.json](https://github.com/dotnet/runtime/blob/main/src/libraries/pkg/Microsoft.Private.PackageBaseline/packageIndex.json). Find the entry for your library in that file (again, making sure you're in the correct release branch), then find the subsection labeled `AssemblyVersionInPackageVersion`. There, add an entry that maps your new `AssemblyVersion` to your new `PackageVersion`. For an example, see [this PR](https://github.com/dotnet/runtime/commit/d0e4dcc7ebf008e7b6835cafbd03878c3a0e75f8#diff-ec9fd7a62cb0c494d86029014940382cR107), where we bumped the `PackageVersion` of `Microsoft.Diagnostics.Tracing.EventSource` from `2.0.0` to `2.0.1`, and bumped the `AssemblyVersion` from `2.0.0.0` to `2.0.1.0`. Therefore, we added an entry to `packageIndex.json` of the form `"2.0.1.0": "2.0.1"`. The baseline version for the assembly in the package index should also be incremented so that all the other packages can use this servicing version for package dependencies. ## Add your package to libraries-packages.proj -In order to ensure that your package gets built, you need to add it to [libraries-packages.proj](https://github.com/dotnet/runtime/blob/master/src/libraries/libraries-packages.proj). In the linked example, we were building `System.Drawing.Common`. All you have to do is add a `Project` block inside the linked ItemGroup that matches the form of the linked example, but with `System.Drawing.Common` replaced by your library's name. Again, make sure to do this in the right servicing branch. +In order to ensure that your package gets built, you need to add it to [libraries-packages.proj](https://github.com/dotnet/runtime/blob/main/src/libraries/libraries-packages.proj). In the linked example, we were building `System.Drawing.Common`. All you have to do is add a `Project` block inside the linked ItemGroup that matches the form of the linked example, but with `System.Drawing.Common` replaced by your library's name. Again, make sure to do this in the right servicing branch. ## Test your changes diff --git a/docs/project/writing-tests.md b/docs/project/writing-tests.md index dd66fc96cd2..3255ff0df6b 100644 --- a/docs/project/writing-tests.md +++ b/docs/project/writing-tests.md @@ -33,7 +33,7 @@ public class HttpWebRequestTest ``` # LoopbackServer -When writing network related tests we try to avoid running tests against a remote endpoint if possible. We provide simple APIs to create a LoopbackServer and send responses. A high number of scenarios can be tested with it. For additional information see https://github.com/dotnet/runtime/blob/master/src/libraries/Common/tests/System/Net/Http/LoopbackServer.cs +When writing network related tests we try to avoid running tests against a remote endpoint if possible. We provide simple APIs to create a LoopbackServer and send responses. A high number of scenarios can be tested with it. For additional information see https://github.com/dotnet/runtime/blob/main/src/libraries/Common/tests/System/Net/Http/LoopbackServer.cs Example (skipping additional usings and class scoping): ```cs @@ -65,7 +65,7 @@ This doesn't mean that you should mark every test which executes against a remot # Relay Server For network related tests which needs to contact a remote endpoint instead of a LoopbackServer, you can use our Relay Servers. We invest in Infrastructure to provide these "safe" remote endpoints. -For more information see https://github.com/dotnet/runtime/blob/master/src/libraries/Common/tests/System/Net/Configuration.Http.cs +For more information see https://github.com/dotnet/runtime/blob/main/src/libraries/Common/tests/System/Net/Configuration.Http.cs Example: ```cs diff --git a/docs/workflow/building/coreclr/cross-building.md b/docs/workflow/building/coreclr/cross-building.md index ef2eab62d32..55ef90222ed 100644 --- a/docs/workflow/building/coreclr/cross-building.md +++ b/docs/workflow/building/coreclr/cross-building.md @@ -6,7 +6,7 @@ Building ARM for Windows can be done using cross compilation. Requirements ------------ -Install the ARM tools and Windows SDK, as described [here](https://github.com/dotnet/runtime/blob/master/docs/workflow/requirements/windows-requirements.md). +Install the ARM tools and Windows SDK, as described [here](https://github.com/dotnet/runtime/blob/main/docs/workflow/requirements/windows-requirements.md). Cross compiling CoreCLR ----------------------- diff --git a/docs/workflow/building/libraries/README.md b/docs/workflow/building/libraries/README.md index 9e309d35c36..662be5442da 100644 --- a/docs/workflow/building/libraries/README.md +++ b/docs/workflow/building/libraries/README.md @@ -7,7 +7,7 @@ Here is one example of a daily workflow for a developer working mainly on the li ```cmd :: From root: git clean -xdf -git pull upstream master & git push origin master +git pull upstream main & git push origin main :: Build Debug libraries on top of Release runtime: build.cmd clr+libs -rc Release :: Performing the above is usually only needed once in a day, or when you pull down significant new changes. @@ -31,7 +31,7 @@ The instructions for Linux and macOS are essentially the same: ```bash # From root: git clean -xdf -git pull upstream master & git push origin master +git pull upstream main & git push origin main # Build Debug libraries on top of Release runtime: ./build.sh clr+libs -rc Release # Performing the above is usually only needed once in a day, or when you pull down significant new changes. diff --git a/docs/workflow/building/libraries/webassembly-instructions.md b/docs/workflow/building/libraries/webassembly-instructions.md index d8667ddec1a..315611d1ded 100644 --- a/docs/workflow/building/libraries/webassembly-instructions.md +++ b/docs/workflow/building/libraries/webassembly-instructions.md @@ -162,7 +162,7 @@ Submit a PR request with the updated version, wait for all checks to pass and fo }, ``` -Copy the docker image tag and replace it in [platform-matrix.yml](https://github.com/dotnet/runtime/blob/master/eng/pipelines/common/platform-matrix.yml#L172) +Copy the docker image tag and replace it in [platform-matrix.yml](https://github.com/dotnet/runtime/blob/main/eng/pipelines/common/platform-matrix.yml#L172) ``` container: diff --git a/docs/workflow/debugging/libraries/windows-instructions.md b/docs/workflow/debugging/libraries/windows-instructions.md index 5a1bedd45d9..16c48cdc4d4 100644 --- a/docs/workflow/debugging/libraries/windows-instructions.md +++ b/docs/workflow/debugging/libraries/windows-instructions.md @@ -150,7 +150,7 @@ The following EventSources are built-in to CoreFX. The ones that are not marked #### System.Net namespaces -Helper scripts are available at https://github.com/dotnet/runtime/tree/master/src/libraries/Common/tests/Scripts/Tools. Run `net_startlog.cmd` as Administrator, run the application, then run `net_stoplog.cmd`. Open the `.etl` file with PerfView. +Helper scripts are available at https://github.com/dotnet/runtime/tree/main/src/libraries/Common/tests/Scripts/Tools. Run `net_startlog.cmd` as Administrator, run the application, then run `net_stoplog.cmd`. Open the `.etl` file with PerfView. * `*Microsoft-System-Net-Http {bdd9a83e-1929-5482-0d73-2fe5e1c0e16d}`: HTTP-related traces. * `*Microsoft-System-Net-Http-WinHttpHandler {b71555b1-9566-5ce3-27f5-98405bbfde9d}`: WinHttpHandler-related traces. diff --git a/docs/workflow/requirements/windows-requirements.md b/docs/workflow/requirements/windows-requirements.md index a5cbaa83884..6b11f07a6fc 100644 --- a/docs/workflow/requirements/windows-requirements.md +++ b/docs/workflow/requirements/windows-requirements.md @@ -75,7 +75,7 @@ The dotnet/runtime repository requires at least Git 2.22.0. While not strictly needed to build or test this repository, having the .NET SDK installed lets you browse solution files in this repository with Visual Studio and use the dotnet.exe command to run .NET applications in the 'normal' way. We use this in the [Using Your Build](../testing/using-your-build.md) instructions. -The minimum required version of the SDK is specified in the [global.json file](https://github.com/dotnet/runtime/blob/master/global.json#L3). [You can find the installers and binaries for nightly builds of .NET SDK here](https://github.com/dotnet/installer#installers-and-binaries). +The minimum required version of the SDK is specified in the [global.json file](https://github.com/dotnet/runtime/blob/main/global.json#L3). [You can find the installers and binaries for nightly builds of .NET SDK here](https://github.com/dotnet/installer#installers-and-binaries). Alternatively, to avoid modifying your machine state, you can use the repository's locally acquired SDK by passing in the solution to load via the `-vs` switch: diff --git a/docs/workflow/testing/coreclr/test-configuration.md b/docs/workflow/testing/coreclr/test-configuration.md index 20d7375adac..3e0f0d21302 100644 --- a/docs/workflow/testing/coreclr/test-configuration.md +++ b/docs/workflow/testing/coreclr/test-configuration.md @@ -51,13 +51,13 @@ Therefore the managed portion of each test **must not contain**: * `<GCStressIncompatible>true</GCStressIncompatible>` * Exclude test from JIT stress runs runs by adding the following to the csproj: * `<JitOptimizationSensitive>true</JitOptimizationSensitive>` -* Add NuGet references by updating the following [test project](https://github.com/dotnet/runtime/blob/master/src/tests/Common/test_dependencies/test_dependencies.csproj). +* Add NuGet references by updating the following [test project](https://github.com/dotnet/runtime/blob/main/src/tests/Common/test_dependencies/test_dependencies.csproj). * Get access to System.Private.CoreLib types and methods that are not exposed via public surface by adding the following to the csproj: * `<ReferenceSystemPrivateCoreLib>true</ReferenceSystemPrivateCoreLib>` * Any System.Private.CoreLib types and methods used by tests must be available for building on all platforms. This means there must be enough implementation for the C# compiler to find the referenced types and methods. Unsupported target platforms should simply `throw new PlatformNotSupportedException()` in its dummy method implementations. -* Update exclusion list at [tests/issues.targets](https://github.com/dotnet/runtime/blob/master/src/tests/issues.targets) if the test fails due to active bug. +* Update exclusion list at [tests/issues.targets](https://github.com/dotnet/runtime/blob/main/src/tests/issues.targets) if the test fails due to active bug. ### Creating a C# test project diff --git a/docs/workflow/testing/libraries/testing-android.md b/docs/workflow/testing/libraries/testing-android.md index 52a17f996f3..4c753f6832c 100644 --- a/docs/workflow/testing/libraries/testing-android.md +++ b/docs/workflow/testing/libraries/testing-android.md @@ -75,7 +75,7 @@ The following shows how to run tests for a specific library ``` ### Test App Design -Android app is basically a [Java Instrumentation](https://github.com/dotnet/runtime/blob/master/src/mono/msbuild/AndroidAppBuilder/Templates/MonoRunner.java) and a simple Activity that inits the Mono Runtime via JNI. This Mono Runtime starts a simple xunit test +Android app is basically a [Java Instrumentation](https://github.com/dotnet/runtime/blob/main/src/mono/msbuild/AndroidAppBuilder/Templates/MonoRunner.java) and a simple Activity that inits the Mono Runtime via JNI. This Mono Runtime starts a simple xunit test runner called XHarness.TestRunner (see https://github.com/dotnet/xharness) which runs tests for all `*.Tests.dll` libs in the bundle. There is also XHarness.CLI tool with ADB embedded to deploy `*.apk` to a target (device or emulator) and obtain logs once tests are completed. ### Obtaining the logs diff --git a/docs/workflow/testing/libraries/testing-apple.md b/docs/workflow/testing/libraries/testing-apple.md index 3f995700420..3e9be3c600c 100644 --- a/docs/workflow/testing/libraries/testing-apple.md +++ b/docs/workflow/testing/libraries/testing-apple.md @@ -14,7 +14,7 @@ In order to run the tests on a device you need to specify `DevTeamProvisioning` ``` ./build.sh libs.tests -os iOS -arch x64 -test /p:DevTeamProvisioning=H1A2B3C4D5 ``` -[AppleAppBuilder](https://github.com/dotnet/runtime/blob/master/src/mono/msbuild/AppleAppBuilder/AppleAppBuilder.cs) generates temp Xcode projects you can manually open and resolve provisioning issues there using native UI and deploy to your devices. +[AppleAppBuilder](https://github.com/dotnet/runtime/blob/main/src/mono/msbuild/AppleAppBuilder/AppleAppBuilder.cs) generates temp Xcode projects you can manually open and resolve provisioning issues there using native UI and deploy to your devices. ### Running individual test suites - The following shows how to run tests for a specific library: @@ -23,7 +23,7 @@ In order to run the tests on a device you need to specify `DevTeamProvisioning` ``` ### Test App Design -iOS/tvOS `*.app` (or `*.ipa`) is basically a simple [ObjC app](https://github.com/dotnet/runtime/blob/master/src/mono/msbuild/AppleAppBuilder/Templates/main-console.m) that inits the Mono Runtime. This Mono Runtime starts a simple xunit test +iOS/tvOS `*.app` (or `*.ipa`) is basically a simple [ObjC app](https://github.com/dotnet/runtime/blob/main/src/mono/msbuild/AppleAppBuilder/Templates/main-console.m) that inits the Mono Runtime. This Mono Runtime starts a simple xunit test runner called XHarness.TestRunner (see https://github.com/dotnet/xharness) which runs tests for all `*.Tests.dll` libs in the bundle. There is also XHarness.CLI tool to deploy `*.app` and `*.ipa` to a target (device or simulator) and listens for logs via network sockets. ### Existing Limitations diff --git a/docs/workflow/testing/using-your-build.md b/docs/workflow/testing/using-your-build.md index f3d96b6a144..682a5dcb523 100644 --- a/docs/workflow/testing/using-your-build.md +++ b/docs/workflow/testing/using-your-build.md @@ -27,7 +27,7 @@ After setting up dotnet you can verify you are using the newer version by: `dotnet --info` -- the version should be greater than 3.0.0-* -For another small walkthrough see [Dogfooding .NET SDK](https://github.com/dotnet/runtime/blob/master/docs/project/dogfooding.md). +For another small walkthrough see [Dogfooding .NET SDK](https://github.com/dotnet/runtime/blob/main/docs/project/dogfooding.md). ## Create sample self-contained application diff --git a/docs/workflow/using-dotnet-cli.md b/docs/workflow/using-dotnet-cli.md index 8e08863cdd9..1c67594a1af 100644 --- a/docs/workflow/using-dotnet-cli.md +++ b/docs/workflow/using-dotnet-cli.md @@ -9,7 +9,7 @@ If you want to use a faster method, you may want to use one of these walkthrough - [Using Your Build - Update from raw build output](./testing/using-your-build.md) - [Using CoreRun To Run .NET Application](./testing/using-corerun.md) -- [Dogfooding .NET SDK](https://github.com/dotnet/runtime/blob/master/docs/project/dogfooding.md). +- [Dogfooding .NET SDK](https://github.com/dotnet/runtime/blob/main/docs/project/dogfooding.md). ## Prerequisites diff --git a/eng/Versions.props b/eng/Versions.props index fc0f604d858..5ac8ca462e9 100644 --- a/eng/Versions.props +++ b/eng/Versions.props @@ -36,7 +36,7 @@ release, all packages listed below automatically stop building because the property no longer matches the metadata. (Do not delete the items!) - If the PatchVersion below is never changed from '0', the package will build in the 'master' + If the PatchVersion below is never changed from '0', the package will build in the 'main' branch, and during a forked RTM release ("X.Y.0"). It will stop building for "X.Y.1" unless manually enabled by updating the metadata. --> diff --git a/eng/build.ps1 b/eng/build.ps1 index c9777e478cb..4d6c6fe5b2d 100644 --- a/eng/build.ps1 +++ b/eng/build.ps1 @@ -111,7 +111,7 @@ function Get-Help() { Write-Host ".\build.cmd mono.corelib+libs.pretest -rc debug -c release" Write-Host "" Write-Host "" - Write-Host "For more information, check out https://github.com/dotnet/runtime/blob/master/docs/workflow/README.md" + Write-Host "For more information, check out https://github.com/dotnet/runtime/blob/main/docs/workflow/README.md" } if ($help) { diff --git a/eng/build.sh b/eng/build.sh index 4acb1e2c792..dc72e26d500 100755 --- a/eng/build.sh +++ b/eng/build.sh @@ -109,7 +109,7 @@ usage() echo "" echo "However, for this example, you need to already have ROOTFS_DIR set up." echo "Further information on this can be found here:" - echo "https://github.com/dotnet/runtime/blob/master/docs/workflow/building/coreclr/linux-instructions.md" + echo "https://github.com/dotnet/runtime/blob/main/docs/workflow/building/coreclr/linux-instructions.md" echo "" echo "* Build Mono runtime for Linux x64 on Release configuration." echo "./build.sh mono -c release" @@ -121,7 +121,7 @@ usage() echo "./build.sh mono.corelib+libs.pretest -rc debug -c release" echo "" echo "" - echo "For more general information, check out https://github.com/dotnet/runtime/blob/master/docs/workflow/README.md" + echo "For more general information, check out https://github.com/dotnet/runtime/blob/main/docs/workflow/README.md" } initDistroRid() diff --git a/eng/native/build-commons.sh b/eng/native/build-commons.sh index 2c2da6bfb2d..c629cd59c50 100755 --- a/eng/native/build-commons.sh +++ b/eng/native/build-commons.sh @@ -50,14 +50,14 @@ check_prereqs() if [[ "$__HostOS" == "OSX" ]]; then # Check presence of pkg-config on the path - command -v pkg-config 2>/dev/null || { echo >&2 "Please install pkg-config before running this script, see https://github.com/dotnet/runtime/blob/master/docs/workflow/requirements/macos-requirements.md"; exit 1; } + command -v pkg-config 2>/dev/null || { echo >&2 "Please install pkg-config before running this script, see https://github.com/dotnet/runtime/blob/main/docs/workflow/requirements/macos-requirements.md"; exit 1; } if ! pkg-config openssl ; then # We export the proper PKG_CONFIG_PATH where openssl was installed by Homebrew # It's important to _export_ it since build-commons.sh is sourced by other scripts such as build-native.sh export PKG_CONFIG_PATH=/usr/local/opt/openssl@1.1/lib/pkgconfig:/usr/local/opt/openssl/lib/pkgconfig # We try again with the PKG_CONFIG_PATH in place, if pkg-config still can't find OpenSSL, exit with an error, cmake won't find OpenSSL either - pkg-config openssl || { echo >&2 "Please install openssl before running this script, see https://github.com/dotnet/runtime/blob/master/docs/workflow/requirements/macos-requirements.md"; exit 1; } + pkg-config openssl || { echo >&2 "Please install openssl before running this script, see https://github.com/dotnet/runtime/blob/main/docs/workflow/requirements/macos-requirements.md"; exit 1; } fi fi diff --git a/eng/native/init-compiler-and-cmake.cmd b/eng/native/init-compiler-and-cmake.cmd index 757e600f107..43e4cf8b8fe 100644 --- a/eng/native/init-compiler-and-cmake.cmd +++ b/eng/native/init-compiler-and-cmake.cmd @@ -50,7 +50,7 @@ if "%VisualStudioVersion%"=="16.0" ( :MissingVersion :: Can't find appropriate VS install echo Error: Visual Studio 2019 required -echo Please see https://github.com/dotnet/runtime/tree/master/docs/workflow/building/libraries for build instructions. +echo Please see https://github.com/dotnet/runtime/tree/main/docs/workflow/building/libraries for build instructions. exit /b 1 :VS2019 @@ -73,7 +73,7 @@ goto FindDIASDK if exist "%VSINSTALLDIR%DIA SDK" goto CheckRepoRoot echo Error: DIA SDK is missing at "%VSINSTALLDIR%DIA SDK". ^ Did you install all the requirements for building on Windows, including the "Desktop Development with C++" workload? ^ -Please see https://github.com/dotnet/runtime/blob/master/docs/workflow/requirements/windows-requirements.md ^ +Please see https://github.com/dotnet/runtime/blob/main/docs/workflow/requirements/windows-requirements.md ^ Another possibility is that you have a parallel installation of Visual Studio and the DIA SDK is there. In this case it ^ may help to copy its "DIA SDK" folder into "%VSINSTALLDIR%" manually, then try again. exit /b 1 diff --git a/eng/pipelines/evaluate-changed-paths.sh b/eng/pipelines/evaluate-changed-paths.sh index 2788db3995a..742ea4caa7e 100755 --- a/eng/pipelines/evaluate-changed-paths.sh +++ b/eng/pipelines/evaluate-changed-paths.sh @@ -30,7 +30,7 @@ set -e usage() { echo "Script that evaluates changed paths and emits an azure devops variable if the changes contained in the current HEAD against the difftarget meet the includepahts/excludepaths filters:" - echo " --difftarget <value> SHA or branch to diff against. (i.e: HEAD^1, origin/master, 0f4hd36, etc.)" + echo " --difftarget <value> SHA or branch to diff against. (i.e: HEAD^1, origin/main, 0f4hd36, etc.)" echo " --excludepaths <value> Escaped list of paths to exclude from diff separated by '+'. (i.e: 'src/libraries/*+'src/installer/*')" echo " --includepaths <value> Escaped list of paths to include on diff separated by '+'. (i.e: 'src/libraries/System.Private.CoreLib/*')" echo " --subset Subset name for which we're evaluating in order to include it in logs" diff --git a/eng/regenerate-download-table.proj b/eng/regenerate-download-table.proj index 860765f104c..892ae9f25ad 100644 --- a/eng/regenerate-download-table.proj +++ b/eng/regenerate-download-table.proj @@ -17,7 +17,7 @@ </PropertyGroup> <ItemGroup> - <Branch Include="Master" Abbr="6.0.X" /> + <Branch Include="Main" Abbr="6.0.X" /> <Platform Include="Windows (x64)" Abbr="win-x64" /> <Platform Include="Windows (x86)" Abbr="win-x86" /> diff --git a/src/coreclr/build-runtime.cmd b/src/coreclr/build-runtime.cmd index 89d9cd24e4d..61e3793dd4e 100644 --- a/src/coreclr/build-runtime.cmd +++ b/src/coreclr/build-runtime.cmd @@ -851,7 +851,7 @@ exit /b 1 :NoDIA echo Error: DIA SDK is missing at "%VSINSTALLDIR%DIA SDK". ^ Did you install all the requirements for building on Windows, including the "Desktop Development with C++" workload? ^ -Please see https://github.com/dotnet/runtime/blob/master/docs/workflow/requirements/windows-requirements.md ^ +Please see https://github.com/dotnet/runtime/blob/main/docs/workflow/requirements/windows-requirements.md ^ Another possibility is that you have a parallel installation of Visual Studio and the DIA SDK is there. In this case it ^ may help to copy its "DIA SDK" folder into "%VSINSTALLDIR%" manually, then try again. exit /b 1 diff --git a/src/coreclr/crossgen-corelib.cmd b/src/coreclr/crossgen-corelib.cmd index 14a018ae88a..882404d697a 100644 --- a/src/coreclr/crossgen-corelib.cmd +++ b/src/coreclr/crossgen-corelib.cmd @@ -261,7 +261,7 @@ exit /b !__exitCode! :NoDIA echo Error: DIA SDK is missing at "%VSINSTALLDIR%DIA SDK". ^ Did you install all the requirements for building on Windows, including the "Desktop Development with C++" workload? ^ -Please see https://github.com/dotnet/runtime/blob/master/docs/workflow/requirements/windows-requirements.md ^ +Please see https://github.com/dotnet/runtime/blob/main/docs/workflow/requirements/windows-requirements.md ^ Another possibility is that you have a parallel installation of Visual Studio and the DIA SDK is there. In this case it ^ may help to copy its "DIA SDK" folder into "%VSINSTALLDIR%" manually, then try again. exit /b 1 diff --git a/src/coreclr/jit/compiler.cpp b/src/coreclr/jit/compiler.cpp index a8b990d2ed0..30acb69d97b 100644 --- a/src/coreclr/jit/compiler.cpp +++ b/src/coreclr/jit/compiler.cpp @@ -4374,7 +4374,7 @@ void Compiler::EndPhase(Phases phase) // code:CILJit::compileMethod function. // // For an overview of the structure of the JIT, see: -// https://github.com/dotnet/runtime/blob/master/docs/design/coreclr/jit/ryujit-overview.md +// https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/jit/ryujit-overview.md // // Also called for inlinees, though they will only be run through the first few phases. // diff --git a/src/coreclr/jit/conventions.txt b/src/coreclr/jit/conventions.txt index d09fdd1b973..3e955b182e1 100644 --- a/src/coreclr/jit/conventions.txt +++ b/src/coreclr/jit/conventions.txt @@ -3,7 +3,7 @@ Coding Conventions" document, that can be used as a template when writing new comments in the JIT source code. The definitive coding conventions document is located here: -https://github.com/dotnet/runtime/blob/master/docs/coding-guidelines/clr-jit-coding-conventions.md +https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/clr-jit-coding-conventions.md ********** Section 7.1.5 TODO comments diff --git a/src/coreclr/scripts/superpmi.py b/src/coreclr/scripts/superpmi.py index a4c59e6df12..8660dd27def 100755 --- a/src/coreclr/scripts/superpmi.py +++ b/src/coreclr/scripts/superpmi.py @@ -11,7 +11,7 @@ # Script to orchestrate SuperPMI collections, replays, asm diffs, and SuperPMI # data management. Note that some of the options provided by this script are # also provided in our SuperPMI collect test. The test can be found here: -# https://github.com/dotnet/runtime/blob/master/src/tests/JIT/superpmi/superpmicollect.cs. +# https://github.com/dotnet/runtime/blob/main/src/tests/JIT/superpmi/superpmicollect.cs. # ################################################################################ ################################################################################ @@ -2664,8 +2664,8 @@ def process_base_jit_path_arg(coreclr_args): 1. Determine the current git hash using: git rev-parse HEAD or use the `-git_hash` argument (call the result `git_hash`). - 2. Determine the baseline: where does this hash meet `master` using: - git merge-base `git_hash` master + 2. Determine the baseline: where does this hash meet `main` using: + git merge-base `git_hash` main or use the `-base_git_hash` argument (call the result `base_git_hash`). 3. If the `-base_git_hash` argument is used, use that directly as the exact git hash of the baseline JIT to use. @@ -2720,7 +2720,7 @@ def process_base_jit_path_arg(coreclr_args): if coreclr_args.base_git_hash is None: # We've got the current hash; figure out the baseline hash. - command = [ "git", "merge-base", current_hash, "master" ] + command = [ "git", "merge-base", current_hash, "main" ] logging.debug("Invoking: %s", " ".join(command)) proc = subprocess.Popen(command, stdout=subprocess.PIPE) stdout_git_merge_base, _ = proc.communicate() diff --git a/src/coreclr/setup_vs_tools.cmd b/src/coreclr/setup_vs_tools.cmd index 802038b0d8c..055a5dd2fb4 100644 --- a/src/coreclr/setup_vs_tools.cmd +++ b/src/coreclr/setup_vs_tools.cmd @@ -31,7 +31,7 @@ if exist %_VSWHERE% ( :call_vs if not exist "%_VSCOMNTOOLS%" ( echo %__MsgPrefix%Error: Visual Studio 2019 required. - echo Please see https://github.com/dotnet/runtime/blob/master/docs/workflow/requirements/windows-requirements.md for build instructions. + echo Please see https://github.com/dotnet/runtime/blob/main/docs/workflow/requirements/windows-requirements.md for build instructions. exit /b 1 ) echo %__MsgPrefix%"%_VSCOMNTOOLS%\VsDevCmd.bat" diff --git a/src/coreclr/tools/Common/Compiler/Logging/MessageContainer.cs b/src/coreclr/tools/Common/Compiler/Logging/MessageContainer.cs index 7f1da04ba32..f9a0ef6f130 100644 --- a/src/coreclr/tools/Common/Compiler/Logging/MessageContainer.cs +++ b/src/coreclr/tools/Common/Compiler/Logging/MessageContainer.cs @@ -49,7 +49,7 @@ namespace ILCompiler.Logging /// Create an error message. /// </summary> /// <param name="text">Humanly readable message describing the error</param> - /// <param name="code">Unique error ID. Please see https://github.com/mono/linker/blob/master/doc/error-codes.md + /// <param name="code">Unique error ID. Please see https://github.com/mono/linker/blob/main/doc/error-codes.md /// for the list of errors and possibly add a new one</param> /// <param name="subcategory">Optionally, further categorize this error</param> /// <param name="origin">Filename, line, and column where the error was found</param> @@ -67,7 +67,7 @@ namespace ILCompiler.Logging /// </summary> /// <param name="context">Context with the relevant warning suppression info.</param> /// <param name="text">Humanly readable message describing the warning</param> - /// <param name="code">Unique warning ID. Please see https://github.com/mono/linker/blob/master/doc/error-codes.md + /// <param name="code">Unique warning ID. Please see https://github.com/mono/linker/blob/main/doc/error-codes.md /// for the list of warnings and possibly add a new one</param> /// /// <param name="origin">Filename or member where the warning is coming from</param> /// <param name="subcategory">Optionally, further categorize this warning</param> diff --git a/src/coreclr/tools/Common/Compiler/Logging/ReferenceSource/MessageContainer.cs b/src/coreclr/tools/Common/Compiler/Logging/ReferenceSource/MessageContainer.cs index e24ff8a4c21..62231f2ce8a 100644 --- a/src/coreclr/tools/Common/Compiler/Logging/ReferenceSource/MessageContainer.cs +++ b/src/coreclr/tools/Common/Compiler/Logging/ReferenceSource/MessageContainer.cs @@ -40,7 +40,7 @@ namespace Mono.Linker /// Create an error message. /// </summary> /// <param name="text">Humanly readable message describing the error</param> - /// <param name="code">Unique error ID. Please see https://github.com/mono/linker/blob/master/doc/error-codes.md + /// <param name="code">Unique error ID. Please see https://github.com/mono/linker/blob/main/doc/error-codes.md /// for the list of errors and possibly add a new one</param> /// <param name="subcategory">Optionally, further categorize this error</param> /// <param name="origin">Filename, line, and column where the error was found</param> @@ -80,7 +80,7 @@ namespace Mono.Linker /// </summary> /// <param name="context">Context with the relevant warning suppression info.</param> /// <param name="text">Humanly readable message describing the warning</param> - /// <param name="code">Unique warning ID. Please see https://github.com/mono/linker/blob/master/doc/error-codes.md + /// <param name="code">Unique warning ID. Please see https://github.com/mono/linker/blob/main/doc/error-codes.md /// for the list of warnings and possibly add a new one</param> /// /// <param name="origin">Filename or member where the warning is coming from</param> /// <param name="subcategory">Optionally, further categorize this warning</param> diff --git a/src/coreclr/tools/ILVerify/README.md b/src/coreclr/tools/ILVerify/README.md index 6f9814027b3..23c22ca4945 100644 --- a/src/coreclr/tools/ILVerify/README.md +++ b/src/coreclr/tools/ILVerify/README.md @@ -46,7 +46,7 @@ The test project itself is under [src/tests/ilverify](../../../tests/ilverify) ### Building and Running Tests -General instructions to build this library can be found [here](https://github.com/dotnet/runtime/blob/master/docs/workflow/testing/coreclr/testing.md). +General instructions to build this library can be found [here](https://github.com/dotnet/runtime/blob/main/docs/workflow/testing/coreclr/testing.md). As the test project is marked with priority=1, simply building the test projects from the root of the project is not enough. For the initial build of priority=1 in release mode, run the following: @@ -120,6 +120,6 @@ All ILVerify issues are labeled with [area-ILVerification](https://github.com/se Useful sources: - [PEVerify source code](https://github.com/lewischeng-ms/sscli/blob/master/clr/src/jit64/newverify.cpp) - - [RyuJIT source code](https://github.com/dotnet/runtime/tree/master/src/coreclr/jit), specifically: [exception handling specific part](https://github.com/dotnet/runtime/blob/master/src/coreclr/jit/jiteh.cpp), [importer.cpp](https://github.com/dotnet/runtime/blob/master/src/coreclr/jit/importer.cpp) (look for `Compiler::ver`, `Verify`, `VerifyOrReturn`, and `VerifyOrReturnSpeculative`), [_typeinfo.h](https://github.com/dotnet/runtime/blob/master/src/coreclr/jit/_typeinfo.h), [typeinfo.cpp](https://github.com/dotnet/runtime/blob/master/src/coreclr/jit/typeinfo.cpp) + - [RyuJIT source code](https://github.com/dotnet/runtime/tree/main/src/coreclr/jit), specifically: [exception handling specific part](https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/jiteh.cpp), [importer.cpp](https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/importer.cpp) (look for `Compiler::ver`, `Verify`, `VerifyOrReturn`, and `VerifyOrReturnSpeculative`), [_typeinfo.h](https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/_typeinfo.h), [typeinfo.cpp](https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/typeinfo.cpp) - [ECMA-335 standard](https://www.ecma-international.org/publications/standards/Ecma-335.htm) - [Expert .NET 2.0 IL Assembler book](http://www.apress.com/us/book/9781590596463) by Serge Lidin diff --git a/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/ReadyToRunMethod.cs b/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/ReadyToRunMethod.cs index 57c71db1f89..18ca5eb3b08 100644 --- a/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/ReadyToRunMethod.cs +++ b/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/ReadyToRunMethod.cs @@ -84,7 +84,7 @@ namespace ILCompiler.Reflection.ReadyToRun /// A runtime function corresponds to a contiguous fragment of code that implements a method. /// </summary> /// <remarks> - /// Based on <a href="https://github.com/dotnet/runtime/blob/master/src/coreclr/pal/inc/pal.h">src/pal/inc/pal.h</a> _RUNTIME_FUNCTION + /// Based on <a href="https://github.com/dotnet/runtime/blob/main/src/coreclr/pal/inc/pal.h">src/pal/inc/pal.h</a> _RUNTIME_FUNCTION /// </remarks> public class RuntimeFunction { diff --git a/src/coreclr/vm/corelib.h b/src/coreclr/vm/corelib.h index 4edc72533ad..3b870b718d1 100644 --- a/src/coreclr/vm/corelib.h +++ b/src/coreclr/vm/corelib.h @@ -16,7 +16,7 @@ // // Note: This file gets parsed by the Mono IL Linker (https://github.com/mono/linker/) which may throw an exception during parsing. -// Specifically, this (https://github.com/mono/linker/blob/master/corebuild/integration/ILLink.Tasks/CreateRuntimeRootDescriptorFile.cs) will try to +// Specifically, this (https://github.com/mono/linker/blob/main/corebuild/integration/ILLink.Tasks/CreateRuntimeRootDescriptorFile.cs) will try to // parse this header, and it may throw an exception while doing that. If you edit this file and get a build failure on msbuild.exe D:\repos\coreclr\build.proj // you might want to check out the parser linked above. // diff --git a/src/coreclr/vm/eetoprofinterfaceimpl.cpp b/src/coreclr/vm/eetoprofinterfaceimpl.cpp index 69de8cb54b6..22708c8d0d9 100644 --- a/src/coreclr/vm/eetoprofinterfaceimpl.cpp +++ b/src/coreclr/vm/eetoprofinterfaceimpl.cpp @@ -15,7 +15,7 @@ // PLEASE READ! // // There are strict rules for how to implement ICorProfilerCallback* wrappers. Please read -// https://github.com/dotnet/runtime/blob/master/docs/design/coreclr/botr/profilability.md +// https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/profilability.md // to understand the rules and why they exist. // // As a reminder, here is a short summary of your responsibilities. Every PUBLIC diff --git a/src/coreclr/vm/namespace.h b/src/coreclr/vm/namespace.h index 951346af1fc..1cb2b1b9234 100644 --- a/src/coreclr/vm/namespace.h +++ b/src/coreclr/vm/namespace.h @@ -4,7 +4,7 @@ // This file defines namespaces used by the runtime. // // Note: This file gets parsed by the Mono IL Linker (https://github.com/mono/linker/) which may throw an exception during parsing. -// Specifically, this (https://github.com/mono/linker/blob/master/corebuild/integration/ILLink.Tasks/CreateRuntimeRootDescriptorFile.cs) will try to +// Specifically, this (https://github.com/mono/linker/blob/main/corebuild/integration/ILLink.Tasks/CreateRuntimeRootDescriptorFile.cs) will try to // parse this header, and it may throw an exception while doing that. If you edit this file and get a build failure on msbuild.exe D:\repos\coreclr\build.proj // you might want to check out the parser linked above. // diff --git a/src/coreclr/vm/proftoeeinterfaceimpl.cpp b/src/coreclr/vm/proftoeeinterfaceimpl.cpp index d97024a7bf7..ac4d9c7727b 100644 --- a/src/coreclr/vm/proftoeeinterfaceimpl.cpp +++ b/src/coreclr/vm/proftoeeinterfaceimpl.cpp @@ -16,7 +16,7 @@ // PLEASE READ! // // There are strict rules for how to implement ICorProfilerInfo* methods. Please read -// https://github.com/dotnet/runtime/blob/master/docs/design/coreclr/botr/profilability.md +// https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/profilability.md // to understand the rules and why they exist. // // As a reminder, here is a short summary of your responsibilities. Every PUBLIC diff --git a/src/coreclr/vm/rexcep.h b/src/coreclr/vm/rexcep.h index da7686af64e..18082af8af7 100644 --- a/src/coreclr/vm/rexcep.h +++ b/src/coreclr/vm/rexcep.h @@ -19,7 +19,7 @@ // // Note: This file gets parsed by the Mono IL Linker (https://github.com/mono/linker/) which may throw an exception during parsing. -// Specifically, this (https://github.com/mono/linker/blob/master/corebuild/integration/ILLink.Tasks/CreateRuntimeRootDescriptorFile.cs) will try to +// Specifically, this (https://github.com/mono/linker/blob/main/corebuild/integration/ILLink.Tasks/CreateRuntimeRootDescriptorFile.cs) will try to // parse this header, and it may throw an exception while doing that. If you edit this file and get a build failure on msbuild.exe D:\repos\coreclr\build.proj // you might want to check out the parser linked above. // diff --git a/src/installer/pkg/THIRD-PARTY-NOTICES.TXT b/src/installer/pkg/THIRD-PARTY-NOTICES.TXT index e756940d903..c58f0920ea4 100644 --- a/src/installer/pkg/THIRD-PARTY-NOTICES.TXT +++ b/src/installer/pkg/THIRD-PARTY-NOTICES.TXT @@ -15,7 +15,7 @@ Copyright (c) .NET Foundation. All rights reserved. Licensed under the Apache License, Version 2.0. Available at -https://github.com/dotnet/aspnetcore/blob/master/LICENSE.txt +https://github.com/dotnet/aspnetcore/blob/main/LICENSE.txt License notice for Slicing-by-8 ------------------------------- diff --git a/src/installer/tests/scripts/linux-test/README.md b/src/installer/tests/scripts/linux-test/README.md index d7537851573..4851921c6d8 100644 --- a/src/installer/tests/scripts/linux-test/README.md +++ b/src/installer/tests/scripts/linux-test/README.md @@ -11,7 +11,7 @@ The options are: * runtime - verification test for .NET Runtime Linux packages
* sdk - verification test for .NET SDK Linux packages
* \<version>
- * latest - install the latest available .NET package from our master repository
+ * latest - install the latest available .NET package from our main repository
* \<number> - install the package corresponding to this version number
* \<command>
* install - verification test for install
diff --git a/src/libraries/Common/src/System/Net/Http/aspnetcore/ReadMe.SharedCode.md b/src/libraries/Common/src/System/Net/Http/aspnetcore/ReadMe.SharedCode.md index 63c31623360..44d726b8552 100644 --- a/src/libraries/Common/src/System/Net/Http/aspnetcore/ReadMe.SharedCode.md +++ b/src/libraries/Common/src/System/Net/Http/aspnetcore/ReadMe.SharedCode.md @@ -13,7 +13,7 @@ dotnet/aspnetcore code paths: - To copy code from dotnet/aspnetcore to dotnet/runtime, set RUNTIME_REPO to the runtime repo root and then run CopyToRuntime.cmd. ## Building dotnet/runtime code: -- https://github.com/dotnet/runtime/tree/master/docs/workflow +- https://github.com/dotnet/runtime/tree/main/docs/workflow - Run *build.cmd* from the root once: `PS D:\github\runtime> .\build.cmd -runtimeConfiguration Release -subset clr+libs` - Build the individual projects: - `PS D:\github\dotnet\src\libraries\Common\tests> dotnet build` diff --git a/src/libraries/Common/tests/System/Net/Prerequisites/README.md b/src/libraries/Common/tests/System/Net/Prerequisites/README.md index 7dbb0924163..b273f0c48b9 100644 --- a/src/libraries/Common/tests/System/Net/Prerequisites/README.md +++ b/src/libraries/Common/tests/System/Net/Prerequisites/README.md @@ -8,11 +8,11 @@ Contains source files for the networking test servers in Azure or a private IIS 1. Open .\Deployment\config.ps1 in an editor. 2. Fill in the _Machine Selection_ section with the names and IP addresses of the target machines. In most cases the default options for _Test Parameters_ should be enough. -Note: the `config.ps1` file has been added to .gitignore to prevent it being updated in the master branch. +Note: the `config.ps1` file has been added to .gitignore to prevent it being updated in the main branch. ### Build the server applications -Prepare the $DOTNET_TEST_NET_CLIENT_Machine as any Dev station following the instructions at https://github.com/dotnet/runtime/blob/master/docs/workflow/requirements/windows-requirements.md. Ensure that you can build and test CoreFX on this machine. +Prepare the $DOTNET_TEST_NET_CLIENT_Machine as any Dev station following the instructions at https://github.com/dotnet/runtime/blob/main/docs/workflow/requirements/windows-requirements.md. Ensure that you can build and test CoreFX on this machine. In addition, you will also need to install the _Azure development_ workload for Visual Studio 2017. From a Visual Studio command prompt: diff --git a/src/libraries/Native/Unix/System.Security.Cryptography.Native/extra_libs.cmake b/src/libraries/Native/Unix/System.Security.Cryptography.Native/extra_libs.cmake index 3162edec02e..5a0776577a9 100644 --- a/src/libraries/Native/Unix/System.Security.Cryptography.Native/extra_libs.cmake +++ b/src/libraries/Native/Unix/System.Security.Cryptography.Native/extra_libs.cmake @@ -26,7 +26,7 @@ macro(append_extra_cryptography_libs NativeLibsExtra) endif() if(NOT OPENSSL_FOUND) - message(FATAL_ERROR "!!! Cannot find libssl and System.Security.Cryptography.Native cannot build without it. Try installing libssl-dev (on Linux, but this may vary by distro) or openssl (on macOS) !!!. See the requirements document for your specific operating system: https://github.com/dotnet/runtime/tree/master/docs/workflow/requirements.") + message(FATAL_ERROR "!!! Cannot find libssl and System.Security.Cryptography.Native cannot build without it. Try installing libssl-dev (on Linux, but this may vary by distro) or openssl (on macOS) !!!. See the requirements document for your specific operating system: https://github.com/dotnet/runtime/tree/main/docs/workflow/requirements.") endif(NOT OPENSSL_FOUND) diff --git a/src/libraries/Native/build-native.cmd b/src/libraries/Native/build-native.cmd index 8568899162a..6b6b74d5f57 100644 --- a/src/libraries/Native/build-native.cmd +++ b/src/libraries/Native/build-native.cmd @@ -73,7 +73,7 @@ if "%VisualStudioVersion%"=="16.0" ( :MissingVersion :: Can't find appropriate VS install echo Error: Visual Studio 2019 required -echo Please see https://github.com/dotnet/runtime/tree/master/docs/workflow/building/libraries for build instructions. +echo Please see https://github.com/dotnet/runtime/tree/main/docs/workflow/building/libraries for build instructions. exit /b 1 :VS2019 @@ -125,7 +125,7 @@ echo %MSBUILD_EMPTY_PROJECT_CONTENT% > "%__artifactsDir%\obj\native\Directory.Bu if exist "%VSINSTALLDIR%DIA SDK" goto FindCMake echo Error: DIA SDK is missing at "%VSINSTALLDIR%DIA SDK". ^ Did you install all the requirements for building on Windows, including the "Desktop Development with C++" workload? ^ -Please see https://github.com/dotnet/runtime/blob/master/docs/workflow/requirements/windows-requirements.md ^ +Please see https://github.com/dotnet/runtime/blob/main/docs/workflow/requirements/windows-requirements.md ^ Another possibility is that you have a parallel installation of Visual Studio and the DIA SDK is there. In this case it ^ may help to copy its "DIA SDK" folder into "%VSINSTALLDIR%" manually, then try again. exit /b 1 diff --git a/src/libraries/System.ComponentModel.Composition/mef_guide/README.md b/src/libraries/System.ComponentModel.Composition/mef_guide/README.md index c8c59ad5209..6eec7db268b 100644 --- a/src/libraries/System.ComponentModel.Composition/mef_guide/README.md +++ b/src/libraries/System.ComponentModel.Composition/mef_guide/README.md @@ -6,4 +6,4 @@ * It is important to recognize that MEF2 is not a new version of MEF1, but instead they serve different purposes. MEF2 is mostly suitable for web apps in order to make them more efficient. MEF1, on the other hand, uses a lot of reflection code in order to import exports, to build catalogs, and to do object instantiations but then it is more flexible in that it accepts cycles. This makes MEF1 a good option for adding dynamic extensions for long running applications. For web apps it is important to have fast response times and we deal with situations where servers might shut down, which is a good use case for MEF2. -* The `System.ComponentModel.Composition` package on nuget is most widely known as MEF1 and was originally shipped for .NET Framework. `Microsoft.Composition` package later became `System.Composition` package and both are known as MEF2. For more information on MEF you can check out the [archive](https://github.com/microsoftarchive/mef) which holds old wiki documentations in it where you can find out more about differences between MEF1 and MEF2 and links to other material. The source code for MEF1 and MEF2 can be found in this repository under [`System.ComponentModel.Composition`](https://github.com/dotnet/runtime/tree/master/src/libraries/System.ComponentModel.Composition) and [`System.Composition`](https://github.com/dotnet/runtime/tree/master/src/libraries/System.Composition) respectively. +* The `System.ComponentModel.Composition` package on nuget is most widely known as MEF1 and was originally shipped for .NET Framework. `Microsoft.Composition` package later became `System.Composition` package and both are known as MEF2. For more information on MEF you can check out the [archive](https://github.com/microsoftarchive/mef) which holds old wiki documentations in it where you can find out more about differences between MEF1 and MEF2 and links to other material. The source code for MEF1 and MEF2 can be found in this repository under [`System.ComponentModel.Composition`](https://github.com/dotnet/runtime/tree/main/src/libraries/System.ComponentModel.Composition) and [`System.Composition`](https://github.com/dotnet/runtime/tree/main/src/libraries/System.Composition) respectively. diff --git a/src/libraries/System.Diagnostics.DiagnosticSource/src/ActivityUserGuide.md b/src/libraries/System.Diagnostics.DiagnosticSource/src/ActivityUserGuide.md index cacc8876c26..789f57ad011 100644 --- a/src/libraries/System.Diagnostics.DiagnosticSource/src/ActivityUserGuide.md +++ b/src/libraries/System.Diagnostics.DiagnosticSource/src/ActivityUserGuide.md @@ -17,7 +17,7 @@ External dependency Activity Id is passed along with the request, so the depende Activities may be created and started/stopped by platform code or frameworks; applications need to be notified about activities events and need to have access to current activity being processed. Therefore code which creates activity also writes corresponding event to `DiagnosticSource`: -- DO - create new `DiagnosticListener` for specific Activity type to allow filtering by activity. E.g Incoming and Outgoing Http Requests should be different DiagnosticListeners. Follow [DiagnosticSource User Guide](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md) to pick a name. +- DO - create new `DiagnosticListener` for specific Activity type to allow filtering by activity. E.g Incoming and Outgoing Http Requests should be different DiagnosticListeners. Follow [DiagnosticSource User Guide](https://github.com/dotnet/runtime/blob/main/src/libraries/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md) to pick a name. - DO - Guard Activity creation and start with call to `DiagnosticSource.IsEnabled` to avoid creating activities when no-one is listening to them and to enable event name-based filtering or sampling. - DO - Use `DiagnosticSource.StartActivity(Activity)` and `DiagnosticSource.StopActivity(Activity)` methods instead of Activity methods to ensure Activity events are always written to `DiagnosticSource`. - DO - pass any necessary context to `DiagnosticListener`, so your application may enrich Activity. For example, in the case of an incoming HTTP request, the application needs an instance of `HttpContext` in order to add custom tags (method, path, user-agent, etc.) @@ -108,7 +108,7 @@ Note that different DiagnosticSources should be used for incoming and outgoing H ## Listening to Activity Events An application may listen to activity events and log them. It can access `Activity.Current` to get information about the current activity. -This follows normal [DiagnosticListener conventions](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md). +This follows normal [DiagnosticListener conventions](https://github.com/dotnet/runtime/blob/main/src/libraries/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md). An application may also add tags and baggage to the current activity when processing an Activity start callback. Note that in the [Incoming Request Sample](#starting-and-stopping-activity), we pass `HttpContext` to DiagnosticSource, so that the application has access to the request properties in order to enrich the current activity. diff --git a/src/libraries/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md b/src/libraries/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md index 11f7b2f25bf..8f98d156cd1 100644 --- a/src/libraries/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md +++ b/src/libraries/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md @@ -15,7 +15,7 @@ instrumenting code. In addition to `DiagnosticSource`, there are two other logging systems provided by Microsoft: 1. `EventSource` [docs](https://msdn.microsoft.com/en-us/library/system.diagnostics.tracing.eventsource(v=vs.110).aspx) - and [src](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs). + and [src](https://github.com/dotnet/runtime/blob/main/src/libraries/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs). `EventSource` has been available since V4.5 of the .NET Runtime and is what is used to instrument the runtime itself. It is designed to be fast and to be strongly typed (payloads are typed, named properties), and to interface with OS logging @@ -374,7 +374,7 @@ Note that using reflection is relatively expensive. However, using reflection is option if the payloads were generated using anonymous types. You can reduce this overhead by making fast, specialized property fetchers either using `PropertyInfo.CreateDelegate` or `ReflectEmit`, but that is beyond the scope of this document. -(See the [PropertySpec](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs#L784) +(See the [PropertySpec](https://github.com/dotnet/runtime/blob/main/src/libraries/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs#L784) class used in the `DiagnosticSourceEventSource` for an example of a fast, delegate-based property fetcher.) #### Filtering @@ -453,5 +453,5 @@ subscribe to any `DiagnosticListener` as well as pluck off particular data items Thus code that is using `System.Diagnostics.Tracing.EventListener` or ETW can get at any information logged with `DiagnosticSource`. -See [DiagnosticSourceEventSource](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs) +See [DiagnosticSourceEventSource](https://github.com/dotnet/runtime/blob/main/src/libraries/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs) for more information on how to use it. diff --git a/src/libraries/System.IO.Ports/tests/Support/TCSupport.cs b/src/libraries/System.IO.Ports/tests/Support/TCSupport.cs index 18d5cf7310d..15f65a77c61 100644 --- a/src/libraries/System.IO.Ports/tests/Support/TCSupport.cs +++ b/src/libraries/System.IO.Ports/tests/Support/TCSupport.cs @@ -109,7 +109,7 @@ namespace Legacy.Support // https://github.com/dotnet/runtime/issues/20149 // https://github.com/dotnet/runtime/issues/20174 // https://github.com/dotnet/runtime/issues/22159 - // hardware tests are currently insufficiently stable on master CI + // hardware tests are currently insufficiently stable on main CI if (loopbackPortName == null && !nullModemPresent) { // We don't have any supporting hardware - disable all the tests which would use just an open port diff --git a/src/libraries/System.Net.Http/src/HttpDiagnosticsGuide.md b/src/libraries/System.Net.Http/src/HttpDiagnosticsGuide.md index 318d791b0bb..c4283a883af 100644 --- a/src/libraries/System.Net.Http/src/HttpDiagnosticsGuide.md +++ b/src/libraries/System.Net.Http/src/HttpDiagnosticsGuide.md @@ -1,12 +1,12 @@ # HttpClient Diagnostic Instrumentation Users Guide -This document describes `HttpClientHandler` instrumentation with [`DiagnosticSource`](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md). +This document describes `HttpClientHandler` instrumentation with [`DiagnosticSource`](https://github.com/dotnet/runtime/blob/main/src/libraries/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md). # Overview Applications typically log outgoing HTTP requests. Usually, it's done with `DelegatingHandler` implementation that logs every request. However, in an existing system, it may require extensive code changes, since `DelegatingHandler` needs to be added to the `HttpClient` pipeline every time when a new client is created. `DiagnosticListener` instrumentation allows to enable outgoing request tracing with a few lines of code; it also provides the context necessary to correlate logs. -Context is represented as `System.Diagnostics.Activity` class. `Activity` may be started as a child of another `Activity`, and the whole operation is represented with a tree of Activities. You can find more details in the [Activity User Guide](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/ActivityUserGuide.md). +Context is represented as `System.Diagnostics.Activity` class. `Activity` may be started as a child of another `Activity`, and the whole operation is represented with a tree of Activities. You can find more details in the [Activity User Guide](https://github.com/dotnet/runtime/blob/main/src/libraries/System.Diagnostics.DiagnosticSource/src/ActivityUserGuide.md). `Activity` carries useful properties for logging such as `Id`, `Tags`, `Baggage`, start time and parent information. @@ -17,7 +17,7 @@ Instrumentation adds context into the request headers: * *Request-Id* header with `Activity.Id` value * *Correlation-Context* header with `Activity.Baggage` key-value pair list in `k1=v1, k2=v2` format -See [HTTP Protocol proposal](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/HttpCorrelationProtocol.md) for more details. +See [HTTP Protocol proposal](https://github.com/dotnet/runtime/blob/main/src/libraries/System.Diagnostics.DiagnosticSource/src/HttpCorrelationProtocol.md) for more details. ## Subscription Instrumentation is off by default. To enable it, consumer firstly needs to subscribe to a `DiagnosticListener` called *HttpHandlerDiagnosticListener*. diff --git a/src/libraries/System.Net.Http/tests/StressTests/HttpStress/Readme.md b/src/libraries/System.Net.Http/tests/StressTests/HttpStress/Readme.md index bb0078cd9cd..ec19d321160 100644 --- a/src/libraries/System.Net.Http/tests/StressTests/HttpStress/Readme.md +++ b/src/libraries/System.Net.Http/tests/StressTests/HttpStress/Readme.md @@ -20,7 +20,7 @@ $ dotnet run -- -help Note that the stress suite will test the sdk available in the environment, that is to say it will not necessarily test the implementation of the local runtime repo. -To achieve this, we will first need to build a new sdk from source. This can be done [using docker](https://github.com/dotnet/runtime/blob/master/eng/docker/Readme.md). +To achieve this, we will first need to build a new sdk from source. This can be done [using docker](https://github.com/dotnet/runtime/blob/main/eng/docker/Readme.md). ### Running using docker-compose diff --git a/src/libraries/System.Net.Security/tests/StressTests/SslStress/Readme.md b/src/libraries/System.Net.Security/tests/StressTests/SslStress/Readme.md index ee4642289e4..18ed7562ace 100644 --- a/src/libraries/System.Net.Security/tests/StressTests/SslStress/Readme.md +++ b/src/libraries/System.Net.Security/tests/StressTests/SslStress/Readme.md @@ -20,7 +20,7 @@ $ dotnet run -- -help Note that the stress suite will test the sdk available in the environment, that is to say it will not necessarily test the implementation of the local runtime repo. -To achieve this, we will first need to build a new sdk from source. This can be done [using docker](https://github.com/dotnet/runtime/blob/master/eng/docker/Readme.md). +To achieve this, we will first need to build a new sdk from source. This can be done [using docker](https://github.com/dotnet/runtime/blob/main/eng/docker/Readme.md). ### Running using docker-compose diff --git a/src/libraries/System.Private.CoreLib/src/Internal/IO/File.cs b/src/libraries/System.Private.CoreLib/src/Internal/IO/File.cs index a6502f2d7e3..34bff3febe8 100644 --- a/src/libraries/System.Private.CoreLib/src/Internal/IO/File.cs +++ b/src/libraries/System.Private.CoreLib/src/Internal/IO/File.cs @@ -11,7 +11,7 @@ namespace Internal.IO { // // Subsetted clone of System.IO.File for internal runtime use. - // Keep in sync with https://github.com/dotnet/runtime/tree/master/src/libraries/System.IO.FileSystem. + // Keep in sync with https://github.com/dotnet/runtime/tree/main/src/libraries/System.IO.FileSystem. // internal static partial class File { diff --git a/src/libraries/System.Private.CoreLib/src/Internal/Runtime/CompilerServices/Unsafe.cs b/src/libraries/System.Private.CoreLib/src/Internal/Runtime/CompilerServices/Unsafe.cs index e6d1ac84090..c85a4bb4f71 100644 --- a/src/libraries/System.Private.CoreLib/src/Internal/Runtime/CompilerServices/Unsafe.cs +++ b/src/libraries/System.Private.CoreLib/src/Internal/Runtime/CompilerServices/Unsafe.cs @@ -17,7 +17,7 @@ namespace Internal.Runtime.CompilerServices { // // Subsetted clone of System.Runtime.CompilerServices.Unsafe for internal runtime use. - // Keep in sync with https://github.com/dotnet/runtime/tree/master/src/libraries/System.Runtime.CompilerServices.Unsafe. + // Keep in sync with https://github.com/dotnet/runtime/tree/main/src/libraries/System.Runtime.CompilerServices.Unsafe. // /// <summary> diff --git a/src/libraries/System.Private.CoreLib/src/Internal/Win32/RegistryKey.cs b/src/libraries/System.Private.CoreLib/src/Internal/Win32/RegistryKey.cs index f4c779ff6f8..f73025d545b 100644 --- a/src/libraries/System.Private.CoreLib/src/Internal/Win32/RegistryKey.cs +++ b/src/libraries/System.Private.CoreLib/src/Internal/Win32/RegistryKey.cs @@ -15,7 +15,7 @@ using Internal.Win32.SafeHandles; // A minimal version of RegistryKey that supports just what CoreLib needs. // // Internal.Win32 namespace avoids confusion with the public standalone Microsoft.Win32.Registry implementation -// that lives in https://github.com/dotnet/runtime/tree/master/src/libraries/Microsoft.Win32.Registry +// that lives in https://github.com/dotnet/runtime/tree/main/src/libraries/Microsoft.Win32.Registry // namespace Internal.Win32 { diff --git a/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventCounter.cs b/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventCounter.cs index 2f4489afc9e..ecd1dcb3a1a 100644 --- a/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventCounter.cs +++ b/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventCounter.cs @@ -21,7 +21,7 @@ namespace System.Diagnostics.Tracing /// See https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.Tracing/documentation/EventCounterTutorial.md /// for a tutorial guide. /// - /// See https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.Tracing/tests/BasicEventSourceTest/TestEventCounter.cs + /// See https://github.com/dotnet/runtime/blob/main/src/libraries/System.Diagnostics.Tracing/tests/BasicEventSourceTest/TestEventCounter.cs /// which shows tests, which are also useful in seeing actual use. /// </summary> [UnsupportedOSPlatform("browser")] diff --git a/src/libraries/System.Private.CoreLib/src/System/Number.BigInteger.cs b/src/libraries/System.Private.CoreLib/src/System/Number.BigInteger.cs index 51cfa45736a..48305c4aaa2 100644 --- a/src/libraries/System.Private.CoreLib/src/System/Number.BigInteger.cs +++ b/src/libraries/System.Private.CoreLib/src/System/Number.BigInteger.cs @@ -430,7 +430,7 @@ namespace System public static void DivRem(ref BigInteger lhs, ref BigInteger rhs, out BigInteger quo, out BigInteger rem) { // This is modified from the libraries BigIntegerCalculator.DivRem.cs implementation: - // https://github.com/dotnet/runtime/blob/master/src/libraries/System.Runtime.Numerics/src/System/Numerics/BigIntegerCalculator.DivRem.cs + // https://github.com/dotnet/runtime/blob/main/src/libraries/System.Runtime.Numerics/src/System/Numerics/BigIntegerCalculator.DivRem.cs Debug.Assert(!rhs.IsZero()); diff --git a/src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/ModuleInitializerAttribute.cs b/src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/ModuleInitializerAttribute.cs index f0ee87096ff..61680edaf1b 100644 --- a/src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/ModuleInitializerAttribute.cs +++ b/src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/ModuleInitializerAttribute.cs @@ -21,7 +21,7 @@ namespace System.Runtime.CompilerServices /// - The method's effective accessibility must be `internal` or `public`. /// /// The specification for module initializers in the .NET runtime can be found here: - /// https://github.com/dotnet/runtime/blob/master/docs/design/specs/Ecma-335-Augments.md#module-initializer + /// https://github.com/dotnet/runtime/blob/main/docs/design/specs/Ecma-335-Augments.md#module-initializer /// </remarks> [AttributeUsage(AttributeTargets.Method, Inherited = false)] public sealed class ModuleInitializerAttribute : Attribute diff --git a/src/libraries/System.Private.CoreLib/src/System/Runtime/InteropServices/SuppressGCTransitionAttribute.cs b/src/libraries/System.Private.CoreLib/src/System/Runtime/InteropServices/SuppressGCTransitionAttribute.cs index 21b8a615f1a..4c3c2d72e86 100644 --- a/src/libraries/System.Private.CoreLib/src/System/Runtime/InteropServices/SuppressGCTransitionAttribute.cs +++ b/src/libraries/System.Private.CoreLib/src/System/Runtime/InteropServices/SuppressGCTransitionAttribute.cs @@ -32,7 +32,7 @@ namespace System.Runtime.InteropServices /// of the unmanaged function. However, avoiding this transition removes some of the guarantees the runtime /// provides through a normal P/Invoke. When exiting the managed runtime to enter an unmanaged function the /// GC must transition from Cooperative mode into Preemptive mode. Full details on these modes can be found at - /// https://github.com/dotnet/runtime/blob/master/docs/coding-guidelines/clr-code-guide.md#2.1.8. + /// https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/clr-code-guide.md#2.1.8. /// Suppressing the GC transition is an advanced scenario and should not be done without fully understanding /// potential consequences. /// diff --git a/src/libraries/System.Private.CoreLib/src/System/Runtime/Loader/AssemblyLoadContext.cs b/src/libraries/System.Private.CoreLib/src/System/Runtime/Loader/AssemblyLoadContext.cs index 7ef30515b72..dfa08abd5fc 100644 --- a/src/libraries/System.Private.CoreLib/src/System/Runtime/Loader/AssemblyLoadContext.cs +++ b/src/libraries/System.Private.CoreLib/src/System/Runtime/Loader/AssemblyLoadContext.cs @@ -513,7 +513,7 @@ namespace System.Runtime.Loader /// /// The property is stored in an AsyncLocal<AssemblyLoadContext>. This means the setting can be unique for every async or thread in the process. /// - /// For more details see https://github.com/dotnet/runtime/blob/master/docs/design/features/AssemblyLoadContext.ContextualReflection.md + /// For more details see https://github.com/dotnet/runtime/blob/main/docs/design/features/AssemblyLoadContext.ContextualReflection.md /// </remarks> public static AssemblyLoadContext? CurrentContextualReflectionContext => s_asyncLocalCurrent?.Value; diff --git a/src/libraries/System.Private.CoreLib/src/System/Threading/ExecutionContext.cs b/src/libraries/System.Private.CoreLib/src/System/Threading/ExecutionContext.cs index f08b510ed3a..e1950bd4858 100644 --- a/src/libraries/System.Private.CoreLib/src/System/Threading/ExecutionContext.cs +++ b/src/libraries/System.Private.CoreLib/src/System/Threading/ExecutionContext.cs @@ -151,7 +151,7 @@ namespace System.Threading { // Note: ExecutionContext.RunInternal is an extremely hot function and used by every await, ThreadPool execution, etc. // Note: Manual enregistering may be addressed by "Exception Handling Write Through Optimization" - // https://github.com/dotnet/runtime/blob/master/docs/design/features/eh-writethru.md + // https://github.com/dotnet/runtime/blob/main/docs/design/features/eh-writethru.md // Enregister variables with 0 post-fix so they can be used in registers without EH forcing them to stack // Capture references to Thread Contexts diff --git a/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/Ecma335/Encoding/BlobEncoders.cs b/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/Ecma335/Encoding/BlobEncoders.cs index e08505c3f66..40efe2f0ecf 100644 --- a/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/Ecma335/Encoding/BlobEncoders.cs +++ b/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/Ecma335/Encoding/BlobEncoders.cs @@ -915,7 +915,7 @@ namespace System.Reflection.Metadata.Ecma335 public void Type(EntityHandle type, bool isValueType) { // Get the coded index before we start writing anything (might throw argument exception): - // Note: We don't allow TypeSpec as per https://github.com/dotnet/runtime/blob/master/src/libraries/System.Reflection.Metadata/specs/Ecma-335-Issues.md#proposed-specification-change + // Note: We don't allow TypeSpec as per https://github.com/dotnet/runtime/blob/main/src/libraries/System.Reflection.Metadata/specs/Ecma-335-Issues.md#proposed-specification-change int codedIndex = CodedIndex.TypeDefOrRef(type); ClassOrValue(isValueType); @@ -978,7 +978,7 @@ namespace System.Reflection.Metadata.Ecma335 } // Get the coded index before we start writing anything (might throw argument exception): - // Note: We don't allow TypeSpec as per https://github.com/dotnet/runtime/blob/master/src/libraries/System.Reflection.Metadata/specs/Ecma-335-Issues.md#proposed-specification-change + // Note: We don't allow TypeSpec as per https://github.com/dotnet/runtime/blob/main/src/libraries/System.Reflection.Metadata/specs/Ecma-335-Issues.md#proposed-specification-change int codedIndex = CodedIndex.TypeDefOrRef(genericType); Builder.WriteByte((byte)SignatureTypeCode.GenericTypeInstance); diff --git a/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/Ecma335/MetadataBuilder.Tables.cs b/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/Ecma335/MetadataBuilder.Tables.cs index 8ad28470a5a..56405caa852 100644 --- a/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/Ecma335/MetadataBuilder.Tables.cs +++ b/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/Ecma335/MetadataBuilder.Tables.cs @@ -1217,7 +1217,7 @@ namespace System.Reflection.Metadata.Ecma335 /// <param name="language"> /// GUID of the language. /// </param> - /// See https://github.com/dotnet/runtime/blob/master/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md + /// See https://github.com/dotnet/runtime/blob/main/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md public DocumentHandle AddDocument(BlobHandle name, GuidHandle hashAlgorithm, BlobHandle hash, GuidHandle language) { _documentTable.Add(new DocumentRow @@ -1239,7 +1239,7 @@ namespace System.Reflection.Metadata.Ecma335 /// </param> /// <param name="sequencePoints"> /// Sequence Points blob, or nil if the method doesn't have sequence points. - /// See https://github.com/dotnet/runtime/blob/master/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md#sequence-points-blob. + /// See https://github.com/dotnet/runtime/blob/main/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md#sequence-points-blob. /// </param> public MethodDebugInformationHandle AddMethodDebugInformation(DocumentHandle document, BlobHandle sequencePoints) { @@ -1315,7 +1315,7 @@ namespace System.Reflection.Metadata.Ecma335 /// </summary> /// <param name="name">Name of the variable.</param> /// <param name="signature"> - /// LocalConstantSig blob, see https://github.com/dotnet/runtime/blob/master/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md#localconstantsig-blob. + /// LocalConstantSig blob, see https://github.com/dotnet/runtime/blob/main/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md#localconstantsig-blob. /// </param> public LocalConstantHandle AddLocalConstant(StringHandle name, BlobHandle signature) { @@ -1333,7 +1333,7 @@ namespace System.Reflection.Metadata.Ecma335 /// </summary> /// <param name="parentScope">Parent scope handle.</param> /// <param name="imports"> - /// Imports blob, see https://github.com/dotnet/runtime/blob/master/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md#imports-blob. + /// Imports blob, see https://github.com/dotnet/runtime/blob/main/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md#imports-blob. /// </param> public ImportScopeHandle AddImportScope(ImportScopeHandle parentScope, BlobHandle imports) { diff --git a/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/Document.cs b/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/Document.cs index 0e228cca4d9..b33937d1385 100644 --- a/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/Document.cs +++ b/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/Document.cs @@ -9,7 +9,7 @@ namespace System.Reflection.Metadata /// Source document in debug metadata. /// </summary> /// <remarks> - /// See also https://github.com/dotnet/runtime/blob/master/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md#document-table-0x30. + /// See also https://github.com/dotnet/runtime/blob/main/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md#document-table-0x30. /// </remarks> public readonly struct Document { diff --git a/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/ImportScope.cs b/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/ImportScope.cs index ca34a56939f..5afb9c6bd7e 100644 --- a/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/ImportScope.cs +++ b/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/ImportScope.cs @@ -9,7 +9,7 @@ namespace System.Reflection.Metadata /// Lexical scope within which a group of imports are available. Stored in debug metadata. /// </summary> /// <remarks> - /// See https://github.com/dotnet/runtime/blob/master/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md#importscope-table-0x35 + /// See https://github.com/dotnet/runtime/blob/main/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md#importscope-table-0x35 /// </remarks> public readonly struct ImportScope { diff --git a/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/LocalConstant.cs b/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/LocalConstant.cs index 048c053903f..eb9f62c75a6 100644 --- a/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/LocalConstant.cs +++ b/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/LocalConstant.cs @@ -9,7 +9,7 @@ namespace System.Reflection.Metadata /// Local constant. Stored in debug metadata. /// </summary> /// <remarks> - /// See https://github.com/dotnet/runtime/blob/master/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md#localconstant-table-0x34. + /// See https://github.com/dotnet/runtime/blob/main/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md#localconstant-table-0x34. /// </remarks> public readonly struct LocalConstant { diff --git a/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/LocalScope.cs b/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/LocalScope.cs index 8a5468b99b0..fffbc77f202 100644 --- a/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/LocalScope.cs +++ b/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/LocalScope.cs @@ -9,7 +9,7 @@ namespace System.Reflection.Metadata /// Scope of local variables and constants. Stored in debug metadata. /// </summary> /// <remarks> - /// See https://github.com/dotnet/runtime/blob/master/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md#localscope-table-0x32. + /// See https://github.com/dotnet/runtime/blob/main/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md#localscope-table-0x32. /// </remarks> public readonly struct LocalScope { diff --git a/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/LocalVariable.cs b/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/LocalVariable.cs index 623b08f80d2..8f5b283867f 100644 --- a/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/LocalVariable.cs +++ b/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/LocalVariable.cs @@ -9,7 +9,7 @@ namespace System.Reflection.Metadata /// Local variable. Stored in debug metadata. /// </summary> /// <remarks> - /// See https://github.com/dotnet/runtime/blob/master/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md#localvariable-table-0x33. + /// See https://github.com/dotnet/runtime/blob/main/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md#localvariable-table-0x33. /// </remarks> public readonly struct LocalVariable { diff --git a/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/MethodDebugInformation.cs b/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/MethodDebugInformation.cs index 50949a86681..08ba1e0b46f 100644 --- a/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/MethodDebugInformation.cs +++ b/src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/PortablePdb/MethodDebugInformation.cs @@ -9,7 +9,7 @@ namespace System.Reflection.Metadata /// Debug information associated with a method definition. Stored in debug metadata. /// </summary> /// <remarks> - /// See https://github.com/dotnet/runtime/blob/master/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md#methoddebuginformation-table-0x31. + /// See https://github.com/dotnet/runtime/blob/main/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md#methoddebuginformation-table-0x31. /// </remarks> public readonly struct MethodDebugInformation { diff --git a/src/libraries/System.Reflection.Metadata/src/System/Reflection/PortableExecutable/DebugDirectory/DebugDirectoryEntryType.cs b/src/libraries/System.Reflection.Metadata/src/System/Reflection/PortableExecutable/DebugDirectory/DebugDirectoryEntryType.cs index 4caff17e5a3..8c5bbf689eb 100644 --- a/src/libraries/System.Reflection.Metadata/src/System/Reflection/PortableExecutable/DebugDirectory/DebugDirectoryEntryType.cs +++ b/src/libraries/System.Reflection.Metadata/src/System/Reflection/PortableExecutable/DebugDirectory/DebugDirectoryEntryType.cs @@ -20,7 +20,7 @@ namespace System.Reflection.PortableExecutable /// Associated PDB file description. /// </summary> /// <remarks> - /// See https://github.com/dotnet/runtime/blob/master/src/libraries/System.Reflection.Metadata/specs/PE-COFF.md#codeview-debug-directory-entry-type-2 for specification. + /// See https://github.com/dotnet/runtime/blob/main/src/libraries/System.Reflection.Metadata/specs/PE-COFF.md#codeview-debug-directory-entry-type-2 for specification. /// </remarks> CodeView = 2, @@ -44,7 +44,7 @@ namespace System.Reflection.PortableExecutable /// The debug directory entry of type <see cref="Reproducible"/> must have all fields, except for Type zeroed. /// </para> /// <para> - /// See https://github.com/dotnet/runtime/blob/master/src/libraries/System.Reflection.Metadata/specs/PE-COFF.md#deterministic-debug-directory-entry-type-16 for specification. + /// See https://github.com/dotnet/runtime/blob/main/src/libraries/System.Reflection.Metadata/specs/PE-COFF.md#deterministic-debug-directory-entry-type-16 for specification. /// </para> /// </remarks> Reproducible = 16, @@ -59,7 +59,7 @@ namespace System.Reflection.PortableExecutable /// /// Data spans the remainder of the blob and contains a Deflate-compressed Portable PDB. /// - /// See https://github.com/dotnet/runtime/blob/master/src/libraries/System.Reflection.Metadata/specs/PE-COFF.md#embedded-portable-pdb-debug-directory-entry-type-17 for specification. + /// See https://github.com/dotnet/runtime/blob/main/src/libraries/System.Reflection.Metadata/specs/PE-COFF.md#embedded-portable-pdb-debug-directory-entry-type-17 for specification. /// </remarks> EmbeddedPortablePdb = 17, @@ -70,7 +70,7 @@ namespace System.Reflection.PortableExecutable /// The hash can be used to validate that a given PDB file was built with the PE/COFF file and not altered in any way. /// More than one entry can be present, in case multiple PDBs were produced during the build of the PE/COFF file (e.g. private and public symbols). /// - /// See https://github.com/dotnet/runtime/blob/master/src/libraries/System.Reflection.Metadata/specs/PE-COFF.md#pdb-checksum-debug-directory-entry-type-19 for specification. + /// See https://github.com/dotnet/runtime/blob/main/src/libraries/System.Reflection.Metadata/specs/PE-COFF.md#pdb-checksum-debug-directory-entry-type-19 for specification. /// </remarks> PdbChecksum = 19, } diff --git a/src/libraries/System.Reflection.Metadata/tests/Resources/README.md b/src/libraries/System.Reflection.Metadata/tests/Resources/README.md index 08eda7058bf..b2a7d36f882 100644 --- a/src/libraries/System.Reflection.Metadata/tests/Resources/README.md +++ b/src/libraries/System.Reflection.Metadata/tests/Resources/README.md @@ -12,4 +12,4 @@ The same-named source files include the appropriate command to use to build the ## License -Both the source and binary files are licensed as MIT, the same as the rest of the repository. See [LICENSE](https://github.com/dotnet/runtime/blob/master/LICENSE.TXT) at the root of the repo for more information. +Both the source and binary files are licensed as MIT, the same as the rest of the repository. See [LICENSE](https://github.com/dotnet/runtime/blob/main/LICENSE.TXT) at the root of the repo for more information. diff --git a/src/libraries/System.Runtime/tests/TestModule/README.md b/src/libraries/System.Runtime/tests/TestModule/README.md index 4100a6f4051..938d898543a 100644 --- a/src/libraries/System.Runtime/tests/TestModule/README.md +++ b/src/libraries/System.Runtime/tests/TestModule/README.md @@ -8,4 +8,4 @@ You can build this project with msbuild. ## License -Both the source and binary files are licensed as MIT, the same as the rest of the repository. See [LICENSE](https://github.com/dotnet/runtime/blob/master/LICENSE.TXT) at the root of the repo for more information. +Both the source and binary files are licensed as MIT, the same as the rest of the repository. See [LICENSE](https://github.com/dotnet/runtime/blob/main/LICENSE.TXT) at the root of the repo for more information. diff --git a/src/libraries/System.Text.Encodings.Web/tools/updating-encodings.md b/src/libraries/System.Text.Encodings.Web/tools/updating-encodings.md index 1d01b0794e6..e51fb554b2d 100644 --- a/src/libraries/System.Text.Encodings.Web/tools/updating-encodings.md +++ b/src/libraries/System.Text.Encodings.Web/tools/updating-encodings.md @@ -28,7 +28,7 @@ dotnet run --framework netcoreapp3.1 -- "path_to_UnicodeData.txt" ../../src/Syst dotnet run --framework netcoreapp3.1 -- "path_to_Blocks.txt" ../../src/System/Text/Unicode/UnicodeRanges.generated.cs ../../tests/UnicodeRangesTests.generated.cs ``` -5. Update the __ref__ APIs to reflect any new `UnicodeRanges` static properties which were added in the previous step, otherwise the unit test project will not be able to reference them. See https://github.com/dotnet/runtime/blob/master/docs/coding-guidelines/updating-ref-source.md for instructions on how to update the reference assemblies. +5. Update the __ref__ APIs to reflect any new `UnicodeRanges` static properties which were added in the previous step, otherwise the unit test project will not be able to reference them. See https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/updating-ref-source.md for instructions on how to update the reference assemblies. 6. Update the __src/libraries/System.Text.Encodings.Web/tests/System.Text.Encodings.Web.Tests.csproj__ file to reference the new __UnicodeData.txt__ file that was added to the [runtime-assets](https://github.com/dotnet/runtime-assets) repo in step (1). Open the .csproj file in a text editor and replace the `<UnicodeUcdVersion>` property value near the top of the file to reference the new UCD version being consumed. diff --git a/src/libraries/System.Text.Json/docs/KeyConverter_spec.md b/src/libraries/System.Text.Json/docs/KeyConverter_spec.md index 8ac668e1ceb..b382e656e58 100644 --- a/src/libraries/System.Text.Json/docs/KeyConverter_spec.md +++ b/src/libraries/System.Text.Json/docs/KeyConverter_spec.md @@ -77,7 +77,7 @@ The custom `KeyConverter` that calls Utf8Parser underneath performs slightly fas `Dictionary<String, TValue>` results show the same numbers across branches since that still uses `DictionaryOfStringTValueConverter`. -**master:** +**main:** | Type | Method | Mean | Error | StdDev | Median | Min | Max | Gen 0 | Gen 1 | Gen 2 | Allocated | |------------------------------------------- |---------------------------- |---------:|----------:|----------:|---------:|---------:|----------:|-------:|------:|------:|----------:| | WriteDictionary<Dictionary<String, Int32>> | SerializeToUtf8Bytes | 8.737 us | 0.1760 us | 0.1883 us | 8.743 us | 8.487 us | 9.030 us | 0.8867 | - | - | 3760 B | @@ -106,7 +106,7 @@ The custom `KeyConverter` that calls Utf8Parser underneath performs slightly fas ## Deserialize/Read -**master:** +**main:** | Type | Method | Mean | Error | StdDev | Median | Min | Max | Gen 0 | Gen 1 | Gen 2 | Allocated | |------------------------------------------ |------------------------- |---------:|---------:|---------:|---------:|---------:|---------:|-------:|------:|------:|----------:| | ReadDictionary<Dictionary<String, Int32>> | DeserializeFromUtf8Bytes | 22.05 us | 0.439 us | 0.470 us | 22.10 us | 21.23 us | 23.16 us | 4.0872 | - | - | 17176 B | diff --git a/src/libraries/pkg/Microsoft.Windows.Compatibility/Microsoft.Windows.Compatibility.pkgproj b/src/libraries/pkg/Microsoft.Windows.Compatibility/Microsoft.Windows.Compatibility.pkgproj index 6a35c6c3636..4fe2bdb6ba0 100644 --- a/src/libraries/pkg/Microsoft.Windows.Compatibility/Microsoft.Windows.Compatibility.pkgproj +++ b/src/libraries/pkg/Microsoft.Windows.Compatibility/Microsoft.Windows.Compatibility.pkgproj @@ -51,7 +51,7 @@ <NS21PrereleaseLibraryPackage Include="System.ComponentModel.Composition.Registration" /> <NS21PrereleaseLibraryPackage Include="System.Reflection.Context" /> - <!-- Packages we don't build in master anymore --> + <!-- Packages we don't build in main anymore --> <LibraryPackage Include="System.Data.DataSetExtensions"> <Version>4.5.0</Version> </LibraryPackage> diff --git a/src/native/corehost/build.cmd b/src/native/corehost/build.cmd index 0c3207f6bb4..f166cb7acc9 100644 --- a/src/native/corehost/build.cmd +++ b/src/native/corehost/build.cmd @@ -76,7 +76,7 @@ if "%VisualStudioVersion%"=="16.0" ( :MissingVersion :: Can't find required VS install echo Error: Visual Studio 2019 required -echo Please see https://github.com/dotnet/runtime/blob/master/docs/workflow/requirements/windows-requirements.md for build requirements. +echo Please see https://github.com/dotnet/runtime/blob/main/docs/workflow/requirements/windows-requirements.md for build requirements. exit /b 1 :VS2019 @@ -129,7 +129,7 @@ if not exist "%__IntermediatesDir%" md "%__IntermediatesDir%" if exist "%VSINSTALLDIR%DIA SDK" goto FindCMake echo Error: DIA SDK is missing at "%VSINSTALLDIR%DIA SDK". ^ Did you install all the requirements for building on Windows, including the "Desktop Development with C++" workload? ^ -Please see https://github.com/dotnet/runtime/blob/master/docs/workflow/requirements/windows-requirements.md ^ +Please see https://github.com/dotnet/runtime/blob/main/docs/workflow/requirements/windows-requirements.md ^ Another possibility is that you have a parallel installation of Visual Studio and the DIA SDK is there. In this case it ^ may help to copy its "DIA SDK" folder into "%VSINSTALLDIR%" manually, then try again. exit /b 1 diff --git a/src/tests/Common/scripts/arm32_ci_script.sh b/src/tests/Common/scripts/arm32_ci_script.sh index 2818f5b727c..8866d49536d 100755 --- a/src/tests/Common/scripts/arm32_ci_script.sh +++ b/src/tests/Common/scripts/arm32_ci_script.sh @@ -230,7 +230,7 @@ function cross_build_coreclr { ROOTFS_DIR="$__ARMEmulRootfs" CPLUS_INCLUDE_PATH=$LINUX_ARM_INCPATH CXXFLAGS=$LINUX_ARM_CXXFLAGS ./build.sh $__buildArch cross $__verboseFlag $__skipMscorlib clang3.5 $__buildConfig #Reset the code to the upstream version - (set +x; echo 'Rewinding HEAD to master code') + (set +x; echo 'Rewinding HEAD to main code') if [[ "$__buildConfig" == "Release" ]]; then git reset --hard HEAD^ fi diff --git a/src/tests/Common/scripts/run-pmi-diffs.py b/src/tests/Common/scripts/run-pmi-diffs.py index cd24aaf108b..a4f1d3ecde7 100755 --- a/src/tests/Common/scripts/run-pmi-diffs.py +++ b/src/tests/Common/scripts/run-pmi-diffs.py @@ -97,7 +97,7 @@ parser.add_argument('-diff_root', dest='diff_root', default=None) parser.add_argument('-scratch_root', dest='scratch_root', default=None) parser.add_argument('--skip_baseline_build', dest='skip_baseline_build', action='store_true', default=False) parser.add_argument('--skip_diffs', dest='skip_diffs', action='store_true', default=False) -parser.add_argument('-target_branch', dest='target_branch', default='master') +parser.add_argument('-target_branch', dest='target_branch', default='main') parser.add_argument('-commit_hash', dest='commit_hash', default=None) ########################################################################## diff --git a/src/tests/Interop/ReadMe.md b/src/tests/Interop/ReadMe.md index 97db427b8f4..cb73505816a 100644 --- a/src/tests/Interop/ReadMe.md +++ b/src/tests/Interop/ReadMe.md @@ -51,7 +51,7 @@ Testing P/Invoke has two aspects: ### Marshal API -The Marshal API surface area testing is traditionally done via unit testing and far better suited in the [library test folder](https://github.com/dotnet/runtime/tree/master/src/libraries/System.Runtime.InteropServices/tests). Cases where testing the API surface area requires native tests assets will be performed in the [coreclr test folder](https://github.com/dotnet/runtime/tree/master/src/tests/Interop) repo. +The Marshal API surface area testing is traditionally done via unit testing and far better suited in the [library test folder](https://github.com/dotnet/runtime/tree/main/src/libraries/System.Runtime.InteropServices/tests). Cases where testing the API surface area requires native tests assets will be performed in the [coreclr test folder](https://github.com/dotnet/runtime/tree/main/src/tests/Interop) repo. ### NativeLibrary diff --git a/src/tests/JIT/superpmi/runtests.sh b/src/tests/JIT/superpmi/runtests.sh index 5ef800e06c7..35cb82432cc 100644 --- a/src/tests/JIT/superpmi/runtests.sh +++ b/src/tests/JIT/superpmi/runtests.sh @@ -2,7 +2,7 @@ # Run CoreCLR OSS tests on Linux or Mac # Use the instructions here: -# https://github.com/dotnet/runtime/blob/master/docs/workflow/building/coreclr/unix-test-instructions.md +# https://github.com/dotnet/runtime/blob/main/docs/workflow/building/coreclr/unix-test-instructions.md # # Summary: # 1. On Linux/Mac, in coreclr, ./build.sh diff --git a/src/tests/build.cmd b/src/tests/build.cmd index 985568d0712..4e33642e5f9 100644 --- a/src/tests/build.cmd +++ b/src/tests/build.cmd @@ -308,7 +308,7 @@ if defined __SkipManaged goto SkipManagedBuild echo %__MsgPrefix%Starting the Managed Tests Build if not defined VSINSTALLDIR ( - echo %__ErrMsgPrefix%%__MsgPrefix%Error: build.cmd should be run from a Visual Studio Command Prompt. Please see https://github.com/dotnet/runtime/tree/master/docs/workflow for build instructions. + echo %__ErrMsgPrefix%%__MsgPrefix%Error: build.cmd should be run from a Visual Studio Command Prompt. Please see https://github.com/dotnet/runtime/tree/main/docs/workflow for build instructions. exit /b 1 ) set __AppendToLog=false @@ -574,7 +574,7 @@ exit /b 1 :NoDIA echo Error: DIA SDK is missing at "%VSINSTALLDIR%DIA SDK". ^ Did you install all the requirements for building on Windows, including the "Desktop Development with C++" workload? ^ -Please see https://github.com/dotnet/runtime/blob/master/docs/workflow/requirements/windows-requirements.md ^ +Please see https://github.com/dotnet/runtime/blob/main/docs/workflow/requirements/windows-requirements.md ^ Another possibility is that you have a parallel installation of Visual Studio and the DIA SDK is there. In this case it ^ may help to copy its "DIA SDK" folder into "%VSINSTALLDIR%" manually, then try again. exit /b 1 diff --git a/src/tests/run.py b/src/tests/run.py index 78ea7c5228a..bff79dd1ec5 100755 --- a/src/tests/run.py +++ b/src/tests/run.py @@ -32,8 +32,8 @@ # standard please pass the -test_native_bin_location flag to the script. # # Use the instructions here: -# https://github.com/dotnet/runtime/blob/master/docs/workflow/testing/coreclr/windows-test-instructions.md -# https://github.com/dotnet/runtime/blob/master/docs/workflow/testing/coreclr/unix-test-instructions.md +# https://github.com/dotnet/runtime/blob/main/docs/workflow/testing/coreclr/windows-test-instructions.md +# https://github.com/dotnet/runtime/blob/main/docs/workflow/testing/coreclr/unix-test-instructions.md # ################################################################################ ################################################################################ |