Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix vscode fuse feature flag #10169

Merged
merged 13 commits into from
Mar 29, 2024
Merged

Fix vscode fuse feature flag #10169

merged 13 commits into from
Mar 29, 2024

Conversation

ryzngard
Copy link
Contributor

Prior to this change, the feature flag was being serialized and deserialized as part of the RazorConfiguration. This works fine for VS, since the razor extension is the one serializing. However, if we want to store that information in the serialization on vs code, we'd have to have a hook into Roslyn to do that.

Instead, this adds a section of the configuration specifically labeled for feature flags. This should not be serialized, and should be filled in based on the LanguageServerConfiguration. This allows us to pass the flag into rzls and retrieve for the correct implementation when running the ProjectEngine

@ryzngard ryzngard changed the title [DRAFT] Fix vscode fuse feature flag Fix vscode fuse feature flag Mar 26, 2024
@ryzngard ryzngard marked this pull request as ready for review March 26, 2024 21:00
@ryzngard ryzngard requested review from a team as code owners March 26, 2024 21:00
Copy link
Contributor

@davidwengier davidwengier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a surprisingly tricky bit of plumbing. My comments are mostly just me thinking out loud, I'm curious what you think

Comment on lines 28 to 34
var forceRuntimeCodeGeneration = false;

if (reader.NextMessagePackType is MessagePackType.Boolean)
{
forceRuntimeCodeGeneration = reader.ReadBoolean();
count -= 1;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this back again?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because I'm so afraid to break things!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's probably safe to remove at this point.

Copy link
Contributor

@davidwengier davidwengier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, but a couple of places to update before merging.

@@ -47,7 +39,7 @@ public override RazorConfiguration Deserialize(ref MessagePackReader reader, Ser
? version
: RazorLanguageVersion.Version_2_1;

return new(languageVersion, configurationName, extensions, ForceRuntimeCodeGeneration: forceRuntimeCodeGeneration);
return new(languageVersion, configurationName, extensions, RazorLanguageFeatureFlags.Default);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we be serializing the language feature flags?

@@ -12,20 +12,20 @@

namespace Microsoft.AspNetCore.Razor.ProjectSystem;

internal sealed class RazorProjectInfo
internal sealed record class RazorProjectInfo
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does making this a record help in some way? Note that the equality of this record won't be correct because it will need to use SequenceEquals for the Documents property.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It made it cleaner to add a with for modifying readonly properties than having to write out new(...)

@@ -47,7 +47,7 @@ public override RazorConfiguration Deserialize(ref MessagePackReader reader, Ser
? version
: RazorLanguageVersion.Version_2_1;

return new(languageVersion, configurationName, extensions, ForceRuntimeCodeGeneration: forceRuntimeCodeGeneration);
return new(languageVersion, configurationName, extensions);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we bothering to read forceRuntimeCodeGeneration above if it's not used any longer? It looks like the read was removed from the JSON serialization.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is potential overlap where we have it written to a file right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's super small though. Is it worth protecting between 17.10p2 and 17.10p3? (Was this even in 17.10p2?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only p3, which we could port to remove

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh actually, it's shipped in vs code already.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need a flow chart!

Comment on lines 28 to 34
var forceRuntimeCodeGeneration = false;

if (reader.NextMessagePackType is MessagePackType.Boolean)
{
forceRuntimeCodeGeneration = reader.ReadBoolean();
count -= 1;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's probably safe to remove at this point.

@@ -63,14 +64,14 @@ public async Task ProjectConfigurationFileChanged_Removed_NonNormalizedPaths()
.Setup(x => x.AddProject(
projectInfo.FilePath,
intermediateOutputPath,
projectInfo.Configuration,
It.IsAny<RazorConfiguration>(),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the curious or inquisitive person who finds this, I had to change this to IsAny because we're mocking our own code and the path to add/update a project enforces that the configuration is up to date with the feature flags. That causes reference equality to fail and thus moq to fail.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😭

@@ -107,11 +107,13 @@ private async Task AddFallbackProjectAsync(ProjectId projectId, string filePath,

var rootNamespace = project.DefaultNamespace;

var configuration = FallbackRazorConfiguration.Latest with { LanguageServerFlags = _languageServerFeatureOptions.ToLanguageServerFlags() };
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty change! 😄

Copy link
Contributor

@chsienki chsienki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Compiler changes LGTM

@ryzngard ryzngard enabled auto-merge (squash) March 28, 2024 21:39
@ryzngard ryzngard merged commit a4be655 into dotnet:main Mar 29, 2024
12 checks passed
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Mar 29, 2024
@ryzngard ryzngard deleted the vscode_featureflag branch March 29, 2024 00:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants