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

Convert formatting engine to TextChange and ImmutableArray #10842

Closed
davidwengier opened this issue Sep 5, 2024 · 0 comments · Fixed by #10855
Closed

Convert formatting engine to TextChange and ImmutableArray #10842

davidwengier opened this issue Sep 5, 2024 · 0 comments · Fixed by #10855

Comments

@davidwengier
Copy link
Contributor

Our formatting engine constantly switches between TextChange and TextEdit, and generally uses arrays for things, because it was written with LSP concepts (TextEdit and arrays) in mind. We should consider re-writing it to use more modern concepts/features.

@davidwengier davidwengier self-assigned this Sep 5, 2024
davidwengier added a commit that referenced this issue Sep 10, 2024
…dit` (#10855)

Fixes #10842

The formatting self-nerd-sniping continues.

The formatting engine was written to use the LSP `TextEdit` class, which
makes some sense, but also uses Roslyn APIs like `SourceText` a lot,
which uses the `TextChange` struct instead. This meant lots of code to
convert to and from the two types. Changing the whole formatting engine
over to `TextChange`, and using more `TextSpan`, `LinePositionSpan` etc.
removes a lot of this code. It also makes a lot more sense in cohosting,
to boot.

I wouldn't claim that I've gone through and improved the perf of the
formatting engine, but rather I've use the changes to lead me to things
that need fixing. ie, I started out moving from `TextEdit[]` to
`ImmutableArray<TextChange>`, and this let me to places where pooled
array builders could be used, and places where `Range` and `Position`
were used which didn't make much sense, and then the constructor for
`LinePosition` threw at one point because it turns out we were only
using the `Line` property from the `Position` that used to be used, and
so never validated the characters, so that API moved to `int`, etc.

TL;DR the commits tell the story, and there could well be something I
missed, if it never came across my plate for another reason.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant