Spaces before input parameters of a lambda expression are breaking the formatting
- Dominant language
- No language data
- Stars
- 1.9k
- Forks
- 173
- Avg merge
- 10d 13h
- Merged PRs (30d)
- 1
Description
Hi, I'm working in the Graphics repository at Unity, we noticed an edge-case issue with dotnet-format.
- [editorconfig file](https://github.com/Unity-Technologies/Graphics/commit/d2d547be908203d40a2cddd09f56366beddffde4).
- Command used: `dotnet format -f . --include .\com.unity.render-pipelines.universal\Editor\Converter\ReadonlyMaterialConverter.cs`
## What is happening
Running `dotnet format` on a file containing a lambda with input parameters separated by more than 1 space from the previous argument within a function is making dotnet format remove 1 space at each line start in the lambda. The indentation is then broken (odd number of spaces instead of even).
I made [this commit on a separated branch](https://github.com/Unity-Technologies/Graphics/commit/5d79e415ce56152608977d375967a60a86762d30) to better visualize.
## What is expected
Running `dotnet format` on this sort of lambdas does not remove spaces for each line of the lambda, regardless of how the input parameters are originally formatted. It is expected to reduce the number of spaces before the input parameters to 1 though (as was done [in this commit manually](https://github.com/Unity-Technologies/Graphics/commit/a97838f94d8e217cd467b3b5c33140fc1dabff41))
## What I tried
Manually removing the extra spaces in [this commit](https://github.com/Unity-Technologies/Graphics/commit/a97838f94d8e217cd467b3b5c33140fc1dabff41) and then rerunning the formatter. In that case there is no problem, the formatter does not generate any diff.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.