[nojaf]

A fractured flaw, a broken hue, hath beset my project's sight,
Type checking, bereft of full diagnostics, relinquishes its might,
Where once clarity and guidance did resound,
Now echoes of disarray, an enigmatic sound.

Hi all,

This is more of a question and potentially a bug report disguised as a PR.
I believe I found a regression when it comes to the compiler diagnostics of implementation files that were backed by a signature file.

See MissingDiagnostic.fs for a concrete example.
The diagnostic reported in the implementation file is not covered anymore by FSharpChecker.ParseAndCheckProject.

I suspect this is happens in FinalizeTypeCheckTask because

fsharp/src/Compiler/Service/IncrementalBuild.fs

Lines 720 to 723 in ebd758e

	let! tcInfos =
	computedBoundModels
	|> Seq.map (fun boundModel -> node { return! boundModel.GetOrComputeTcInfo() })
	|> NodeCode.Sequential

will contain the same diagnostics that were reported in the signature file for both files.
The implementation file will wrap the signature diagnostics in

fsharp/src/Compiler/Service/IncrementalBuild.fs

Lines 305 to 321 in ebd758e

	let skippedImplemetationTypeCheck =
	match syntaxTreeOpt, prevTcInfo.sigNameOpt with
	| Some syntaxTree, Some (_, qualifiedName) when syntaxTree.HasSignature ->
	let input, _, fileName, _ = syntaxTree.Skip qualifiedName
	SkippedImplFilePlaceholder(tcConfig, tcImports, tcGlobals, prevTcInfo.tcState, input)
	|> Option.map (fun ((_, topAttribs, _, ccuSigForFile), tcState) ->
	{
	tcState = tcState
	tcEnvAtEndOfFile = tcState.TcEnvFromImpls
	moduleNamesDict = prevTcInfo.moduleNamesDict
	latestCcuSigForFile = Some ccuSigForFile
	tcDiagnosticsRev = prevTcInfo.tcDiagnosticsRev
	topAttribs = Some topAttribs
	tcDependencyFiles = fileName :: prevTcInfo.tcDependencyFiles
	sigNameOpt = Some(fileName, qualifiedName)
	})
	| _ -> None

.

tcDiagnosticsRev = prevTcInfo.tcDiagnosticsRev being the culprit.

Later in FinalizeTypeCheckTask
let finalInfo = Array.last tcInfos and let diagnostics = diagnosticsLogger.GetDiagnostics() :: finalInfo.tcDiagnosticsRev will the wrong diagnostics.

This is breaking behaviour if you compare it against FCS 43.7.200.
See MissingDiagnostic.zip sample to compare them.

Note that changing FSharpChecker.Create(enablePartialTypeChecking = enablePartialTypeChecking) doesn't seem to have any effect on this.

The changes in #14903 might be related or relevant here.
@majocha would you mind taking a look at this?

[vzarytovskii]

Thanks, we've seen it happening for compiler too.

I wish GH had a mix of issue and PR, when you can submit and issue, but have some diff too, so CI can run tests, but it would still be in the issues view.

[majocha]

When I got the notification my first thought was "it would be awesome to have a test for this", then I opened Github and what a pleasant surprise 🤩. Great writeup @nojaf as usual.

I think I got it. This what I have now: (I'll post a draft later)

I'm not sure what the logic should be in case of enablePartialTypeChecking = true? Should GetCheckResultsAndImplementationsForProject do a full typecheck regardless?

[majocha]

Yeah, the problem is that collecting diagnostics sequentially does not really work well when we're not doing the type check sequentially. I understand this is solved nicely in #14494. Transparent Compiler PR #15179 will tackle this also. I'm not sure it's worth putting the effort here in the old code that is on it's way out already?

[vzarytovskii]

Yeah, the problem is that collecting diagnostics sequentially does not really work well when we're not doing the type check sequentially. I understand this is solved nicely in #14494. Transparent Compiler PR #15179 will tackle this also. I'm not sure it's worth putting the effort here in the old code that is on it's way out already?

Problem with this is that new compiler will take a really long time until we can turn it on by default for vs.

[nojaf]

I'm not sure it's worth putting the effort here in the old code that is on it's way out already?

Given this is quite a regression, I think it is worth putting effort into this. As this is a public API of FCS, it will impact many consumers.

I guess the implementation file (with backing signature) should only be allowed to be skipped for FSharpChecker.ParseAndCheckFileInProject. And never be skipped in ParseAndCheckProject.