-
Notifications
You must be signed in to change notification settings - Fork 830
Description
Large projects can benefit from signature files due to an optimization in FCS that skips type checking for files that have a matching signature file.
fsharp/src/Compiler/Driver/ParseAndCheckInputs.fs
Lines 1211 to 1229 in 36af364
| let typeCheckOne = | |
| if skipImplIfSigExists && hadSig then | |
| (EmptyTopAttrs, CreateEmptyDummyImplFile qualNameOfFile rootSigOpt.Value, Unchecked.defaultof<_>, tcImplEnv, false) | |
| |> Cancellable.ret | |
| else | |
| CheckOneImplFile( | |
| tcGlobals, | |
| tcState.tcsNiceNameGen, | |
| amap, | |
| tcState.tcsCcu, | |
| tcState.tcsImplicitOpenDeclarations, | |
| checkForErrors, | |
| conditionalDefines, | |
| tcSink, | |
| tcConfig.internalTestSpanStackReferring, | |
| tcImplEnv, | |
| rootSigOpt, | |
| file | |
| ) |
This solution could make working on said large projects more optimal. The problem with this is that signature files can get out of sync quite rapidly when changing the implementation file.
Describe the solution you'd like
Could we at some level (FCS or editor) introduce a feature that automatically keeps signature files up to date? Or perhaps display a light bulb when the signature file no longer matches the implementation.
Describe alternatives you've considered
Maintain the signature files by hand.
Additional context
If we were to have a synchronization mechanism, I wonder if we could generate the files in a .vscode like folder? So that end-users don't even need to include them inside the fsproj.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status