-
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
editorconfig codestyle options #15029
editorconfig codestyle options #15029
Conversation
3b462ea
to
a0f7ab0
Compare
a0f7ab0
to
b887870
Compare
retest vsi please |
@@ -0,0 +1,29 @@ | |||
namespace Microsoft.CodeAnalysis.CodeStyle |
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.
Copyright. #Closed
@jmarolf Is this now subsumed by your other PR or does this still need a review? |
@jasonmalinowski #15065 depends on changes in this PR. I was thinking that that this would merge in before #15065 but I am going to take the feedback you left there and apply it here. |
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.
I'd move the parsing logic into the core .editorconfig logic since a CodeStyleOption is a core concept to us, just to save some verbosity. We did that in other persisters already.
bool isEnabled = false; | ||
if (args.Length != 2) | ||
{ | ||
if (arg.Length == 1) |
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.
Not sure why we have nested ifs here...this seems a bit tricky.
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 handles the case where the user specified that a rule should be on
but has not specified a severity, so we just use the default.
In reply to: 87656798 [](ancestors = 87656798)
return CodeStyleOption<bool>.Default; | ||
} | ||
} | ||
return CodeStyleOption<bool>.Default; |
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.
Is this right? Wouldn't we want to say that we should return the default for the option which might be different than this?
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.
The semantics for these editorconfig files is that if the user has specified the option, but we can't parse it, we pass the default option. Would you prefer we throw?
In reply to: 87657312 [](ancestors = 87657312)
@@ -20,55 +21,73 @@ public class CodeStyleOptions | |||
/// This option says if we should simplify away the <see langword="this"/>. or <see langword="Me"/>. in field access expressions. | |||
/// </summary> | |||
public static readonly PerLanguageOption<CodeStyleOption<bool>> QualifyFieldAccess = new PerLanguageOption<CodeStyleOption<bool>>(nameof(CodeStyleOptions), nameof(QualifyFieldAccess), defaultValue: CodeStyleOption<bool>.Default, | |||
storageLocations: new RoamingProfileStorageLocation("TextEditor.%LANGUAGE%.Specific.QualifyFieldAccess")); | |||
storageLocations: new OptionStorageLocation[]{ | |||
new EditorConfigStorageLocation("dotnet_style_qualification_for_field", ParseEditorConfigCodeStyleOption), |
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.
I'm not morally against teaching EditorConfigStorageLocation about CodeStyle options directly to avoid having to pass the parser to each one specifically. We did that in the RoamingProfileStorageLocation as well.
|
||
switch (args[1].Trim()) | ||
{ | ||
case "none": return new CodeStyleOption<bool>(value: isEnabled, notification: NotificationOption.None); |
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.
Still not sure I like "none" because it's confusing to me if that's the severity or the value. 'silent' perhaps?
f846c80
to
3d6680b
Compare
@Pilchie @MattGertz @natidea I've re-targeted the PR against RC.2, please let me know it we want to take this. Customer scenario
Bugs this fixes: (either VSO or GitHub links)Workarounds
Risk
Performance impact
Is this a regression from a previous update?
Root cause analysis: how did we miss it? What tests are we adding to guard against it in the future?
How was the bug found? (E.g. customer reported it vs. ad hoc testing)
|
Tests seemed to have stalled. Closing and reopening to restart them |
@jmarolf -- hey, so when making this work for Roslyn, I realized that it in our coding guidelines we call "predefined types" actually "language types". Perhaps let's reconsider the naming here? Might not be worth it... |
hey, i would love to see these style categories added. |
@dotnet/roslyn-ide @jasonmalinowski
Adds the following options
Code Style Options