-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
F# Regressions affecting F#+ #613
Comments
Would it make sense to nudge the CI here and maybe look into adjustments in dotnet/fsharp that would make it easy to test the preview compiler? |
I think it would. Reason is, F#+ uses code in a style that is not covered by dogfooding or by other early users of previews - most of these bugs are reports unlike any other we have received. We would need to raise familiarity with internal workings of F#+ amongst compiler contributors including myself (so that we can identify and isolate issues better), but that would be definitely for the better. If anyone familiar with F#+ would be willing to contribute some scripting snippets to do a basic sanity test of F#+, I will be happy to integrate it as a new CI leg in the compiler. |
Due to the nature of the issues, even two different legs I assume:
WDYT? |
@T-Gro I think it totally makes sense. You can't imagine how hard is for me to anticipate to each new compiler and test everything by hand with F#+, then follow up on fixes. All this using free time which sometimes is quite limited. Also important to mention, Don had the same idea, before you joined the team and there is somewhere a PR that integrates F#+ in the F# compiler test project. It just received some pushback from Phillip at that time and finally got abandoned. But we can definitely revive and improve it. |
The main thing I remember was Don wasn't super eager we use F#+ as motivator for evolving the compiler / language design (on areas like overload resolution, etc.), but I think for catching overload resolution, type inference regressions, and seeing if compatibility with library compiled with older compiler, F#+ is a nice stress test. Overall, a generic infrastructure where we can add to the CI:
This infrastructure would provide high level reporting:
Maybe this would work better if this can be external to the compiler repository upfront, so ultimately it won't be core compiler team owning it, as I know, each such request expands the maintenance area significantly. I think it is still a lot of work to make something like this though. But in meantime, a small thing that checks F#+ in this repository is still good way to know upfront about regressions. |
This one I assume? https://github.com/dotnet/fsharp/pull/5878/files Understandably, there has been pushback on the consequences of such CI leg failing, especially if caused by a F#+ change added since last run(even when hypothetical) and not by the compiler-contributing PR executing the test. I think this is still worth it, and we could do a backdoor where a label "Accept-F#+-Break" would allow merging a PR despite seeing some breaks. IMO still worth a try and we will be wiser after running this for some period of time. Another angle is the one of security and stability implied by running code from a variable location. i.e. choosing a compromise between the various options of what code to build & run exactly:
The same question then applies to the scripts orchestrating it. Thinking this trough, the option I currently like the most:
Upside: Risks and stability can be safely accepted by dotnet/fsharp owners, the code being built is no longer a moving target |
Yes, that's the PR. Actually if you read through, the idea was to always use a specific commit, so changes in the library shouldn't affect the compiler. Don explains in the comments how to achieve that. |
I agree to that. That way, if F#+ pivots this, same mechanism can be also used for other critical parts of the F# library ecosystem (where F#+ still has a special place due to the way it stressed SRTP features). I will have a think on how to smoothly plug in the necessary overrides ( they should be covered here https://github.com/dotnet/fsharp/blob/main/UseLocalCompiler.Directory.Build.props + cleaning global.json references). This set of overrides gives a hint - perharps to CI job being executed could have environment variables pointing to the freshly built compiler artifacts ( |
With the release of F# 9, lot of regressions are being observed.
The idea is to compile a list as much detailed as possible.
F#+ doesn't compiler anymore:
SeqT.lisft
see below more examples of this error.F#+ examples broken:
CEs:
FSharpPlus/docsrc/content/computation-expressions.fsx
Lines 120 to 127 in 1f0fc12
Fails both when using F#+ nuget and when using F#+ compiled with F#9.
More information: The
for
method of themonad.fx
builder is compiled as follow:SeqT:
FSharpPlus/docsrc/content/type-seqt.fsx
Lines 70 to 77 in 1f0fc12
Fails with `type-seqt.fsx(74,61): error FS0001: 'SeqT_V2.SeqT.lift' does not support the type 'Async', because the latter lacks the required (real or built-in) member 'Map'``
Same failure in
FSharpPlus/docsrc/content/type-seqt.fsx
Line 147 in 1f0fc12
Alternatives:
FSharpPlus/docsrc/content/abstraction-alternative.fsx
Line 114 in 1f0fc12
Using F#+ compiled with F#9 ->
abstraction-alternative.fsx(114,24): error FS0001: The type 'string option list' does not support the operator 'choice'
FSharpPlus/docsrc/content/abstraction-alternative.fsx
Line 128 in 1f0fc12
abstraction-alternative.fsx(128,22): error FS0071: Type constraint mismatch when applying the default type 'obj' for a type inference variable. None of the types 'Async<(string list -> string list)>, obj' support the operator '<*>' Consider adding further type constraints
Bitraversable:
FSharpPlus/docsrc/content/abstraction-bitraversable.fsx
Line 87 in 1f0fc12
abstraction-bitraversable.fsx(87,37): error FS0043: No overloads match for method 'Bisequence'.
Misc:
FSharpPlus/docsrc/content/abstraction-misc.fsx
Line 47 in 1f0fc12
abstraction-misc.fsx(47,22): error FS0001: '.Choice' does not support the type 'Result<int,string>', because the latter lacks the required (real or built-in) member 'IsAltLeftZero'
(seems to be the same as the one in Alternatives.Monad:
FSharpPlus/docsrc/content/abstraction-monad.fsx
Line 346 in 1f0fc12
abstraction-monad.fsx(346,16): error FS0001: The type ''a list' does not support the operator 'choice'
Profunctor:
FSharpPlus/docsrc/content/abstraction-traversable.fsx
Lines 110 to 113 in 1f0fc12
FSharpPlus/docsrc/content/abstraction-profunctor.fsx
Line 107 in 1f0fc12
abstraction-profunctor.fsx(107,12): error FS0071: Type constraint mismatch when applying the default type 'obj' for a type inference variable. No overloads match for method 'Map'.
FSharpPlus/docsrc/content/abstraction-profunctor.fsx
Line 109 in 1f0fc12
`abstraction-profunctor.fsx(109,12): error FS0071: Type constraint mismatch when applying the default type 'obj' for a type inference variable. No overloads match for method 'Dimap'.
Traversable:
FSharpPlus/docsrc/content/abstraction-traversable.fsx
Lines 110 to 113 in 1f0fc12
abstraction-traversable.fsx(110,23): error FS0071: Type constraint mismatch when applying the default type 'obj' for a type inference variable. None of the types '(int list -> int list) list, obj' support the operator '<*>' Consider adding further type constraints
abstraction-traversable.fsx(111,23): error FS0071: Type constraint mismatch when applying the default type 'obj' for a type inference variable. None of the types '(int list -> int list) option, obj' support the operator '<*>' Consider adding further type constraints
abstraction-traversable.fsx(112,23): error FS0071: Type constraint mismatch when applying the default type 'obj' for a type inference variable. None of the types '(int list -> int list) list, obj' support the operator '<*>' Consider adding further type constraints
abstraction-traversable.fsx(113,23): error FS0071: Type constraint mismatch when applying the default type 'obj' for a type inference variable. None of the types '(int list -> int list) list, obj' support the operator '<*>' Consider adding further type constraints
ZipApplicative:
FSharpPlus/docsrc/content/abstraction-zipapplicative.fsx
Line 139 in 1f0fc12
abstraction-zipapplicative.fsx(139,65): error FS0193: None of the types 'Async<int>, Async<char>, Async<'a>' support the operator 'Zip'
Testing is not complete. More errors are expected in Tests and maybe in the TypeLevel project
The text was updated successfully, but these errors were encountered: