Skip to content

Conversation

@katrinafyi
Copy link
Member

Fixes #1992. Doesn't change anything aside from formatting.

It looks like rustfmt gives up on a function if it has strings which exceed the max_width, because rustfmt doesn't make any changes to string literals.

After some long strings are manually broken up, rustfmt can format the rest of the function.

Example of manual change, old:

            ErrorKind::MissingGitHubToken => Some(
                "GitHub token required. Use --github-token flag or GITHUB_TOKEN environment variable".to_string()
            ),

new:

            ErrorKind::MissingGitHubToken => Some(format!(
                "GitHub token required. {}",
                "Use --github-token flag or GITHUB_TOKEN environment variable",
            )),

Unfortunately, this PR doesn't do anything to prevent this happening again. Some options I looked into:

  • The rustfmt options error_on_line_overflow and error_on_unformatted seemed promising. However, I tried both and they do not report the long strings as problems, but they do report different unrelated errors across the codebase.
  • Enable rustfmt option format_strings. Does fix the problem, but sometimes introduces \ inside string literals. Also, the option is unstable and has some known bugs. Could be chosen as a trade-off.

@katrinafyi katrinafyi changed the title Fix formatting in ErrorKind::details() Fix source code formatting in ErrorKind::details() Jan 16, 2026
@thomas-zahner thomas-zahner merged commit f48fcc9 into lycheeverse:master Jan 19, 2026
7 checks passed
@mre mre mentioned this pull request Jan 14, 2026
@thomas-zahner
Copy link
Member

Thank you! I didn't know about this limitation until now, but I also remember being confused why rustfmt didn't work int that section and thought it was an issue on my side. (blaming my IDE probably)

format_strings sounds promising, but I guess we need to wait until it's stabilised. I really wouldn't use it while unstable.

@mre
Copy link
Member

mre commented Jan 25, 2026

Nice catch. It looks much better now.

@mre mre mentioned this pull request Jan 25, 2026
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.

Why is ErrorKind::details not formatted?

3 participants