CI is failing, it seem to be a silent SDK upgrade causing the issue

[7sharp9]

PR #445 (the ShipIt build-system work) hit a failing build (ubuntu-latest).
That PR only touches CHANGELOG.md and a few markdown docs, so a real test failure made no sense. Dug into it, and it isn't one. Every PR is going to fail this check right now, regardless of what's in it, until someone deals with this.

What's actually failing

11 tests fail, spread across four libraries that have nothing to do with each other:
GenORDER.Tests, GenCORE.Tests, ZForm.Tests, GenFORM.Tests. Same root error in all of them:

op_HatEquals is the ^= operator from the Aether optics library, which GenCORE.Lib uses in its range/limit code. F# lets you define custom operators like this, but the .NET test runner (Expecto, via reflection) has to find and call it dynamically while discovering tests, rather than the compiler wiring up the call directly the way it does in normal code. That's the part that's seemingly now broken.

Ruled out the obvious explanations

First guess was flakiness. Reran the exact same failed job. Got the exact same 11 failures, same error, same stack trace, both times. A timing issue wouldn't reproduce that precisely twice in a row, so that's out.

Second guess was a dependency bump. Checked paket.lock: Aether is pinned at 8.3.1, FSharp.Core at 10.1.203. CI runs paket restore, which uses the lock file exactly as written rather than re-resolving anything, so the packages didn't move either.

Last known green run, 11 August: .NET Core SDK with version '10.0.302' is already installed.
The failing run, 12 August: Installed version is 10.0.400. (freshly downloaded, not cached, so this is new to the runner)

What actually changed

global.json has:

{ "sdk": { "version": "10.0.0", "rollForward": "latestFeature" } }

Possible fixes:

1. Tighten global.json's rollForward (to patch or disable, say) so a future SDK release can't silently change what CI runs on without a deliberate, reviewed version bump.
2. Fix the GenCORE.Lib optics usage so it works under the newer SDK's reflection behaviour. Doing only option 1 just postpones this until someone next bumps the pinned SDK on purpose.

[halcwb]

@7sharp9

Possible fixes:

Tighten global.json's rollForward (to patch or disable, say) so a future SDK release can't silently change what CI runs on without a deliberate, reviewed version bump.
Fix the GenCORE.Lib optics usage so it works under the newer SDK's reflection behaviour. Doing only option 1 just postpones this until someone next bumps the pinned SDK on purpose.

I think we should do both. First pin the sdk and document the error finding with the new sdk and then fix the underlying error.

For the future we need a more reliable build environment. I am looking at using NIX as a reliable build environment, otherwise we will keep having, "but it works on my computer".

[7sharp9]

@halcwb I'll create a new issue for the actual issue that bumping the SDK causes.

From initial investigation it looks like Aether's entire inline-SRTP machinery (get, set, and compose) is incompatible with the 10.0.400 F# compiler, not a great breakfast accompaniment. SRTP always has a way of running your day.

Someone beat me to log this earlier today: dotnet/fsharp#20253

I think in general SRTP machinery is unreliable and there is no compiler contract to enforce the behaviour being relied on here:

Aether's Optic.get/set/>-> all use the "single-case dummy type + overloaded static members" trick to get ad-hoc polymorphism through SRTP, so any code built this way is inherently more exposed to this class of regression than ordinary generic F# code. This has happened at least several times before.