From a7bb0d56ed5e7687a98255a0e24f8fda158a630d Mon Sep 17 00:00:00 2001 From: Genevieve Warren <24882762+gewarren@users.noreply.github.com> Date: Wed, 18 Sep 2024 18:02:10 -0700 Subject: [PATCH] fix xrefs (#42660) --- docs/core/whats-new/dotnet-9/libraries.md | 6 +++--- docs/core/whats-new/dotnet-9/runtime.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/core/whats-new/dotnet-9/libraries.md b/docs/core/whats-new/dotnet-9/libraries.md index 13e8f3e65665d..74b430954da20 100644 --- a/docs/core/whats-new/dotnet-9/libraries.md +++ b/docs/core/whats-new/dotnet-9/libraries.md @@ -38,7 +38,7 @@ The collection types in .NET gain the following updates for .NET 9: In high-performance code, spans are often used to avoid allocating strings unnecessarily, and lookup tables with types like and are frequently used as caches. However, there has been no safe, built-in mechanism for doing lookups on these collection types with spans. With the new `allows ref struct` feature in C# 13 and new features on these collection types in .NET 9, it's now possible to perform these kinds of lookups. -The following example demonstrates using [Dictionary.GetAlternateLookup](xref:System.Collections.Generic.CollectionExtensions.GetAlternateLookup%60%603(System.Collections.Generic.Dictionary{%60%600,%60%601})). +The following example demonstrates using [Dictionary.GetAlternateLookup](xref:System.Collections.Generic.Dictionary`2.GetAlternateLookup``1). :::code language="csharp" source="../snippets/dotnet-9/csharp/Collections.cs" id="AlternateLookup"::: @@ -671,7 +671,7 @@ public static bool ListContainsItem(ReadOnlySpan span, string item) ## System.Formats -The position or offset of the data in the enclosing stream for a object is now a public property. `TarEntry.DataOffset` returns the position in the entry's archive stream where the entry's first data byte is located. The entry's data is encapsulated in a substream that you can access via , which hides the real position of the data relative to the archive stream. That's enough for most users, but if you need more flexibility and want to know the real starting position of the data in the archive stream, the new `TarEntry.DataOffset` API makes it easy to support features like concurrent access with very large TAR files. +The position or offset of the data in the enclosing stream for a object is now a public property. returns the position in the entry's archive stream where the entry's first data byte is located. The entry's data is encapsulated in a substream that you can access via , which hides the real position of the data relative to the archive stream. That's enough for most users, but if you need more flexibility and want to know the real starting position of the data in the archive stream, the new API makes it easy to support features like concurrent access with very large TAR files. :::code language="csharp" source="../snippets/dotnet-9/csharp/TarEntry.cs" id="DataOffset"::: @@ -691,7 +691,7 @@ The position or offset of the data in the enclosing stream for a --> and `BrotliCompressionOptions` are new types for setting algorithm-specific compression [level](xref:System.IO.Compression.CompressionLevel) and strategy (`Default`, `Filtered`, `HuffmanOnly`, `RunLengthEncoding`, or `Fixed`). These types are aimed at users who want more fine-tuned settings than the only existing option, . + and are new types for setting algorithm-specific compression [level](xref:System.IO.Compression.CompressionLevel) and strategy (`Default`, `Filtered`, `HuffmanOnly`, `RunLengthEncoding`, or `Fixed`). These types are aimed at users who want more fine-tuned settings than the only existing option, . The new compression option types might be expanded in the future. diff --git a/docs/core/whats-new/dotnet-9/runtime.md b/docs/core/whats-new/dotnet-9/runtime.md index 728a04e57de8b..16d3e6d135fdf 100644 --- a/docs/core/whats-new/dotnet-9/runtime.md +++ b/docs/core/whats-new/dotnet-9/runtime.md @@ -310,7 +310,7 @@ The use of `size` in the call to `Sse2.ShiftRightLogical128BitLane` can be subst ### Arm64 SVE support -.NET 9 introduces experimental support for the [Scalable Vector Extension (SVE)](https://en.wikipedia.org/wiki/AArch64#Scalable_Vector_Extension_(SVE)), a SIMD instruction set for ARM64 CPUs. .NET already supported the NEON instruction set, so on [NEON](https://en.wikipedia.org/wiki/ARM_architecture_family#Advanced_SIMD_(Neon))-capable hardware, your applications can leverage 128-bit vector registers. SVE supports flexible vector lengths all the way up to 2048 bits, unlocking more data processing per instruction. In .NET 9, is 128 bits wide when targeting SVE, and future work will enable scaling of its width to match the target machine's vector register size. You can accelerate your .NET applications on SVE-capable hardware using the new `System.Runtime.Intrinsics.Arm.Sve` APIs. +.NET 9 introduces experimental support for the [Scalable Vector Extension (SVE)](https://en.wikipedia.org/wiki/AArch64#Scalable_Vector_Extension_(SVE)), a SIMD instruction set for ARM64 CPUs. .NET already supported the NEON instruction set, so on [NEON](https://en.wikipedia.org/wiki/ARM_architecture_family#Advanced_SIMD_(Neon))-capable hardware, your applications can leverage 128-bit vector registers. SVE supports flexible vector lengths all the way up to 2048 bits, unlocking more data processing per instruction. In .NET 9, is 128 bits wide when targeting SVE, and future work will enable scaling of its width to match the target machine's vector register size. You can accelerate your .NET applications on SVE-capable hardware using the new APIs. > [!NOTE] > SVE support in .NET 9 is experimental. The APIs under `System.Runtime.Intrinsics.Arm.Sve` are marked with , which means they're subject to change in future releases. Additionally, debugger stepping and breakpoints through SVE-generated code might not function properly, resulting in application crashes or corruption of data.