dotnet / dotnet/format

Spaces before input parameters of a lambda expression are breaking the formatting

Open
#1,265 0 comments 0 reactions 0 assignees View on GitHub
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.