search

dotnet / fsharp

The F# compiler, F# core library, F# language service, and F# tooling integration for Visual Studio
https://dotnet.microsoft.com/languages/fsharp
MIT License
3.92k stars 786 forks source link

error FS0073: internal error: Undefined or unsolved type variable: ^_?82069 #9633

Open gusty opened 4 years ago

gusty commented 4 years ago

I'm creating this issue to track all occurrences of this error for which there is already a fix in the feature/ext branch.

This error is a longstanding one and it's still being reported from time to time with many different repros.

I'm personally tired of wasting my time finding ways to workaround it, which is unfortunately not always possible.

I think the main commit that fixes this issue is here: https://github.com/dotnet/fsharp/pull/6805/commits/f57f9471b08aee19b6575b9b711bad1c7c868a91

And as far as I can tell is totally independent of RFC-1043, the only reason why it was fixed there is because F#+ was used to test the new feature and F#+ finds very frequently that error.

Here's a list of existing reported issues of this error, which I can confirm they work when running them from feature/ext even without the language preview switch which would activate RFC-1043.

I can't stress how important is to get this bug fixed in the constraint solver area, and AFAIK bugs have priority over features, so I think efforts should be invested in order to get the existing fix merged into master.

cartermp commented 4 years ago

Tagging https://github.com/dotnet/fsharp/issues/3508 and https://github.com/dotnet/fsharp/issues/9717

dsyme commented 4 years ago

I've linked this in https://github.com/dotnet/fsharp/pull/6805 to investigate this in the context of that branch work

dsyme commented 4 years ago

Regarding priority - please note that FSharpPlus is using a combination of techniques (SRTP, overloading of witnesses, chained-generation of new SRTP constraints during solving, subtyping etc.) that are not appropriate for an F# library without a considerable future overhaul of F# SRTP. Its goals should likely be greatly simplified to work on a simpler technical basis and anywhere this bug is being hit is likely a prime candidate for simplification. The guidance for F# 1.0-5.0 would be "Don't make or use F# libraries that regularly hit this problem"

That said, when I or others return to feature/ext we can look to see if the fix can be separated from the branch work. My estimate before was that it was better not to do this due to the need to put any changes in this area through a very long "preview" cycle.

Given previous instability caused by adhoc acceptance of changes, I basically regard any changes in the SRTP area as language feature work requiring significant bake time and /langversion:preview

gusty commented 4 years ago

@dsyme I agree in that F#+ has some modules which heavy use SRTPs taking it to a point which was not considered when they were initially designed, as they were mainly intended to address generic arithmetic problems.

But if you go through these bugs, you'll find many different levels of complexity, and they are not just F#+ specific.

Namely, if you have a look at the first one in the list, you'll see that it's a very simple code and guess what, it's just math stuff, no fancy category theory thing.

My feeling is that, if there are no more issues reported is because it is good enough to scare people.