The Terminal's compiler service is checked rather than warned about (#1100) - #1132
Merged
Rafael-SOWNet merged 1 commit intoAug 31, 2026
Conversation
NU1608 has said on every Terminal publish since 2.3.0 that FSharp.Compiler.Service 43.9.300 wants FSharp.Core 9.0.300 and got 10.1, sixteen times per run, and nobody had checked which of the two readings was right. #1100 asked for an hour of running the Terminal against something non-trivial. **It is benign.** A kernel built on the shipped pair compiles generic functions and inference, records, discriminated unions, classes with members, units of measure, async, sequence expressions, list comprehensions, active patterns, tuple destructuring, recursion, `sprintf`, string interpolation, `inline` generic constraints and an object expression over an interface: sixteen of sixteen. It also still refuses a type error and a syntax error, each with the position the Terminal shows to whoever typed it -- a compiler that accepted everything would pass the first sixteen and be useless. So the warning is suppressed, and the claim it was making is carried by `CompilerServiceWorksTest` instead. That is the point of the change rather than a side effect: a warning nobody reads is not a check, and this one had been passing through CI unread for two releases. If FSharp.Core or FSharp.Compiler.Service moves and the pair really does come apart, a test fails where before a sixteen-line warning would have scrolled past again. The constraint cannot be met, which is why suppressing is the option rather than pinning: the 10.1 is the FSharp.Core the F# SDK references implicitly for every F# project, and satisfying FSharp.Compiler.Service would mean pinning two majors back, against the SDK, across the graph. Measured: 16 NU1608 on `dotnet pack` before, 0 after, and 0 NuGet warnings of any kind on the publish path. The tests use a bare kernel deliberately. The Terminal opens `AggressiveOperators` over the top, which rebinds the comparison operators to build expressions, and that is the tool's whole point -- but it means `if a < b then` does not typecheck in the Terminal, which is a separate question and is filed as one rather than smuggled in here. Part of #1100.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #1100, which asked for "an hour of someone running the Terminal against something non-trivial" rather than a fix.
The answer: it is benign
A kernel built on the shipped pair —
FSharp.Compiler.Service 43.9.300besideFSharp.Core 10.1— compiles sixteen of sixteen language features that the compiler service has to implement rather than the parser fold:inlineconstraintsasync, sequence expressions, list comprehensionsOptionsprintf, string interpolation, object expression over an interfaceAnd it still refuses what it should — a type error and a syntax error, each with the position the Terminal shows to whoever typed it. A compiler that accepted everything would pass the first sixteen and be useless, so that half is asserted too.
What changed, and why it is not just a suppression
The warning is suppressed, and the claim it was making now lives in
CompilerServiceWorksTest. That is the point of the change rather than a side effect. A warning nobody reads is not a check, and this one had been passing through CI unread for two releases at sixteen occurrences a run. IfFSharp.CoreorFSharp.Compiler.Servicemoves and the pair really does come apart, a test fails — where before a sixteen-line warning would have scrolled past again.InteractiveTest.ymlalready runsTerminalUnitTests, so this gates on every PR touching it.Suppressing rather than pinning, because the constraint cannot be met. The 10.1 is the
FSharp.Corethe F# SDK references implicitly for every F# project; satisfyingFSharp.Compiler.Service's= 9.0.300would mean pinning two majors back, against the SDK, across the whole graph.The
.fsprojcomment records what was measured and says the test is what to believe if the versions move.Measured
dotnet pack, NU1608dotnet pack, NuGet warnings of any kindTerminalUnitTestsOne thing found on the way, filed separately
The tests use a bare kernel deliberately. The Terminal opens
AngouriMath.Interactive.AggressiveOperatorsover the top, which rebinds< > <= >= = <>to build expressions — that is the tool's whole point, and it means ordinary F# containing a comparison does not typecheck once AngouriMath is enabled:Same for
if 1 < 2 then …andList.filter (fun x -> x > 1). That is a deliberate design trade-off rather than a defect of this pairing, so it is filed as its own issue rather than smuggled in here.🤖 Generated with Claude Code
https://claude.ai/code/session_012sonx8iAspMiwRwokT1Ura