Wouldn't it be better to use System.Numerics.BitOperations.RotateLeft? It's a JIT intrinsic on dotnet.
We can define static extension polyfill for net472

I have problems with the netstandard build when I tried this:

Go to definition on it in that context yields the following from the System.Collections.Immutable package:

namespace System.Numerics
{
#if !NET
    internal static class BitOperations
    {
        [MethodImpl(MethodImplOptions.AggressiveInlining)]
        public static uint RotateLeft(uint value, int offset) => (value << offset) | (value >> (32 - offset));
    }
#endif
}

Dur, just read your comment again and went ahead and did that in commit 2

I'd add BitOperations to MS.CA.Contracts project. Similar to https://github.com/dotnet/roslyn/blob/main/src/Dependencies/Contracts/ValueTaskExtensions.cs.

That way we can call the dotnet version directly and net472 polyfill will be applied as needed.

Hm, adding a new reference to compiler packages might cause problems. cc @jaredpar

If this is an issue at all, I'm definitely fine closing out this PR as this was just an attempt to remove some hashing code we had copied from the runtime, as I'm attempting to copy some of this code over to razor.

There are VS hurdles to clear if this change were to go forward too, as the test insertion is complaining about optimization data not found for System.IO.Hashing.dll

@tmat indicated he has some context with a similar earlier attempt, so it might be nice to get his input on the difficulties he encountered and whether he thinks this is worth pursuing.

At the very least we should make sure the new DLL is part of the toolset compiler package but I guess it is if it's being inserted into VS. There might be other infra considerations I'm missing though.

Adding a new DLL to the compiler dependency is not cheap. Want to avoid this unless there are significant gains.

The gains were already attained. Switching to System.IO.Hashing pays off debt as discussed here: #70808

Can you forward me the approval?

I really hope we take this. The original copying of code was such an unpleasant hack to work around issues. It was really only meant to be temporary (as can even be seen in the conversation on my PR where we introduced this :)).

I definitely want us to be in the place where if the runtime creates and owns high perf algorithms like this, we can just naturally use them instead of effectively rolling our own :)

If we have the approval I'm okay with taking it for dev18. Just want to make sure we have it before we merge. Haven't seen it yet.

Let me know if was sent and I just missed it.

@tmat -- Can you forward any conversations you've previously had about this approval to this group?

@ToddGrun forwarded the exception request to this group. Think we can close on that being an issue.