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

dotnet format whitespace --verify-no-changes fails on"/" char #1955

Closed
Nowak-Kacper opened this issue Sep 14, 2023 · 10 comments
Closed

dotnet format whitespace --verify-no-changes fails on"/" char #1955

Nowak-Kacper opened this issue Sep 14, 2023 · 10 comments
Labels
Needs More Info This issue needs additional details to be actionable

Comments

@Nowak-Kacper
Copy link

Nowak-Kacper commented Sep 14, 2023

Hi everyone,
as in title dotnet format whitespace --verify-no-changes fails in lines where "/" char is.
I am running command with git workflow so it might be related to this.

Error:
Program.cs(6,3): error WHITESPACE: Fix whitespace formatting. Replace 4 characters with '\n\t\t'.
Program.cs(12,1): error WHITESPACE: Fix whitespace formatting. Replace 2 characters with '\t\t'.

This is the content of my .gitattributes file:

# Set the default behavior, in case people don't have core.autocrlf set.
**/* text=auto

# Declare files that will always have CRLF line endings on checkout.
**/*.cs text eol=crlf
@JoeRobich
Copy link
Member

From the whitespace errors it appears to be trying to fixup indentation by replacing characters with tabs. Is it possible there are mixed spaces and tabs? Also, are the line numbers accurate?

@Nowak-Kacper
Copy link
Author

Nowak-Kacper commented Sep 15, 2023

  1. Line numbers are good, sometimes error is pointing to the line above/under thie line with "/" characters
  2. Indents are correct, no mixed spaces/tabs
    For more context i can add that i have over 700 errors and all of them are in lines with "/" or above/down

One more error example, maybe it will bring something new.
(233,4): error WHITESPACE: Fix whitespace formatting. Replace 5 characters with '\n\t\t\t'.
(234,14): error WHITESPACE: Fix whitespace formatting. Replace 5 characters with '\n\t\t\t'.
(242,47): error WHITESPACE: Fix whitespace formatting. Replace 7 characters with '\n\n\t\t\t'.
(244,10): error WHITESPACE: Fix whitespace formatting. Replace 5 characters with '\n\t\t\t'.
(246,44): error WHITESPACE: Fix whitespace formatting. Replace 7 characters with '\n\n\t\t\t'.
(248,13): error WHITESPACE: Fix whitespace formatting. Replace 5 characters with '\n\t\t\t'.
In file all indents are ok, locally i can not reproduce this error.

@JoeRobich
Copy link
Member

Declare files that will always have CRLF line endings on checkout.
**/*.cs text eol=crlf

So we are always checking these files out with windows line endings. Does your .editorconfig also specify end_of_line=crlf for *.cs files? Otherwise, the formatter will default to the platform specific line ending.

@Nowak-Kacper
Copy link
Author

Nowak-Kacper commented Sep 18, 2023

Currently not, previously I had it but there was more errors than now, should I bring it back? If yes, how should I update some files on git to crlf format? By running git ls-files --eol I see some files are in lf.

I tried to run git add --renormalize . with eol set to crlf in .gitattributes and .editorcong but it overwrites only files in crlf format, and seems to be ignoring the lf files.

@JoeRobich
Copy link
Member

@Nowak-Kacper
Copy link
Author

Already done this, just to be sure I did it again today, but some files are still in lf format.
Part of output from git ls-files --eol

i/mixed w/crlf  attr/
i/crlf  w/crlf  attr/
i/crlf  w/crlf  attr/
i/mixed w/crlf  attr/
i/crlf  w/crlf  attr/
i/lf    w/crlf  attr/ 
i/lf    w/crlf  attr/ 
i/lf    w/crlf  attr/ 
i/crlf  w/crlf  attr/
i/lf    w/crlf  attr/ 
i/lf    w/crlf  attr/ 
i/lf    w/crlf  attr/ 
i/crlf  w/crlf  attr/
i/lf    w/crlf  attr/
i/lf    w/crlf  attr/
i/crlf  w/crlf  attr/

@JoeRobich
Copy link
Member

Not saying this is the issue, just something I noticed after looking at a few .gitattributes files (see https://grep.app/search?q=.cs+text+eol). You could simplify yours by removing the directory separators.

# Set the default behavior, in case people don't have core.autocrlf set.
- */ text=auto
+ * text=auto
# Declare files that will always have CRLF line endings on checkout.
- **/*.cs text eol=crlf
+ *.cs text eol=crlf

Not sure how much more help I can be. In the absence of an end_of_line settings in the .editorconfig, dotnet-format will default to using the environment newline for line endings, which may not match your .gitattributes configuration. So, if you are not letting git automatically handle line endings you will want to configure your .editorconfig to match.

@sharwell
Copy link
Member

sharwell commented Feb 15, 2024

Also note that you want to make this change:

-*.cs text eol=crlf
+*.cs text=auto eol=crlf

⚠️ I would not recommend setting eol in .gitattributes or end_of_line .editorconfig. These lines are an immediate configuration red flag for me.

@sharwell sharwell added the Needs More Info This issue needs additional details to be actionable label Feb 15, 2024
@ghost ghost closed this as completed Feb 25, 2024
@ghost
Copy link

ghost commented Feb 25, 2024

Closing this issue as we've seen no reply to the request for more information. If you are able to get the requested information, please add it to the issue and we will retriage it.

@seantleonard
Copy link

seantleonard commented Apr 2, 2024

Also note that you want to make this change:

-*.cs text eol=crlf
+*.cs text=auto eol=crlf

⚠️ I would not recommend setting eol in .gitattributes or end_of_line .editorconfig. These lines are an immediate configuration red flag for me.

Can you provide an example of your preferred configuration? sharwell

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs More Info This issue needs additional details to be actionable
Projects
None yet
Development

No branches or pull requests

4 participants