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 directive placement when removing nodes using syntax API. #76275

Merged
merged 16 commits into from
Dec 6, 2024

Conversation

CyrusNajmabadi
Copy link
Member

@CyrusNajmabadi CyrusNajmabadi commented Dec 5, 2024

Fixes #19613

When removing a node, a standard flag is passed in saying "keep directives around if removing them would lead to an unbalanced directive state (like removing a #region when the corresponding #endregion stays around). This is an intuitive default as it means users generally don't have to think about pp trivia when removing nodes (since often the PP trivia is actually spread over many physical nodes, even though it looks to surround one 'virtual' node).

However, the logic for actually doing this was not great. When the api detected a PP directive to keep, it would grab only it and keep only that in the resultant tree. This means that a PP-directive that was indented, would become NOT indented, leading to ill formatted code.

For directives like #if this was rarely an issue as VS-formatting and the .Net ecosystem almost always has those left-aligned on column 1. However, for #region directives, this was suboptimal as it meant the directive would go from being indented, to left-aligned.

The fix is to have the removal logic try to keep leading whitespace before the PP directive, to ensure that it stays at the same location, even when the rest of the trivia around it is removed

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead labels Dec 5, 2024
@CyrusNajmabadi CyrusNajmabadi changed the title Initial work Fix directive placement when removing nodes using syntax API. Dec 5, 2024
@CyrusNajmabadi CyrusNajmabadi marked this pull request as ready for review December 5, 2024 06:39
@CyrusNajmabadi CyrusNajmabadi requested review from a team as code owners December 5, 2024 06:39
@CyrusNajmabadi
Copy link
Member Author

@dotnet/roslyn-compiler ptal.

var expectedText = """
class C
{

Copy link
Member Author

Choose a reason for hiding this comment

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

unfortunate blank line. i'm considering chnaging that in this PR to not happen either. LMK if you'd prefer that.

Copy link
Member Author

Choose a reason for hiding this comment

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

i looked into changing this and it was a wash. Undesirable lines like this were kept, while desirable lines (like those between methods) were removed. So i'm keeping this for now.

Copy link
Contributor

Choose a reason for hiding this comment

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

probably a bunch more heuristics would be needed in order to make it a net improvement.

@RikkiGibson RikkiGibson self-assigned this Dec 6, 2024
Copy link
Contributor

@RikkiGibson RikkiGibson 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, but saw a surprising result in an editor features test.

src/Compilers/CSharp/Portable/Syntax/SyntaxNodeRemover.cs Outdated Show resolved Hide resolved
src/Compilers/CSharp/Portable/Syntax/SyntaxNodeRemover.cs Outdated Show resolved Hide resolved
var expectedText = """
class C
{

Copy link
Contributor

Choose a reason for hiding this comment

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

probably a bunch more heuristics would be needed in order to make it a net improvement.

src/Compilers/CSharp/Portable/Syntax/SyntaxNodeRemover.cs Outdated Show resolved Hide resolved
@CyrusNajmabadi
Copy link
Member Author

@dotnet/roslyn-compiler for second pair of eyes. thanks!

Copy link
Member

@333fred 333fred 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 generally look good, but a minor comment on naming for clarity.

@CyrusNajmabadi
Copy link
Member Author

@333fred naming handled. Ok signing off?

@CyrusNajmabadi
Copy link
Member Author

@ToddGrun ptal

@@ -290,16 +340,6 @@ private void AddPartialModifiersToTypeChain(
documentEditor.RemovePrimaryConstructor(node);
}
}

documentEditor.ReplaceNode(State.TypeNode,
Copy link
Member Author

Choose a reason for hiding this comment

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

this was moved to a helper method. it is still called in both the callers that called this method. just at different places now.

documentEditor.RemoveNode(directive);
}

RemoveLeadingBlankLinesFromMovedType(documentEditor);
Copy link
Member Author

Choose a reason for hiding this comment

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

We want ot call this after we remove all the appropriate directives from the node so that the spacing is correct after that happens.

@@ -18,6 +18,7 @@
using Microsoft.CodeAnalysis.Text;
using Roslyn.Utilities;
using Microsoft.CodeAnalysis.CSharp.Extensions.ContextQuery;
using System.Collections.Immutable;
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: sort

Copy link
Member Author

Choose a reason for hiding this comment

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

doen in followup pr.

"""
public partial class Goo
{
#region Region
Copy link
Contributor

Choose a reason for hiding this comment

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

Just to make sure I'm reading this correctly, the directive is expected to be in both places?

Copy link
Member Author

Choose a reason for hiding this comment

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

it's a stretch to say 'expected'. But at the very least we want it to be correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead VSCode
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Refactoring "Move type to ..." breaks preprocessor directives
5 participants