Remove some unnecessary slicing from generated Regex code

[stephentoub]

When we're outputting code to match a "multi" (a sequence of multiple characters), we're currently issuing a Slice for the known tracked offset even if that offset is 0. We can skip that nop.

cc: @joperezr, @danmoseley

Matching "defg" as part of a pattern before

// Multi "defg"{byteSpan=global::System.Runtime.InteropServices.MemoryMarshal.AsBytes(textSpan);if((uint)textSpan.Length<4||global::System.Buffers.Binary.BinaryPrimitives.ReadUInt64LittleEndian(byteSpan.Slice(0))!=0x67006600650064ul){gotoNoMatch;}}

Matching "defg" as part of a pattern after

// Multi "defg"{byteSpan=global::System.Runtime.InteropServices.MemoryMarshal.AsBytes(textSpan);if((uint)textSpan.Length<4||global::System.Buffers.Binary.BinaryPrimitives.ReadUInt64LittleEndian(byteSpan)!=0x67006600650064ul){gotoNoMatch;}}

[ghost]

Tagging subscribers to this area: @eerhardt, @dotnet/area-system-text-regularexpressions
See info in area-owners.md if you want to be subscribed.

Issue Details

---

When we're outputting code to match a "multi" (a sequence of multiple characters), we're currently issuing a Slice for the known tracked offset even if that offset is 0. We can skip that nop.

cc: @joperezr, @danmoseley

Matching "defg" as part of a pattern before

// Multi "defg"{byteSpan=global::System.Runtime.InteropServices.MemoryMarshal.AsBytes(textSpan);if((uint)textSpan.Length<4||global::System.Buffers.Binary.BinaryPrimitives.ReadUInt64LittleEndian(byteSpan.Slice(0))!=0x67006600650064ul){gotoNoMatch;}}

Matching "defg" as part of a pattern after

// Multi "defg"{byteSpan=global::System.Runtime.InteropServices.MemoryMarshal.AsBytes(textSpan);if((uint)textSpan.Length<4||global::System.Buffers.Binary.BinaryPrimitives.ReadUInt64LittleEndian(byteSpan)!=0x67006600650064ul){gotoNoMatch;}}

Author:	stephentoub
Assignees:	-
Labels:	area-System.Text.RegularExpressions
Milestone:	7.0.0

[joperezr]

Other than the one comment this looks good. Is it worth adding a unit test that ensures the Slice is not there in this case? (if the tiny optimization doesn't warrant a test that's ok too)

[stephentoub]

Other than the one comment this looks good. Is it worth adding a unit test that ensures the Slice is not there in this case?

This would likely manifest as a test which generated code and compared the generated output to a known string. We currently don't have any such tests. We could certainly add some (separately), though they would likely be a non-trivial time sink until the code has stabilized further, as many changes would likely require regenerating all such pre-generated snippets.