-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Implement Naming Styles for editorconfig UI #58075
Implement Naming Styles for editorconfig UI #58075
Conversation
This adds all the capabilities necessary to discover and update naming styles in an editorconfig. depends on the parser functionality added in previous commit
This adds a new tab for the naming style options that were exposed via services in a previous commit
src/Workspaces/SharedUtilitiesAndExtensions/Compiler/Core/EditorConfig/readme.md
Outdated
Show resolved
Hide resolved
...ensions/Compiler/Core/NamingStyles/EditorConfig/EditorConfigNamingStyleParser_NamingStyle.cs
Outdated
Show resolved
Hide resolved
src/EditorFeatures/Core/EditorConfigSettings/Updater/NamingStyles/NamingStyleSettingsUpdater.cs
Show resolved
Hide resolved
else | ||
{ | ||
var span = new TextSpan(sourceText.Length, 0); | ||
newNamingStyleSection.Append("\r\n"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we use Environment.NewLine
here?
…ngStyles/EditorConfig/EditorConfigNamingStyleParser_NamingStyle.cs Co-authored-by: Joey Robichaud <[email protected]>
…orConfig/readme.md Co-authored-by: Joey Robichaud <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is already a parser in the compiler. I'm not a big fan of duplicating part of that logic. Is there a way to reuse the existing compiler support for EditorConfig?
This scares me 👀 |
One thing I've always wondered about the EditorConfig UI, how will it be able to handle scenarios where different directories have different settings. This is far from being something to do in this PR, but sharing my thought anyway to consider. |
I mention this here: https://github.com/jmarolf/roslyn/blob/features/editorconfig-naming-style-support/src/Workspaces/SharedUtilitiesAndExtensions/Compiler/Core/EditorConfig/readme.md but then I asked you to review specific commits so this is what I get ¯_(ツ)_/¯ The compilers implementation has some rather big perf requirements and I don't want them to take on the additional complexity . Also the way I've done section parsing includes several cases that the compiler does not need to worry about. Would like to unify these someday but I think the requirements diverge enough that I went with a separate implementation that meets our needs |
// Matches EditorConfig section header such as "[*.{js,py}]", see https://editorconfig.org for details | ||
private static readonly Regex s_sectionMatcher = new(@"^\s*\[(([^#;]|\\#|\\;)+)\]\s*([#;].*)?$", RegexOptions.Compiled); | ||
// Matches EditorConfig property such as "indent_style = space", see https://editorconfig.org for details | ||
private static readonly Regex s_propertyMatcher = new(@"^\s*([\w\.\-_]+)\s*[=:]\s*(.*?)\s*([#;].*)?$", RegexOptions.Compiled); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jmarolf One of the reasons I'm worried about two parser implementations is something like #51625, which proposes a change to the s_propertyMatcher
regex. It's likely we can miss any changes of those kind here. Probably some code comments in each place referring to the other would do it for now until this is unified?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in a world where there was a formal spec that we could write against this would be less of a concern but things being as they are I agree we don't want to do this for no reason. I am still of the opinion that this is justified considering the compilers' requirements.
I will add test cases for the comment parsing to both implementations so that if someone ever updates one version and not the other CI will fail.
...eatures/Core/EditorConfigSettings/Updater/NamingStyles/EditorConfigNamingStylesExtensions.cs
Outdated
Show resolved
Hide resolved
...eatures/Core/EditorConfigSettings/Updater/NamingStyles/EditorConfigNamingStylesExtensions.cs
Outdated
Show resolved
Hide resolved
…les/EditorConfigNamingStylesExtensions.cs Co-authored-by: Youssef Victor <[email protected]>
…les/EditorConfigNamingStylesExtensions.cs Co-authored-by: Youssef Victor <[email protected]>
src/EditorFeatures/Core/EditorConfigSettings/Updater/NamingStyles/SourceTextExtensions.cs
Outdated
Show resolved
Hide resolved
src/EditorFeatures/Core/EditorConfigSettings/Updater/NamingStyles/SourceTextExtensions.cs
Outdated
Show resolved
Hide resolved
I would love to hear ideas. My plan is to is to augment the My expectation is that the UI is a view over a single file showing the rules that are defined there as well as the "implicit" rules that it is pulling from elsewhere. Editing therefore always applies to the file you are viewing but we can make navigating across files better. We can also add additional columns so that sorting and filtering is easier. Another case that I would like to handle is different rules across different sections in the same file. I currently punt on things like this: [*.cs]
# C# specific settings
[*.vb]
# Visual Basic specific settings
[*.{cs,vb}]
# Settings for both If there are duplicated rules. My hope is that I could show duplicated rules as duplicates in the list with a column showing the section they come from to disambiguate |
d1bf3a2
to
4121f55
Compare
4121f55
to
74e9ca0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review 1/3 done
src/Workspaces/SharedUtilitiesAndExtensions/Compiler/Core/EditorConfig/LanguageExtensions.cs
Outdated
Show resolved
Hide resolved
...rkspaces/SharedUtilitiesAndExtensions/Compiler/Core/EditorConfig/Parsing/EditorConfigFile.cs
Outdated
Show resolved
Hide resolved
...spaces/SharedUtilitiesAndExtensions/Compiler/Core/EditorConfig/Parsing/EditorConfigOption.cs
Show resolved
Hide resolved
...aces/SharedUtilitiesAndExtensions/Compiler/Core/EditorConfig/Parsing/EditorConfigOption`1.cs
Outdated
Show resolved
Hide resolved
...ces/SharedUtilitiesAndExtensions/Compiler/Core/EditorConfig/Parsing/Sections/SectionMatch.cs
Show resolved
Hide resolved
...ces/SharedUtilitiesAndExtensions/Compiler/Core/EditorConfig/Parsing/Sections/SectionMatch.cs
Outdated
Show resolved
Hide resolved
...edUtilitiesAndExtensions/Compiler/Core/EditorConfig/Parsing/Sections/SectionMatcher.Lexer.cs
Outdated
Show resolved
Hide resolved
...edUtilitiesAndExtensions/Compiler/Core/EditorConfig/Parsing/Sections/SectionMatcher.Lexer.cs
Show resolved
Hide resolved
...edUtilitiesAndExtensions/Compiler/Core/EditorConfig/Parsing/Sections/SectionMatcher.Lexer.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2/3 done
...eatures/Core/EditorConfigSettings/Updater/NamingStyles/EditorConfigNamingStylesExtensions.cs
Show resolved
Hide resolved
internal SymbolSpecification? Type { get; set; } | ||
|
||
public string StyleName => Style.Name; | ||
public string[] AllStyles => _allStyles.Select(style => style.Name).ToArray(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be ImmutableArray<string>
|
||
internal void ChangeStyle(int selectedIndex) | ||
{ | ||
if (selectedIndex > -1 && selectedIndex < _allStyles.Length && Location is not null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this throw index out of bounds?
src/EditorFeatures/Core/EditorConfigSettings/Updater/NamingStyles/NamingStyleSettingsUpdater.cs
Show resolved
Hide resolved
public static void AppendNamingStylePreferencesToEditorConfig(IEnumerable<NamingRule> namingRules, StringBuilder editorconfig, string? language = null) | ||
{ | ||
var symbolSpecifications = namingRules.Select(x => x.SymbolSpecification).ToImmutableArray(); | ||
var namingStyles = namingRules.Select(x => x.NamingStyle).ToImmutableArray(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's probably not a huge deal, but doing ToImmutableArray()
here is slightly more expensive than just leaving as an IEnumerable
since you're going to just enumerate again and not use the ImmutableArray
. That ore combine with the Select
below for one chained LINQ
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good. Nothing blocking, minor feedback here and there. The Readme.md
files were really helpful and I'm glad they're being checked in. One slight improvement would be to call them out in the PR description (I know it's tough/impossible to link) just so we know to look for them :) Hopefully we can start adopting this for future PRs as a team
@@ -0,0 +1,22 @@ | |||
# Editorconfig settings providers and updaters |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 this is a great idea. Love the contextual markdown files.
Related to #40163
This PR implements naming style support in 3 steps (and I would recommend reviewing this PR step-by-step)