diff options
35 files changed, 58 insertions, 58 deletions
diff --git a/Documentation/Profiling/davbr-blog-archive/Creating an IL-rewriting profiler.md b/Documentation/Profiling/davbr-blog-archive/Creating an IL-rewriting profiler.md index 21678cad4e..7af4739d8b 100644 --- a/Documentation/Profiling/davbr-blog-archive/Creating an IL-rewriting profiler.md +++ b/Documentation/Profiling/davbr-blog-archive/Creating an IL-rewriting profiler.md @@ -45,7 +45,7 @@ And then there's the worst of both worlds: when you need to rewrite IL to call i **Q: Has anyone else tried making an IL-rewriting profiler?** -Sure. If you want to learn from other people's experiences, read through the [Building Development and Diagnostic Tools for .Net Forum](http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=868&SiteID=1). Here are some interesting threads: +Sure. If you want to learn from other people's experiences, read through the [Building Development and Diagnostic Tools for .NET Forum](http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=868&SiteID=1). Here are some interesting threads: [http://social.msdn.microsoft.com/Forums/en-NZ/netfxtoolsdev/thread/5f30596b-e7b7-4b1f-b8e1-8172aa8dde31](http://social.msdn.microsoft.com/Forums/en-NZ/netfxtoolsdev/thread/5f30596b-e7b7-4b1f-b8e1-8172aa8dde31) [http://social.msdn.microsoft.com/Forums/en-GB/netfxtoolsdev/thread/c352266f-ded3-4ee2-b2f9-fbeb41a70c27](http://social.msdn.microsoft.com/Forums/en-GB/netfxtoolsdev/thread/c352266f-ded3-4ee2-b2f9-fbeb41a70c27) diff --git a/Documentation/building/cross-building.md b/Documentation/building/cross-building.md index 8554f731a5..9baca18377 100644 --- a/Documentation/building/cross-building.md +++ b/Documentation/building/cross-building.md @@ -139,7 +139,7 @@ The output is at bin/Product/<BuildOS>.arm.Debug/System.Private.CoreLib.dll. ``` lgs@ubuntu ~/git/coreclr/ $ file ./bin/Product/Linux.arm.Debug/System.Private.CoreLib.dll ./bin/Product/Linux.arm.Debug/System.Private.CoreLib.dll: PE32 executable (DLL) - (console) ARMv7 Thumb Mono/.Net assembly, for MS Windows + (console) ARMv7 Thumb Mono/.NET assembly, for MS Windows ``` Building coreclr for Linux ARM Emulator diff --git a/Documentation/building/debugging-instructions.md b/Documentation/building/debugging-instructions.md index a97433300a..86468b6bbf 100644 --- a/Documentation/building/debugging-instructions.md +++ b/Documentation/building/debugging-instructions.md @@ -208,4 +208,4 @@ Using Visual Studio - For managed debugging, there are some settings in Debug->Options, Debugging->General that might be useful: - Uncheck 'Just My Code'. This will allow you debug into the framework libraries. - Check 'Enable .NET Framework Source Stepping.' This will configure the debugger to download symbols and source automatically for runtime framework binaries. If you built the framework yourself this may be irrelevant because you already have all the source on your machine but it doesn't hurt. - - Check 'Suppress JIT optimzation on module load'. This tells the debugger to tell the .NET runtime JIT to generate debuggable code even for modules that may not have been compiled in a 'Debug' configuration by the C# compiler. This code is slower, but it provides much higher fidelity breakpoints, stepping, and local variable access. It is the same difference you see when debugging .Net apps in the 'Debug' project configuration vs. the 'Release' project configuration. + - Check 'Suppress JIT optimzation on module load'. This tells the debugger to tell the .NET runtime JIT to generate debuggable code even for modules that may not have been compiled in a 'Debug' configuration by the C# compiler. This code is slower, but it provides much higher fidelity breakpoints, stepping, and local variable access. It is the same difference you see when debugging .NET apps in the 'Debug' project configuration vs. the 'Release' project configuration. diff --git a/Documentation/building/windows-instructions.md b/Documentation/building/windows-instructions.md index b526148895..afb216fccb 100644 --- a/Documentation/building/windows-instructions.md +++ b/Documentation/building/windows-instructions.md @@ -88,7 +88,7 @@ Powershell version must be 3.0 or higher. This should be the case for Windows 8 ## DotNet Core SDK While not strictly needed to build or test the .NET Core repository, having the .NET Core SDK installed lets you use the dotnet.exe command to run .NET Core applications in the 'normal' way. We use this in the [Using Your Build](../workflow/UsingYourBuild.md) instructions. Visual Studio should have -installed the .NET Core SDK, but in case it did not you can get it from the [Installing the .Net Core SDK](https://www.microsoft.com/net/core) page. +installed the .NET Core SDK, but in case it did not you can get it from the [Installing the .NET Core SDK](https://www.microsoft.com/net/core) page. ## Adding to the default PATH variable diff --git a/Documentation/design-docs/assemblyloadcontext.md b/Documentation/design-docs/assemblyloadcontext.md index cf6c92cda1..c9575c4be6 100644 --- a/Documentation/design-docs/assemblyloadcontext.md +++ b/Documentation/design-docs/assemblyloadcontext.md @@ -18,7 +18,7 @@ Every .NET Core app has a **LoadContext** instance created during .NET Core Runt ### Custom LoadContext For scenarios that wish to have isolation between loaded assemblies, applications can create their own **LoadContext** instance by deriving from **System.Runtime.Loader.AssemblyLoadContext** type and loading the assemblies within that instance. -Multiple assemblies with the same simple name cannot be loaded into a single load context (*Default* or *Custom*). Also, .Net Core ignores strong name token for assembly binding process. +Multiple assemblies with the same simple name cannot be loaded into a single load context (*Default* or *Custom*). Also, .NET Core ignores strong name token for assembly binding process. ## How Load is attempted diff --git a/Documentation/design-docs/code-versioning-profiler-breaking-changes.md b/Documentation/design-docs/code-versioning-profiler-breaking-changes.md index 538693101d..1889e1c4c9 100644 --- a/Documentation/design-docs/code-versioning-profiler-breaking-changes.md +++ b/Documentation/design-docs/code-versioning-profiler-breaking-changes.md @@ -1,6 +1,6 @@ # Code Versioning Profiler Breaking Changes # -The runtime changes done as part of the code versioning feature will cause some (hopefully minor) breaking changes to be visible via the profiler API. My goal is to advertise these coming changes and solicit feedback about what will be easiest for profiler writers to absorb. Currently this feature is only under development in the .Net Core version of the runtime. If you solely support a profiler on full .Net Framework this change doesn't affect you. +The runtime changes done as part of the code versioning feature will cause some (hopefully minor) breaking changes to be visible via the profiler API. My goal is to advertise these coming changes and solicit feedback about what will be easiest for profiler writers to absorb. Currently this feature is only under development in the .NET Core version of the runtime. If you solely support a profiler on full .NET Framework this change doesn't affect you. ## Underlying issue ## diff --git a/Documentation/design-docs/code-versioning.md b/Documentation/design-docs/code-versioning.md index 928f4a5512..4a4594bc5c 100644 --- a/Documentation/design-docs/code-versioning.md +++ b/Documentation/design-docs/code-versioning.md @@ -308,7 +308,7 @@ Generics can cause methods in domain-neutral modules to refer to types in domain CoreCLR is largely moving away from multiple AppDomains but I left the domain distinctions in place for a few reasons: 1. Pragmatically the feature is a partial refactoring of ReJitManager and this is what ReJitManager did. Diverging from ReJitManager's design incurs extra time and risk of new issues. -2. Maybe someday we will want to migrate similar functionality back to the desktop .Net SKU. Desktop supports multiple AppDomains so per-AppDomain handling would be required in that context. +2. Maybe someday we will want to migrate similar functionality back to the desktop .NET SKU. Desktop supports multiple AppDomains so per-AppDomain handling would be required in that context. AppDomain unloading however has not been handled. If CoreCLR supports proper AppDomain unload at some point or the code moves back to desktop runtime we will need to handle this gap. @@ -355,7 +355,7 @@ All other information such as Edit and Continue IL modifications, or a profiler - **Explicit** - These are configuration options that are encoded directly into the version tree data structures so they can be trivially read back at any time. Profiler ReJIT, generic instantiation, and tiered compilation settings are all explicit. - **Ambient** - These are configuration values that are immutable once set and apply to all code versions of the same method. This can be treated the same as if the build stage gave an explicit configuration result for each generated code version, but the policy in that build stage always returns the same answer. Then as a memory footprint optimization rather than save N copies of the same answer in N different versions, the runtime stores the answer once and knows that it applies to all code versions. For example the debugger can set a debuggable codegen flag that causes all methods in a module to jit differently. The runtime stores that flag in the module for efficiency, but we can map it back to the code version concept as if every code version had that flag in it and it happens to be the same for all versions. -- **Unrecorded** - The final case are configuration options that do change per code version, but they aren't recorded in the NativeCodeVersion/ILCodeVersion data structures. Logically this configuration is part of the code version regardless of the runtime's ability trivially access it/compute it on demand. For example a .Net profiler can control whether a particular jitting of a method has Profiler Enter/Leave/Tailcall probes in it based on its response to the FunctionIDMapper2 callback during JIT code generation. If there was already a version of this function generated without ELT and the profiler wanted a new version that does have ELT then the profiler needs to create a new code version. The only technique it has available to create new code versions is to use ReJIT, but ELT isn't part of explicit configuration that ReJIT collects for the new code version. Instead the profiler records in its own data structures that the new ReJIT version should have a certain ELT configuration setting. Whenever code jits that corresponds to this version the runtime will query the profiler and then the profiler will respond with the appropriate ELT setting. In this way the ELT has logically become part of the profiler ReJIT stage configuration even though the runtime has no explicit record of it. Generalizing from this example, the runtime expects that all unrecorded code version configuration can be treated as a hidden portion of the configuration that is supplied by one of the explicitly configured build stages. +- **Unrecorded** - The final case are configuration options that do change per code version, but they aren't recorded in the NativeCodeVersion/ILCodeVersion data structures. Logically this configuration is part of the code version regardless of the runtime's ability trivially access it/compute it on demand. For example a .NET profiler can control whether a particular jitting of a method has Profiler Enter/Leave/Tailcall probes in it based on its response to the FunctionIDMapper2 callback during JIT code generation. If there was already a version of this function generated without ELT and the profiler wanted a new version that does have ELT then the profiler needs to create a new code version. The only technique it has available to create new code versions is to use ReJIT, but ELT isn't part of explicit configuration that ReJIT collects for the new code version. Instead the profiler records in its own data structures that the new ReJIT version should have a certain ELT configuration setting. Whenever code jits that corresponds to this version the runtime will query the profiler and then the profiler will respond with the appropriate ELT setting. In this way the ELT has logically become part of the profiler ReJIT stage configuration even though the runtime has no explicit record of it. Generalizing from this example, the runtime expects that all unrecorded code version configuration can be treated as a hidden portion of the configuration that is supplied by one of the explicitly configured build stages. The runtime's current classification is: diff --git a/Documentation/design-docs/inlining-plans.md b/Documentation/design-docs/inlining-plans.md index 2279c16e37..79116092e9 100644 --- a/Documentation/design-docs/inlining-plans.md +++ b/Documentation/design-docs/inlining-plans.md @@ -31,12 +31,12 @@ overhead. It is anticipated that this work will encompass Machinery, Ability, and Profitability. LLILC does no inlining today. Since we aspire to have LLILC be a -high-performance .Net code generator, we need to enable inlining in +high-performance .NET code generator, we need to enable inlining in LLILC. LLILC can likely leverage much of LLVM's built-in inlining Machinery and Ability, but will need new code for Legality and Profitability. -We envision various scenarios for .Net Code generation that impact +We envision various scenarios for .NET Code generation that impact inlining: a first-tier JIT compiler, a higher-tier JIT compiler, a fast AOT compiler, and an optimizing AOT compiler. Each scenario calls for inlining, but the tradeoffs are different. For a given scenario, @@ -221,7 +221,7 @@ xml or json markup): ``` where `[o]` is a successful inline, `[x]` a failed inline, and -indentation shows the inlining tree. For .Net compilation we'll need +indentation shows the inlining tree. For .NET compilation we'll need some kind of persistent ID for methods, which may not be all that easy to come by. diff --git a/Documentation/design-docs/tiered-compilation.md b/Documentation/design-docs/tiered-compilation.md index fbea857e50..70bb014338 100644 --- a/Documentation/design-docs/tiered-compilation.md +++ b/Documentation/design-docs/tiered-compilation.md @@ -40,11 +40,11 @@ Design ## Historical context ## -Tiered Compilation was prototyped in 2016, introduced into the runtime code in 2017, and offered as an opt-in Preview feature in .Net Core 2.1 RTM in 2018. This design doc was written after the fact. We had been trying to mitigate runtime startup and performance problems for nearly 20 years with various forms of pre-compilation (NGEN, ReadyToRun, MulticoreJit) but this was the first serious foray into using compilation tiers to achieve similar goals. The IL interpreter appears similar but as best I understand it was not primarily targeted at performance, but rather at portability into environments that did not allow jitting. Although the idea of tiered compilation had come up repeatedly in the past it had never gained the degree of consensus/acceptance/momentum necessary to move forward relative to other performance investments. +Tiered Compilation was prototyped in 2016, introduced into the runtime code in 2017, and offered as an opt-in Preview feature in .NET Core 2.1 RTM in 2018. This design doc was written after the fact. We had been trying to mitigate runtime startup and performance problems for nearly 20 years with various forms of pre-compilation (NGEN, ReadyToRun, MulticoreJit) but this was the first serious foray into using compilation tiers to achieve similar goals. The IL interpreter appears similar but as best I understand it was not primarily targeted at performance, but rather at portability into environments that did not allow jitting. Although the idea of tiered compilation had come up repeatedly in the past it had never gained the degree of consensus/acceptance/momentum necessary to move forward relative to other performance investments. ## Goals ## -1. Improve the steady state and startup performance of typical .Net Core workloads while minimizing regressions. +1. Improve the steady state and startup performance of typical .NET Core workloads while minimizing regressions. 2. Compliment existing precompilation techniques so that developers can leverage the best of both options. diff --git a/Documentation/project-docs/jit-testing.md b/Documentation/project-docs/jit-testing.md index bebcf2106e..a4a560b577 100644 --- a/Documentation/project-docs/jit-testing.md +++ b/Documentation/project-docs/jit-testing.md @@ -25,7 +25,7 @@ all OS platforms. TBD). 5. Tests in CI can be run on private changes (currently tied to PRs; this may be sufficient). -6. Test strategy harmonious with other .Net repo test strategies. +6. Test strategy harmonious with other .NET repo test strategies. 7. Test harness behaves reasonably on test failure. Easy to get at repro steps for subsequent debugging. 8. Tests must allow fine-grained inspection of JIT outputs, for instance @@ -58,7 +58,7 @@ formatting). 2. Some have deep desktop CLR dependence (testing a desktop CLR feature that is not present in CoreCLR). 3. Some require tools not yet available in CoreCLR (ilasm in particular). -4. Some test windows features and won’t be relevant to other OS platforms. +4. Some test windows features and won't be relevant to other OS platforms. 5. Some tests may not be able to be freely redistributed. We have done an internal inventory and identified roughly 1000 tests that @@ -68,7 +68,7 @@ moving these. ### Test script capabilities We need to ensure that the CoreCLR repo contains a suitably -hookable test script. Core testing is driven by xunit but there’s typically a +hookable test script. Core testing is driven by xunit but there's typically a wrapper around this (runtest.cmd today) to facilitate test execution. The proposal is to implement platform-neutral variant of runtest.cmd that diff --git a/src/System.Private.CoreLib/shared/System/Diagnostics/Tracing/TraceLogging/PropertyValue.cs b/src/System.Private.CoreLib/shared/System/Diagnostics/Tracing/TraceLogging/PropertyValue.cs index daa6d9736a..0f87ea58db 100644 --- a/src/System.Private.CoreLib/shared/System/Diagnostics/Tracing/TraceLogging/PropertyValue.cs +++ b/src/System.Private.CoreLib/shared/System/Diagnostics/Tracing/TraceLogging/PropertyValue.cs @@ -185,7 +185,7 @@ namespace System.Diagnostics.Tracing /// <summary> /// Gets a delegate that gets the value of a property of a value type. We unfortunately cannot avoid boxing the value type, /// without making this generic over the value type. That would result in a large number of generic instantiations, and furthermore - /// does not work correctly on .Net Native (we cannot express the needed instantiations in an rd.xml file). We expect that user-defined + /// does not work correctly on .NET Native (we cannot express the needed instantiations in an rd.xml file). We expect that user-defined /// value types will be rare, and in any case the boxing only happens for events that are actually enabled. /// </summary> private static Func<PropertyValue, PropertyValue> GetBoxedValueTypePropertyGetter(PropertyInfo property) @@ -202,7 +202,7 @@ namespace System.Diagnostics.Tracing /// <summary> /// For properties of reference types, we use a generic helper class to get the value. This enables us to use MethodInfo.CreateDelegate - /// to build a fast getter. We can get away with this on .Net Native, because we really only need one runtime instantiation of the + /// to build a fast getter. We can get away with this on .NET Native, because we really only need one runtime instantiation of the /// generic type, since it's only instantiated over reference types (and thus all instances are shared). /// </summary> /// <param name="property"></param> diff --git a/src/System.Private.CoreLib/shared/System/Globalization/CalendarData.Windows.cs b/src/System.Private.CoreLib/shared/System/Globalization/CalendarData.Windows.cs index 3702ee431f..403e0e3583 100644 --- a/src/System.Private.CoreLib/shared/System/Globalization/CalendarData.Windows.cs +++ b/src/System.Private.CoreLib/shared/System/Globalization/CalendarData.Windows.cs @@ -365,7 +365,7 @@ namespace System.Globalization // // Get the native day names // - // NOTE: There's a disparity between .Net & windows day orders, the input day should + // NOTE: There's a disparity between .NET & windows day orders, the input day should // start with Sunday // // Parameters: diff --git a/src/ToolBox/SOS/Strike/apollososdocs.txt b/src/ToolBox/SOS/Strike/apollososdocs.txt index 6ed1dcc9e2..d2ac481ef1 100644 --- a/src/ToolBox/SOS/Strike/apollososdocs.txt +++ b/src/ToolBox/SOS/Strike/apollososdocs.txt @@ -1208,8 +1208,8 @@ method of my application. How can I do this?" see the breakpoint listed. You can specify breakpoints by file and line number if: - a) You have some version of .Net Framework installed on your machine. Any OS from - Vista onwards should have .Net Framework installed by default. + a) You have some version of .NET Framework installed on your machine. Any OS from + Vista onwards should have .NET Framework installed by default. b) You have PDBs for the managed modules that need breakpoints, and your symbol path points to those PDBs. This is often easier than module and method name syntax. For example: diff --git a/src/ToolBox/SOS/Strike/sosdocs.txt b/src/ToolBox/SOS/Strike/sosdocs.txt index cf3f079a76..f03d0731f4 100644 --- a/src/ToolBox/SOS/Strike/sosdocs.txt +++ b/src/ToolBox/SOS/Strike/sosdocs.txt @@ -1198,8 +1198,8 @@ method of my application. How can I do this?" see the breakpoint listed. You can specify breakpoints by file and line number if: - a) You have some version of .Net Framework installed on your machine. Any OS from - Vista onwards should have .Net Framework installed by default. + a) You have some version of .NET Framework installed on your machine. Any OS from + Vista onwards should have .NET Framework installed by default. b) You have PDBs for the managed modules that need breakpoints, and your symbol path points to those PDBs. This is often easier than module and method name syntax. For example: diff --git a/src/debug/ee/debugger.cpp b/src/debug/ee/debugger.cpp index 63aa8c256c..d1eabb2d00 100644 --- a/src/debug/ee/debugger.cpp +++ b/src/debug/ee/debugger.cpp @@ -977,7 +977,7 @@ Debugger::Debugger() //------------------------------------------------------------------------------ // Metadata data structure version numbers // - // 1 - initial state of the layouts ( .Net 4.5.2 ) + // 1 - initial state of the layouts ( .NET Framework 4.5.2 ) // // as data structure layouts change, add a new version number // and comment the changes diff --git a/src/inc/mscorsvc.idl b/src/inc/mscorsvc.idl index 48eada4f6f..33ded4247f 100644 --- a/src/inc/mscorsvc.idl +++ b/src/inc/mscorsvc.idl @@ -2,7 +2,7 @@ // The .NET Foundation licenses this file to you under the MIT license. // See the LICENSE file in the project root for more information. /* -------------------------------------------------------------------------- * - * Microsoft .Net Framework Service + * Microsoft .NET Framework Service * -------------------------------------------------------------------------- */ #ifndef IN_MSCOREE diff --git a/src/inc/registrywrapper.h b/src/inc/registrywrapper.h index 6b284506bb..0fbeee2356 100644 --- a/src/inc/registrywrapper.h +++ b/src/inc/registrywrapper.h @@ -4,7 +4,7 @@ //***************************************************************************** // File: registrywrapper.h // -// Wrapper around Win32 Registry Functions allowing redirection of .Net +// Wrapper around Win32 Registry Functions allowing redirection of .NET // Framework root registry location // //***************************************************************************** diff --git a/src/jit/importer.cpp b/src/jit/importer.cpp index 9c2236d5a7..08830deb9a 100644 --- a/src/jit/importer.cpp +++ b/src/jit/importer.cpp @@ -4143,7 +4143,7 @@ GenTree* Compiler::impMathIntrinsic(CORINFO_METHOD_HANDLE method, // Intrinsics that are not implemented directly by target instructions will // be re-materialized as users calls in rationalizer. For prefixed tail calls, // don't do this optimization, because - // a) For back compatibility reasons on desktop.Net 4.6 / 4.6.1 + // a) For back compatibility reasons on desktop .NET Framework 4.6 / 4.6.1 // b) It will be non-trivial task or too late to re-materialize a surviving // tail prefixed GT_INTRINSIC as tail call in rationalizer. if (!IsIntrinsicImplementedByUserCall(intrinsicID) || !tailCall) diff --git a/src/tools/metainfo/metainfo.cpp b/src/tools/metainfo/metainfo.cpp index ab2d73ad9d..afca3bf54a 100644 --- a/src/tools/metainfo/metainfo.cpp +++ b/src/tools/metainfo/metainfo.cpp @@ -26,7 +26,7 @@ void DisplayArchive(__in_z __in wchar_t* szFile, ULONG DumpFilter, __in_z __in_o void PrintLogo() { - printf("Microsoft (R) .Net Frameworks Runtime Meta Data Dump Utility Version %s\n", VER_FILEVERSION_STR); + printf("Microsoft (R) .NET Frameworks Runtime Meta Data Dump Utility Version %s\n", VER_FILEVERSION_STR); printf("%S", VER_LEGALCOPYRIGHT_LOGO_STR_L); printf("\n"); }// PrintLogo diff --git a/src/utilcode/registrywrapper.cpp b/src/utilcode/registrywrapper.cpp index b3c4b42946..0d94a44dc1 100644 --- a/src/utilcode/registrywrapper.cpp +++ b/src/utilcode/registrywrapper.cpp @@ -6,7 +6,7 @@ // // -// Wrapper around Win32 Registry Functions allowing redirection of .Net +// Wrapper around Win32 Registry Functions allowing redirection of .NET // Framework root registry location // // Notes on Offline Ngen Implementation: @@ -55,7 +55,7 @@ // has made incompatible changes here, such as moving the location or redefining // values, we would break. // - Accesses from C:\Windows\System32 and C:\Windows\Syswow64 and HKCU -// HKCU does not contain any .Net Framework settings (Microsoft\.NETFramework +// HKCU does not contain any .NET Framework settings (Microsoft\.NETFramework // is empty). // There are various files accessed from C:\Windows\System32 and these are a // function of the OS loader. We load an executable and it automatically diff --git a/src/vm/ceeload.h b/src/vm/ceeload.h index 6bf5fbdd3b..c3a9609ba0 100644 --- a/src/vm/ceeload.h +++ b/src/vm/ceeload.h @@ -187,7 +187,7 @@ typedef DPTR(struct LookupMapBase) PTR_LookupMapBase; // importantly we cannot mutate compressed entries (for obvious reasons). Many of the lookup maps are only // partially populated at ngen time or otherwise might be updated at runtime and thus are not candidates. // -// In the threshhold timeframe (predicted to be .Net 4.5.3 at the time of writing), we added profiler support +// In the threshhold timeframe (predicted to be .NET Framework 4.5.3 at the time of writing), we added profiler support // for adding new types to NGEN images. Historically we could always do this for jitted images, but one of the // blockers for NGEN were the compressed RID maps. We worked around that by supporting multi-node maps in which // the first node is compressed, but all future nodes are uncompressed. The NGENed portion will all land in the diff --git a/src/vm/codeversion.cpp b/src/vm/codeversion.cpp index e5e8a75e80..9fceca5a5b 100644 --- a/src/vm/codeversion.cpp +++ b/src/vm/codeversion.cpp @@ -2589,7 +2589,7 @@ void CodeVersionManager::OnAppDomainExit(AppDomain * pAppDomain) LIMITED_METHOD_CONTRACT; // This would clean up all the allocations we have done and synchronize with any threads that might // still be using the data - _ASSERTE(!".Net Core shouldn't be doing app domain shutdown - if we start doing so this needs to be implemented"); + _ASSERTE(!".NET Core shouldn't be doing app domain shutdown - if we start doing so this needs to be implemented"); } #endif diff --git a/src/vm/compile.cpp b/src/vm/compile.cpp index bebe403b16..47147976bc 100644 --- a/src/vm/compile.cpp +++ b/src/vm/compile.cpp @@ -3050,7 +3050,7 @@ HRESULT NGenModulePdbWriter::WritePDBData() // Currently DiaSymReader does not work properly generating NGEN PDBS unless // the DLL whose PDB is being generated ends in .ni.*. Unfortunately, readyToRun // images do not follow this convention and end up producing bad PDBS. To fix - // this (without changing diasymreader.dll which ships indepdendently of .Net Core) + // this (without changing diasymreader.dll which ships indepdendently of .NET Core) // we copy the file to somethign with this convention before generating the PDB // and delete it when we are done. SString dllPath = pLoadedLayout->GetPath(); diff --git a/src/vm/interpreter.cpp b/src/vm/interpreter.cpp index 2f27b62e39..e0ad0937ac 100644 --- a/src/vm/interpreter.cpp +++ b/src/vm/interpreter.cpp @@ -1658,7 +1658,7 @@ void Interpreter::JitMethodIfAppropriate(InterpreterMethodInfo* interpMethInfo, &status); } // This used to be a synchronous jit and could be made so again if desired, - // but using ASP.Net MusicStore as an example scenario the performance is + // but using ASP .NET MusicStore as an example scenario the performance is // better doing the JIT asynchronously. Given the not-on-by-default nature of the // interpreter I didn't wring my hands too much trying to determine the ideal // policy. diff --git a/src/vm/synch.cpp b/src/vm/synch.cpp index 55d42d73f5..e49428e450 100644 --- a/src/vm/synch.cpp +++ b/src/vm/synch.cpp @@ -18,7 +18,7 @@ void CLREventBase::CreateAutoEvent (BOOL bInitialState // If TRUE, initial stat THROWS; GC_NOTRIGGER; // disallow creation of Crst before EE starts - // Can not assert here. ASP.Net uses our Threadpool before EE is started. + // Can not assert here. ASP.NET uses our Threadpool before EE is started. PRECONDITION((m_handle == INVALID_HANDLE_VALUE)); PRECONDITION((!IsOSEvent())); } @@ -44,7 +44,7 @@ BOOL CLREventBase::CreateAutoEventNoThrow (BOOL bInitialState // If TRUE, initi NOTHROW; GC_NOTRIGGER; // disallow creation of Crst before EE starts - // Can not assert here. ASP.Net uses our Threadpool before EE is started. + // Can not assert here. ASP.NET uses our Threadpool before EE is started. PRECONDITION((m_handle == INVALID_HANDLE_VALUE)); PRECONDITION((!IsOSEvent())); } @@ -70,7 +70,7 @@ void CLREventBase::CreateManualEvent (BOOL bInitialState // If TRUE, initial st THROWS; GC_NOTRIGGER; // disallow creation of Crst before EE starts - // Can not assert here. ASP.Net uses our Threadpool before EE is started. + // Can not assert here. ASP.NET uses our Threadpool before EE is started. PRECONDITION((m_handle == INVALID_HANDLE_VALUE)); PRECONDITION((!IsOSEvent())); } @@ -93,7 +93,7 @@ BOOL CLREventBase::CreateManualEventNoThrow (BOOL bInitialState // If TRUE, ini NOTHROW; GC_NOTRIGGER; // disallow creation of Crst before EE starts - // Can not assert here. ASP.Net uses our Threadpool before EE is started. + // Can not assert here. ASP.NET uses our Threadpool before EE is started. PRECONDITION((m_handle == INVALID_HANDLE_VALUE)); PRECONDITION((!IsOSEvent())); } @@ -220,7 +220,7 @@ void CLREventBase::CreateOSAutoEvent (BOOL bInitialState // If TRUE, initial st } CONTRACTL_END; - // Can not assert here. ASP.Net uses our Threadpool before EE is started. + // Can not assert here. ASP.NET uses our Threadpool before EE is started. //_ASSERTE (g_fEEStarted); SetOSEvent(); @@ -269,7 +269,7 @@ void CLREventBase::CreateOSManualEvent (BOOL bInitialState // If TRUE, initial } CONTRACTL_END; - // Can not assert here. ASP.Net uses our Threadpool before EE is started. + // Can not assert here. ASP.NET uses our Threadpool before EE is started. //_ASSERTE (g_fEEStarted); SetOSEvent(); diff --git a/tests/dir.props b/tests/dir.props index bef7afc53e..cb56369af5 100644 --- a/tests/dir.props +++ b/tests/dir.props @@ -19,7 +19,7 @@ Switching to the .NET Core version of the BuildTools tasks seems to break numerous scenarios, such as VS intellisense and resource designer as well as running the build on mono. Until we can get these sorted out we will continue using the .NET 4.5 version of the tasks. - It also breaks building any C# project with dotnet.exe on Windows. The windows version of BuildTools doesn't appear to download the .Net Core + It also breaks building any C# project with dotnet.exe on Windows. The windows version of BuildTools doesn't appear to download the .NET Core Roslyn NuGet package which has a Csc task supporting OverrideToolHost, but the default BuildTools CSharpCore targets file does specify OverrideToolHost. The result is that building anything in C# when RunningOnCore=true on Windows fails in Csc task with a parameter not supported error. diff --git a/tests/scripts/format.py b/tests/scripts/format.py index b622cf4625..5ed90968c9 100644 --- a/tests/scripts/format.py +++ b/tests/scripts/format.py @@ -69,7 +69,7 @@ def main(argv): my_env = os.environ - # Download .Net CLI + # Download .NET CLI dotnetcliUrl = "" dotnetcliFilename = "" @@ -88,7 +88,7 @@ def main(argv): if not os.path.isdir(dotnetcliPath): raise - print("Downloading .Net CLI") + print("Downloading .NET CLI") if platform == 'Linux': dotnetcliUrl = "https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.402/dotnet-sdk-2.1.402-linux-x64.tar.gz" dotnetcliFilename = os.path.join(dotnetcliPath, 'dotnetcli-jitutils.tar.gz') @@ -106,10 +106,10 @@ def main(argv): urlretrieve(dotnetcliUrl, dotnetcliFilename) if not os.path.isfile(dotnetcliFilename): - print("Did not download .Net CLI!") + print("Did not download .NET CLI!") return -1 - # Install .Net CLI + # Install .NET CLI if platform == 'Linux' or platform == 'OSX': tar = tarfile.open(dotnetcliFilename) @@ -127,7 +127,7 @@ def main(argv): if not os.path.isfile(os.path.join(dotnetcliPath, dotnet)): - print("Did not extract .Net CLI from download") + print("Did not extract .NET CLI from download") return -1 # Download bootstrap diff --git a/tests/scripts/run-pmi-diffs.py b/tests/scripts/run-pmi-diffs.py index d1e5954b93..e02f409dc3 100755 --- a/tests/scripts/run-pmi-diffs.py +++ b/tests/scripts/run-pmi-diffs.py @@ -437,7 +437,7 @@ def do_pmi_diffs(): # Download .NET CLI - log('Downloading .Net CLI') + log('Downloading .NET CLI') dotnetcliUrl = "" dotnetcliFilename = "" @@ -469,12 +469,12 @@ def do_pmi_diffs(): urlretrieve(dotnetcliUrl, dotnetcliFilename) if not os.path.isfile(dotnetcliFilename): - log('ERROR: Did not download .Net CLI') + log('ERROR: Did not download .NET CLI') return 1 - # Install .Net CLI + # Install .NET CLI - log('Unpacking .Net CLI') + log('Unpacking .NET CLI') if not testing: if Is_windows: @@ -486,7 +486,7 @@ def do_pmi_diffs(): tar.close() if not os.path.isfile(os.path.join(dotnetcliPath, dotnet_tool)): - log('ERROR: did not extract .Net CLI from download') + log('ERROR: did not extract .NET CLI from download') return 1 # Add dotnet CLI to PATH we'll use to spawn processes. diff --git a/tests/src/JIT/Methodical/cctor/misc/testlib.cs b/tests/src/JIT/Methodical/cctor/misc/testlib.cs index c5fb330579..5035f185ad 100644 --- a/tests/src/JIT/Methodical/cctor/misc/testlib.cs +++ b/tests/src/JIT/Methodical/cctor/misc/testlib.cs @@ -33,7 +33,7 @@ namespace Precise } Console.WriteLine("in .cctor(), measure.a is {0}", measure.a); Console.WriteLine("Current thread is {0}", Thread.CurrentThread.Name); - // Following two lines commented because not available in .Net Core + // Following two lines commented because not available in .NET Core // Console.WriteLine("Calling assembly is {0}", Assembly.GetCallingAssembly().FullName); // Console.WriteLine("This assembly is {0}", Assembly.GetExecutingAssembly().FullName); measure.a += 8; diff --git a/tests/src/JIT/Performance/CodeQuality/BenchmarksGame/regex-redux/regex-redux-5.cs b/tests/src/JIT/Performance/CodeQuality/BenchmarksGame/regex-redux/regex-redux-5.cs index 841db0897a..47e2bace0a 100644 --- a/tests/src/JIT/Performance/CodeQuality/BenchmarksGame/regex-redux/regex-redux-5.cs +++ b/tests/src/JIT/Performance/CodeQuality/BenchmarksGame/regex-redux/regex-redux-5.cs @@ -29,7 +29,7 @@ namespace BenchmarksGame { static Regex regex(string re) { - // Not compiled on .Net Core, hence poor benchmark results. + // Not compiled on .NET Core, hence poor benchmark results. return new Regex(re, RegexOptions.Compiled); } diff --git a/tests/src/Loader/classloader/generics/Instantiation/Nesting/NestedGenericClasses.csproj b/tests/src/Loader/classloader/generics/Instantiation/Nesting/NestedGenericClasses.csproj index f376265528..aff76cd327 100644 --- a/tests/src/Loader/classloader/generics/Instantiation/Nesting/NestedGenericClasses.csproj +++ b/tests/src/Loader/classloader/generics/Instantiation/Nesting/NestedGenericClasses.csproj @@ -13,7 +13,7 @@ <CLRTestKind>BuildAndRun</CLRTestKind> <CLRTestPriority>1</CLRTestPriority> - <!-- Test fails to build on .Net Core 3.0 preview3 --> + <!-- Test fails to build on .NET Core 3.0 preview3 --> <DisableProjectBuild Condition="'$(__BuildOS)' == 'OSX'">true</DisableProjectBuild> </PropertyGroup> <ItemGroup> diff --git a/tests/src/Loader/classloader/generics/Instantiation/Nesting/NestedGenericStructs.csproj b/tests/src/Loader/classloader/generics/Instantiation/Nesting/NestedGenericStructs.csproj index e3a657319a..c608d69e59 100644 --- a/tests/src/Loader/classloader/generics/Instantiation/Nesting/NestedGenericStructs.csproj +++ b/tests/src/Loader/classloader/generics/Instantiation/Nesting/NestedGenericStructs.csproj @@ -13,7 +13,7 @@ <CLRTestKind>BuildAndRun</CLRTestKind> <CLRTestPriority>1</CLRTestPriority> - <!-- Test fails to build on .Net Core 3.0 preview3 --> + <!-- Test fails to build on .NET Core 3.0 preview3 --> <DisableProjectBuild Condition="'$(__BuildOS)' == 'OSX'">true</DisableProjectBuild> </PropertyGroup> <ItemGroup> diff --git a/tests/src/Loader/classloader/generics/Instantiation/Nesting/NestedGenericTypesMix.csproj b/tests/src/Loader/classloader/generics/Instantiation/Nesting/NestedGenericTypesMix.csproj index 7d59baaa49..8099668004 100644 --- a/tests/src/Loader/classloader/generics/Instantiation/Nesting/NestedGenericTypesMix.csproj +++ b/tests/src/Loader/classloader/generics/Instantiation/Nesting/NestedGenericTypesMix.csproj @@ -13,7 +13,7 @@ <CLRTestKind>BuildAndRun</CLRTestKind> <CLRTestPriority>1</CLRTestPriority> - <!-- Test fails to build on .Net Core 3.0 preview3 --> + <!-- Test fails to build on .NET Core 3.0 preview3 --> <DisableProjectBuild Condition="'$(__BuildOS)' == 'OSX'">true</DisableProjectBuild> </PropertyGroup> diff --git a/tests/src/performance/Scenario/JitBench/unofficial_dotnet/README.md b/tests/src/performance/Scenario/JitBench/unofficial_dotnet/README.md index fd86d7bf37..bc961abd67 100644 --- a/tests/src/performance/Scenario/JitBench/unofficial_dotnet/README.md +++ b/tests/src/performance/Scenario/JitBench/unofficial_dotnet/README.md @@ -185,4 +185,4 @@ CoreCLR CI machines don't currently support building netcoreapp2.0 projects auth C:\Program Files\dotnet\sdk\1.1.0\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.TargetFrameworkInference.targets(112,5): error : The current .NET SDK does not support targeting .NET Core 2.0. Either target .NET Core 1.1 or lower, or use a version of the .NET SDK that supports .NET Core 2.0. [D:\j\workspace\x64_checked_w---eac6a79c\tests\src\performance\Scenario\JitBench\JitBench.csproj] -I assume the CI machines have fairly old SDK tools installed but I didn't have enough time to keep investigating these build issues. From I can tell if you have .Net Core 2.0+ SDK installed on your machine this build works fine from the command line and from VS. +I assume the CI machines have fairly old SDK tools installed but I didn't have enough time to keep investigating these build issues. From I can tell if you have .NET Core 2.0+ SDK installed on your machine this build works fine from the command line and from VS. diff --git a/tests/src/performance/linkbench/scripts/clone.cmd b/tests/src/performance/linkbench/scripts/clone.cmd index 902fad470e..6b69c0f9f2 100644 --- a/tests/src/performance/linkbench/scripts/clone.cmd +++ b/tests/src/performance/linkbench/scripts/clone.cmd @@ -17,7 +17,7 @@ popd exit /b %EXITCODE% :DotNet -REM We clone different versions of .Net CLI in order to cope with +REM We clone different versions of .NET CLI in order to cope with REM different runtimes that the benchmarks target, and certain limitations REM in the ILLink/CLI integration and packaging. REM |