Parse file without enqueuing in the reactor

[auduchinok]

I'd like to make parsing possible without waiting for other files type-check results, possibly asked from another thread.
Currently parsing needs an incremental builder for getting list of files and TcConfig and doesn't mutate this data.
I'm not sure, however, how to get a builder on the calling thread.

[dsyme]

@auduchinok It feels like the right approach is to pass in the flags (i.e. the flags extracted from TcConfig and the builder) directly into FCS, and never create a TcConfig or builder on the parsing path.

The information extracted from the TcConfig is not much, just:

• suppression of warnings from --nowarn arguments etc
• conditional defines
• a couple of flags

The builder is only used to get a list of file names in the project, but that is barely used, see https://github.com/fsharp/FSharp.Compiler.Service/blob/master/src/fsharp/vs/service.fs#L1734 and the usage site. I think you could just pass in a isLastCompiland flag instead.

It might take a bit of digging to allow that information to be passed directly and would require a change to the FCS API (which is OK I think).

It may make sense to add an "FSharpParsingOptions" record to the FCS API and have a "argv: string[] --> FSharpParsingOptions" as part of the FCS API. We've seen other cases where we need to parse the command line arguments and extract only the content relevant for parsing (currently FSharpProjectOptions captures all arguments necessary for tokenizing, parsing, checking and code generation).

[auduchinok]

@dsyme Just in case, should a PR be opened here or in the visualfsharp repo when it's ready? If the latter, can you please predict when it's going to be merged here?
By the way, FCS can now be built from visualfsharp, so I'm kind of confused about the purpose of this repo in the long term.

[dsyme]

@dsyme Just in case, should a PR be opened here or in the visualfsharp repo when it'll be ready?

Please submit to Microsoft/visualfsharp

If the latter, can you please predict when it's going to be merged here?

We will merge as soon as practical (you can help submit the integration PRs if you like). Right now there is one large integration which should be the last hard one, I apologise for that taking a while.

You can also always cherry-pick into here and submit an extra PR if you like if the change is small

By the way, FCS can now be built from visualfsharp, so I'm kind of confused about the purpose of this repo in a long term.

Technically speaking it currently provides

• the nuget packaging
• extra tests
• extra CI configurations tested (more versions of Mono etc.)
• .NET Core build and testing
• Fable bits (in a maintained PR)
• documentation
• no bootstrap of the compiler needed (which makes engineering easier)

There is also a strong feeling in the F# community that this repo (and http://github.com/fsharp/fsharp) are important "living proof" of certain dimensions of F#'s independence. That's harder to explain, but I understand it. My feeling is that we should continue to use this repo at least as a packaging repo until we

1. address all the above technical issues

2. successfully split Microsoft/visualfsharp into "fsharp" and "visualfsharptools".

[dsyme]

@auduchinok Just to note that FCS can now be built in the Microsoft/visualfsharp repo - just use build fcs and build fcs test (after a build proto and build net40 if needed). This includes building the nuget packages. We built the 14.0.x packages from that repo (and integrated the code here)

FCS should continue to be considered a separate logical component,

This should help you make a contribution via the Microsoft\visualfsharp repo.

[auduchinok]

Fixed in 4c244da.

[dsyme]

Thanks for closing :)