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

Update project configuration from Roslyn info #11092

Merged
merged 14 commits into from
Oct 28, 2024

Conversation

davidwengier
Copy link
Contributor

@davidwengier davidwengier commented Oct 25, 2024

Fixes #10736 and brings in IDE support for the new Roslyn tokenizer, which makes this work:

Image

@davidwengier
Copy link
Contributor Author

A better fix here would be to get the SuppressAddComponentParameter flag off of RazorConfiguration and put it on ProjectWorkspaceState, then I wouldn't have needed to hack things into the ProjectWorkspaceStateGenerator as I have. That would require compiler changes though, so I didn't bother since the issue doesn't seem to be fixed either.

The other option is just to rename ProjectWorkspaceStateGenerator to RoslynProjectProcessor or something, since that is what it really does anyway :)

Copy link
Member

@DustinCampbell DustinCampbell left a comment

Choose a reason for hiding this comment

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

A better fix here would be to get the SuppressAddComponentParameter flag off of RazorConfiguration and put it on ProjectWorkspaceState.

Unfortunately, I think that might be a hackier fix. I took a quick look, even though this is in draft, and I'm not comfortable elevating ProjectWorkspaceState to hold more options. IMO, data needed to configure the compiler should go on RazorConfiguration.

@@ -19,6 +19,7 @@
using Microsoft.CodeAnalysis.Razor;
using Microsoft.CodeAnalysis.Razor.Compiler.CSharp;
using Microsoft.CodeAnalysis.Razor.ProjectSystem;
using Microsoft.NET.Sdk.Razor.SourceGenerators;
Copy link
Member

Choose a reason for hiding this comment

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

This feels wrong from a layering perspective. Note that there are (sadly) multiple "features" for configuring the Razor compiler's parse options. This is using the source generator's implementation of IConfigureRazorParserOptionsFeature rather than the newer one that is actually used in most cases: IRazorParserOptionsFactoryProjectFeature.

@davidwengier
Copy link
Contributor Author

it isn't clear to me why CSharpLanguageVersion exists on ProjectWorkspaceState. Seems like this makes better sense on RazorConfiguration?

Noting that I am being descriptive, not prescriptive, but in VS at least, ProjectWorkspaceState is "things that come from Roslyn", and RazorConfiguration is "things that come from the project system". This is ultimately why the SuppressAddComponentParameter change didn't work in VS - that info simply isn't present in the data we receive from the project system, so the value in the configuration is always default.

IMO, data needed to configure the compiler should go on RazorConfiguration.

No argument from me, and with this PR allowing the ProjectWorkspaceStateGenerator to update the configuration as well, that is definitely something we can do. I'm not necessarily a fan of our compiler configuration being dependant on where each piece of data comes from, however the changes in this PR around UseRoslynTokenizer prioritised expediency over everything. Also, to do this properly (ie, not just in a way that uses the configuration properties in the configure lambda) this would require changes to the compiler and how it gets the UseRoslynTokenizer configuration, which was definitely not in scope for the other PR. In general though, I do not like the configure lambda and would happily work to move away from it entirely. Too much potential for bugs when specific calls are missing, and using a strongly typed configuration object is much preferred to me.

its purpose is just to configure RazorCodeGenerationOptions.
This is using the source generator's implementation of IConfigureRazorParserOptionsFeature rather than the newer one that is actually used in most cases: IRazorParserOptionsFactoryProjectFeature.

I am unfamiliar with all 3 of these types, so thank you for the pointers. The current code is just me copying code from the compiler because, as I mentioned above, expediency was the goal.

@davidwengier
Copy link
Contributor Author

davidwengier commented Oct 28, 2024

Okay, pushed up an update to move UseRoslynTokenizer and CSharpLanguageVersion to RazorConfiguration, since they configure the project engine. I would argue RootNamespace should move there too, and in fact it has special handling in some specific cases that could be removed if we did so. I decided not to do that now, and I haven't changed the compiler parts of the wire-up, because I think this is still desired for 17.13 Preview 1, and that work does not seem trivial. It also should probably have some input from the compiler team. I certainly don't feel qualified :) Will happily log issues and we can follow up, unless people have an issue with that approach.

I also took the liberty of renaming some classes because "WorkspaceProject" and "ProjectWorkspace" seem to both mean "Roslyn", so I just called them "Roslyn".

Also taking this out of draft since I found and fixed the issue with SuppressAddComponentParameter.

@davidwengier davidwengier marked this pull request as ready for review October 28, 2024 03:51
@davidwengier davidwengier requested review from a team as code owners October 28, 2024 03:51
@DustinCampbell
Copy link
Member

it isn't clear to me why CSharpLanguageVersion exists on ProjectWorkspaceState. Seems like this makes better sense on RazorConfiguration?

Noting that I am being descriptive, not prescriptive, but in VS at least, ProjectWorkspaceState is "things that come from Roslyn", and RazorConfiguration is "things that come from the project system". This is ultimately why the SuppressAddComponentParameter change didn't work in VS - that info simply isn't present in the data we receive from the project system, so the value in the configuration is always default.

Not related to your pull request at all, but ProjectWorkspaceState is probably something that should just go away. It has an especially bad design smell because it's exposed on IProjectSnapshot. So, there's a IProjectSnapshot.GetTagHelpersAsync(...) method and there's an IProjectSnapshot.ProjectWorkspaceState.TagHelpers property. I've got private changes to address that at some point.

Copy link
Member

@DustinCampbell DustinCampbell 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 definitely a big improvement! Thanks for your hard work cleaning much of this up.

@@ -66,7 +65,7 @@ await _projectManager.UpdateAsync(updater =>
updater.ProjectAdded(hostProject);
});

var projectWorkspaceState = ProjectWorkspaceState.Create(LanguageVersion.LatestMajor);
var projectWorkspaceState = ProjectWorkspaceState.Default;
Copy link
Member

Choose a reason for hiding this comment

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

Does this still represent a project change as the test requires?

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

@davidwengier
Copy link
Contributor Author

ProjectWorkspaceState is probably something that should just go away

Agreed. Now it is just tag helpers, and the name makes little sense.

Comment on lines +144 to +150
var changed = _hostProject1 with
{
Configuration = _hostProject1.Configuration with
{
CSharpLanguageVersion = CodeAnalysis.CSharp.LanguageVersion.CSharp8
}
};
Copy link
Member

Choose a reason for hiding this comment

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

I'm pretty sure you can use dotted names in with. Doesn't block this PR, but good for a follow up.

Suggested change
var changed = _hostProject1 with
{
Configuration = _hostProject1.Configuration with
{
CSharpLanguageVersion = CodeAnalysis.CSharp.LanguageVersion.CSharp8
}
};
var changed = _hostProject1 with
{
Configuration.CSharpLanguageVersion = CodeAnalysis.CSharp.LanguageVersion.CSharp8
};

Copy link
Member

Choose a reason for hiding this comment

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

Actually, it looks like you can't do this, but I was sure we added it. Sigh...

Comment on lines +174 to +180
var changed = _hostProject1 with
{
Configuration = _hostProject1.Configuration with
{
CSharpLanguageVersion = CodeAnalysis.CSharp.LanguageVersion.CSharp8
}
};
Copy link
Member

Choose a reason for hiding this comment

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

Non-blocking!

Suggested change
var changed = _hostProject1 with
{
Configuration = _hostProject1.Configuration with
{
CSharpLanguageVersion = CodeAnalysis.CSharp.LanguageVersion.CSharp8
}
};
var changed = _hostProject1 with
{
Configuration.CSharpLanguageVersion = CodeAnalysis.CSharp.LanguageVersion.CSharp8
};

@davidwengier davidwengier merged commit a37ee12 into dotnet:main Oct 28, 2024
12 checks passed
@davidwengier davidwengier deleted the SuppressAddComponentPlumbing branch October 28, 2024 22:34
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Oct 28, 2024
@phil-allen-msft phil-allen-msft modified the milestones: Next, 17.13 P1 Oct 31, 2024
@jjonescz jjonescz modified the milestones: 17.13 P1, Next Nov 5, 2024
jjonescz added a commit to jjonescz/razor that referenced this pull request Nov 5, 2024
jjonescz added a commit to jjonescz/razor that referenced this pull request Nov 5, 2024
davidwengier added a commit to davidwengier/razor that referenced this pull request Nov 5, 2024
davidwengier added a commit that referenced this pull request Nov 5, 2024
This reverts commit a37ee12, reversing
changes made to ad74439.

We'll have to do another dual insertion into VS Code too, I guess
@jjonescz jjonescz modified the milestones: Next, 17.13 P2 Nov 25, 2024
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.

FUSE generating C# compile errors when non-FUSE doesn't
5 participants