Expose FSharpProjectSnapshot data.

[nojaf]

Description

In the new world of snapshots, it is currently impossible to update a snapshot when, for example, the OtherOptions changed. I'd like to expose more data so the static Create method can be used to create an updated version.

This currently is possible with FSharpProjectOptions. I would need this to have parity.

Who do you think @0101?

Checklist

• Test cases added

• Performance benchmarks added in case of performance changes

• Release notes entry updated:

  Please make sure to add an entry with short succinct description of the change as well as link to this pull request to the respective release notes file, if applicable.

  Release notes files:

  • If anything under src/Compiler has been changed, please make sure to make an entry in docs/release-notes/.FSharp.Compiler.Service/<version>.md, where <version> is usually "highest" one, e.g. 42.8.200
  • If language feature was added (i.e. LanguageFeatures.fsi was changed), please add it to docs/releae-notes/.Language/preview.md
  • If a change to FSharp.Core was made, please make sure to edit docs/release-notes/.FSharp.Core/<version>.md where version is "highest" one, e.g. 8.0.200.

  Information about the release notes entries format can be found in the documentation.
  Example:

  • More inlines for Result module. (PR #16106)
  • Correctly handle assembly imports with public key token of 0 length. (Issue #16359, PR #16363)
    *while! (Language suggestion #1038, PR #14238)

  If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

[github-actions]

⚠️ Release notes required, but author opted out

Warning

Author opted out of release notes, check is disabled for this pull request.
cc @dotnet/fsharp-team-msft

[0101]

Yeah I think that's fine. Alternatively we could maybe add a Update method which you would call on an existing snapshot with any of these and you'd get a new one.

[vzarytovskii]

I'm not a huge fan of exposing underlying data types tbh. The more data types we expose, the harder it's going to be to change it. Don't we want to instead expose operations on snapshots/checker for needed actions, so it's easier to deprecate and change it?

[vzarytovskii]

Nvm, if we want to eventually replace options with snapshot, it's fine

[auduchinok]

Don't we want to instead expose operations on snapshots/checker for needed actions, so it's easier to deprecate and change it?

It could be good, yes. We don't mind changing the API calls when such public APIs appear. However, we need to start testing the transparent compiler earlier than that happens, so for now let's make it possible for all editors to use and test it, without resorting to adding more IVTs to FCS.

[auduchinok]

Nvm, if we want to eventually replace options with snapshot, it's fine

Yes, it sounds like it's where everyone is going to migrate to eventually when transparent compiler is stable.

[0101]

We can expose these now. But eventually the code that will be creating new snapshots based on updates should also be here so everyone doesn't have to re-implement it.

[nojaf]

Alternatively we could maybe add a Update method which you would call on an existing snapshot with any of these and you'd get a new one.

Yes, perhaps, but something that would fit all use cases would be more ideal to start with.