Provide parse options to the language service more quickly

[jasonmalinowski]

When we load a project in Visual Studio, the project system first does an evaluation pass of the project, and hands the resulting list of items to the language service. It then does an execution pass executing CoreCompile passing SkipCompilerExecution=true and ProvideCommandLineArgs=true, that resulting command line string is where we get our compiler switches. The execution pass is much slower than the evaluation pass, so there's a window of time where we have a list of files, but not any options yet.

Because there's a gap, that means there's a time where we are parsing source files with the default parse options. We'll then have to reparse them a second time which isn't great. It also means any cache lookups we do won't have the right options either, so the cache lookups might miss.

To help this, we'll have a property for the evaluation pass which is an "approximation" of the options that would come out of CoreCompile, but only the ones that matter for parsing. It's acceptable for this to be imperfect: once the execution pass is complete we'll use those options instead, so any behaviors here that don't match the real command line generation will only be temporary, and probably won't be any worse than having no options at all.

This is the targets side of #60014; the project system changes were already made and have been merged.

[jasonmalinowski]

One issue that was identified here was the SDK computes some of its constants during execution, which means this optimization doesn't always work as ideally as we'd like. There's other problems with that and we'll investigate further in what it'd take to do. We have some recently added optimizations around avoiding reparsing if there's only a preprocessor directive change and the file doesn't have any preprocessor directives; having us at least get the langversion over means we have a better chance of that optimization being able to kick in.

tl;dr; this doesn't work in all cases, but that's better than working on no cases.

[RikkiGibson]

just curious, is there any telemetry for when "misses" occur here? something we could look at occasionally and say--oops, we added this option which affects parsing, we can see that we need to update this target.

[jasonmalinowski]

We do have telemetry that we added when we initially thought of doing this:

roslyn/src/VisualStudio/Core/Def/ProjectSystem/VisualStudioProject.cs

Line 280 in c756bba

private static void TryReportCompilationThrownAway(SolutionState solutionState, ProjectId projectId)

My concern isn't the lack of the telemetry, but how we'll know to actually look at it if/when the time comes. I admit I don't have any good ideas there. I guess we could switch that code to actually report faults so it'd bubble up in our fault reporting?

[RikkiGibson]

changes under Compilers LGTM

[jasonmalinowski]

@dotnet/roslyn-ide, @dotnet/roslyn-compiler this needs one more review from each team.

[333fred]

Why are the property names different between C# and VB?

[jasonmalinowski]

Seems to be a history thing. If you look at the Csc task vs. Vbc task, there's a different input that's given to them. And I see this too:

https://github.com/dotnet/sdk/blob/2693567468cbaf97c85c57e277e2a0609b317e46/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.VisualBasic.targets#L55

[333fred]

Sigh

[jasonmalinowski]

@333fred That's the appropriate spirit when it comes to MSBuild!

[333fred]

Sigh