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

Support ; and } format on type in mixed scenarios #2585

Merged
merged 4 commits into from
Oct 6, 2020

Conversation

ajaybhargavb
Copy link
Contributor

Fixes:

Summary of the changes

  • Support for format on type in all mixed scenarios
  • Fixed HTML attribute formatting in multiline cases
  • Modified FormattingContext and visitor to extract more useful information
  • Improved CleanupDocument to cleanup both the start and end of the source mappings (we used to only do start)
  • Fixed a bug with how we calculated existing indentation of a line
  • Updated/unskipped tests
  • Filed https://github.com/dotnet/aspnetcore/issues/26527 to track known issues and adding more tests

Pre-LSP:
formatontypeold

Now:
formatontypenew

@ajaybhargavb ajaybhargavb force-pushed the ajbaaska/better-ontype-formatting branch from 0085b37 to 8fbea5b Compare October 3, 2020 01:26
Copy link
Contributor

@NTaylorMullen NTaylorMullen left a comment

Choose a reason for hiding this comment

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

Love to see how it's all coming together!

var offset = (int)offsetProperty.GetValue(result);

var resultLine = changedText.Lines.GetLinePosition(basePosition);
var indentation = resultLine.Character + offset;

// IIndentationService always returns offset as the number of spaces.
// So if the client uses tabs instead of spaces, we need to convert accordingly.
if (!context.Options.InsertSpaces)
Copy link
Contributor

Choose a reason for hiding this comment

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

Why don't we still need to do this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I changed the place where I consumed this to operate on offset instead of levels. I needed to do that because the HTML formatter doesn't always format in exact multiples of levels.
Example,

<div class=foo
     id=fooid>
</div>

}

private static bool ShouldCleanup(FormattingContext context, Position position)
protected bool ShouldFormat(FormattingContext context, Position position, bool allowImplicitStatements)
Copy link
Contributor

Choose a reason for hiding this comment

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

implicit statement or implicit expression? Also, is the reason why the flag is even here is because of the differences between OnTypeFormatting and regular Formatting in regards to implicit expressions?

Copy link
Contributor Author

@ajaybhargavb ajaybhargavb Oct 4, 2020

Choose a reason for hiding this comment

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

implicit statement or implicit expression?

Statements like @if (true){...}.

is the reason why the flag is even here is because of the differences between OnTypeFormatting and regular Formatting

That too. But this is mainly the difference between whether to format using the C# formatter and whether to cleanup that source mapping. They both use ShouldFormat to decide whether they should operate on it. The job of CleanupDocument is to introduce a newline at the start and end of each source mapping. But we can't do that for implicit statements because then it would be wrong like below,

@
if(true){...}

Note: Implicit expressions are never formatted or cleaned up. So didn't need to provide a parameter for that.


private void CleanupSourceMappingEnd(FormattingContext context, Range sourceMappingRange, List<TextChange> changes)
Copy link
Contributor

Choose a reason for hiding this comment

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

Wonder if "Cleanup" is the right verbiage. This method is all about separating language contexts. Also, it adds to the changes collection

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree but all the other names I can think of are too long. I'll try to think of a better name.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I tried really hard but couldn't come up with a concise name :(


namespace Microsoft.AspNetCore.Razor.LanguageServer.Formatting
{
internal class OnTypeFormattingStructureValidationPass : FormattingPassBase
Copy link
Contributor

Choose a reason for hiding this comment

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

So this was just restricting where the ontype formatting would occur. The pre-existing structure validation pass that validates that no content has been "destroyed" still exists right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

pre-existing structure validation

The other validation we currently have are,

  • Content validation (makes sure only whitespace is nuked)
  • Diagnostic validation (makes sure we don't introduce new diagnostics. This works surprisingly well in most cases)

@@ -41,5 +41,23 @@ public static int CompareTo(this Position position, Position other)
var result = position.Line.CompareTo(other.Line);
return (result != 0) ? result : position.Character.CompareTo(other.Character);
}

public static bool IsValid(this Position position, SourceText sourceText)
Copy link
Contributor

Choose a reason for hiding this comment

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

👏 👏 👏

@TanayParikh
Copy link
Contributor

💯 :shipit:

looks like there are some test failures though.

@ajaybhargavb
Copy link
Contributor Author

looks like there are some test failures though.

Looks like some tests became flaky. Nothing here looks like it can introduce flakiness. I wonder how 🤔

* Fix Formatting Flakyness

* Serialize InitializeFile Based Tests
@ajaybhargavb ajaybhargavb merged commit b9b5cc1 into master Oct 6, 2020
@ajaybhargavb ajaybhargavb deleted the ajbaaska/better-ontype-formatting branch October 6, 2020 23:52
@NTaylorMullen NTaylorMullen mentioned this pull request Oct 9, 2021
12 tasks
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.

3 participants