Fix FUSE hook up in VS Code #11175
Merged
Fix FUSE hook up in VS Code #11175
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
These flags were explicitly not for the compiler, being not serialized, and hence don't really belong on RazorConfiguration. They also were only ever set in the VS layer
ryzngard
approved these changes
Nov 7, 2024
| @@ -35,37 +36,26 @@ internal class ProjectState | |||
| private readonly object _lock; | |||
|
|
|||
| private readonly IProjectEngineFactoryProvider _projectEngineFactoryProvider; | |||
| private readonly LanguageServerFeatureOptions _languageServerFeatureOptions; | |||
| private RazorProjectEngine? _projectEngine; | |||
|
|
|||
| public static ProjectState Create( | |||
There was a problem hiding this comment.
❓ I've always wondered why we have a create here that doesn't do any work other than just call the constructor with the same things. Not unique to this PR though
There was a problem hiding this comment.
💭 I suspect it's modeled on Roslyn's APIs like Compilation.
jjonescz
approved these changes
Nov 7, 2024
DustinCampbell
approved these changes
Nov 7, 2024
| @@ -35,37 +36,26 @@ internal class ProjectState | |||
| private readonly object _lock; | |||
|
|
|||
| private readonly IProjectEngineFactoryProvider _projectEngineFactoryProvider; | |||
| private readonly LanguageServerFeatureOptions _languageServerFeatureOptions; | |||
| private RazorProjectEngine? _projectEngine; | |||
|
|
|||
| public static ProjectState Create( | |||
There was a problem hiding this comment.
💭 I suspect it's modeled on Roslyn's APIs like Compilation.
chsienki
approved these changes
Nov 7, 2024
This was referenced Nov 9, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This one might be a little controversial in terms of how I wired the
LanguageServerFeatureOptionsup through theProjectSnapshot, but it's somewhat similar to how it works in cohosting, withRemoteProjectSnapshot -> RemoteSolutionSnapshot -> SolutionSnapshotManager -> LanguageServerFeatureOptions.Aside from that aspect of the specific implementation, which you're more than welcome to critique and suggest an alternative to, the fundamental change here is removing
LanguageServerFlagsand usingLanguageServerFeatureOptionsdirectly. It seems thatLanguageServerFlagswas intended to encapsulate the feature options for the compiler, but since that time they are never actually used by the compiler, and just ended up in a weird spot. They were "flags for the language server", but were only ever initialized in VS. We we essentially ended up with this unnecessary middle-man, that didn't always exist. TheLanguageServerFeatureFlagson the other hand are always set in VS, VS Code, etc.TL;DR: Now that all of the code for deciding whether to use runtime compilation is entirely on the tooling side, it just makes sense to use the tooling side options class directly.