-
Notifications
You must be signed in to change notification settings - Fork 831
Typar name signature data #15003
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
Typar name signature data #15003
Conversation
…fsharp into typar-name-signature-data
|
After seeing this pass for all builds (I'm talking about It resolves the original problem of #14850 and would unblock us to start using If we have this in a nightly dotnet 8 SDK we can start doing extensive testing on our end to ensure that the binary produced by sequential and graph-based type-checking is the same. |
tests/FSharp.Core.UnitTests/FSharp.Core.SurfaceArea.netstandard20.debug.bsl
Show resolved
Hide resolved
|
@nojaf Amazing! Great to see the second take on this nailed it! |
I believe this to be one of my better attempts at making
--test:GraphBasedCheckingdeterministic.The initial intent was to solve #14850 and not get mixed up in any graph-based type-checking adventure.
But alas, my Stockholm syndrome kicked in.
In 97f3d0a I first try to illustrate the problem case.
This is a repeat of the run-through of this comment.
In short, the typars of a
Valinside theModuleOrNamespaceTypewill only get a pretty name if that function is used somewhere. A side effect of this is an impact in the letters used for pretty naming the typars (of theValRef).To overcome this, in 03085c3, I try to prettify the typar names of the signature data (
ModuleOrNamespaceType) inPostInferenceChecks.fs.Because this gets pretty names at the point the function is defined, this will overcome the problem that the pretty naming happens when the function is later invocated in another file. (
CheckValRefwill already have the proper names).I believe this change would solve #14850, but it wouldn't solve the race condition of hash constraints.
For example:
val someGenericFunction: #exn list -> unitin a signature file would still have?after checking the signature file. In graph-based type-checking multiple files could already use this information in parallel, so the naming would kick in again when the function is first invocated.That is why in d6b30e0 I'm calling the name logic again, right after the signature file was checked.
After some local testing (with some wonderful
Thread.Sleep (rnd.Next(100, 500))during the type-checking of each file) I found out that I was able to produce the exact same binary over 50 times in a row with graph-based checking. Sequential checking produced that exact same binary.This doesn't prove anything, but I do believe this is a step in the right direction.
The big question of course remains if these changes are sensible or not.
Fingers crossed,
Florian