String literals with unescaped \ in the end of line is not formatted

[tesuji]

Describe the bug

The Rust reference has an exception rule about unescaped \ at the end of line
of string literals, quoted here:

when an unescaped U+005C character (\) occurs immediately before the line-break,
then the U+005C character, the line-break, and all whitespace at the beginning of
the next line are ignored.

It would be nice if rustfmt format this snippet:

pub fn foo() -> &'static str {
    "use of std::thread::current() is not \
                                          possible after the thread's local \
                                          data has been destroyed"
}

into

pub fn foo() -> &'static str {
    "use of std::thread::current() is not \
     possible after the thread's local \
     data has been destroyed"
}

Meta

• rustfmt version: 1.4.18-nightly (2020-06-13 c1e9b7b) which is the one on playground
• Might be a duplicate of Formatting for calls with multiline string arguments #2876 .

[ayazhafiz]

I think the issues are different; in 2876, the whitespace is significant and it's more about formatting in the context of a call

[ayazhafiz]

You can already do this with the format_strings option, which does a little more:

pub fn foo() -> &'static str {
    "use of std::thread::current() is not \
                                          possible after the thread's local \
                                          data has been destroyed"
}

would go to

pub fn foo() -> &'static str {
    "use of std::thread::current() is not possible after the thread's local data has been \
     destroyed";
}

Would that work for your use case?

[tesuji]

Thanks. Never know about this configuration.
Are there any reasons this is off by default?

[ayazhafiz]

It just was never turned on as a stable option, there is a tracking issue here: #4036

[tesuji]

I try that configuration a bit. It is useful and nice. But I would like to preserve the ending \
in each line, which mean that the configuration would not join multiline together.
For example, this diff is harder to read:

             rustflags.arg("-Zsave-analysis");
             cargo.env(
                 "RUST_SAVE_ANALYSIS_CONFIG",
-                "{\"output_file\": null,\"full_docs\": false,\
-                       \"pub_only\": true,\"reachable_only\": false,\
-                       \"distro_crate\": true,\"signatures\": false,\"borrow_data\": false}",
+                "{\"output_file\": null,\"full_docs\": false,\"pub_only\": \
+                 true,\"reachable_only\": false,\"distro_crate\": true,\"signatures\": \
+                 false,\"borrow_data\": false}",
             );
         }

         if !pass_sanity_check {
             println!("{}\n", subcommand_help);
             println!(
-                "Sorry, I couldn't figure out which subcommand you were trying to specify.\n\
-                 You may need to move some options to after the subcommand.\n"
+                "Sorry, I couldn't figure out which subcommand you were trying to specify.\nYou \
+                 may need to move some options to after the subcommand.\n"
             );
             process::exit(1);
         }

     if !output.status.success() {
         println!(
-            "\n\ncommand did not execute successfully: {:?}\n\
-             expected success, got: {}\n\n\
-             stdout ----\n{}\n\
-             stderr ----\n{}\n\n",
+            "\n\ncommand did not execute successfully: {:?}\nexpected success, got: {}\n\nstdout \
+             ----\n{}\nstderr ----\n{}\n\n",
             cmd,
             output.status,
             String::from_utf8_lossy(&output.stdout),

[tesuji]

Also, is this a bug?

 #[bench]
 fn bench_contains_short_long(b: &mut Bencher) {
-    let haystack = "\
+    let haystack =
+        "\
 Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse quis lorem sit amet dolor \
-ultricies condimentum. Praesent iaculis purus elit, ac malesuada quam malesuada in. Duis sed orci \
-eros. Suspendisse sit amet magna mollis, mollis nunc luctus, imperdiet mi. Integer fringilla non \
-sem ut lacinia. Fusce varius tortor a risus porttitor hendrerit. Morbi mauris dui, ultricies nec \
-tempus vel, gravida nec quam.
+         ultricies condimentum. Praesent iaculis purus elit, ac malesuada quam malesuada in. Duis \
+         sed orci eros. Suspendisse sit amet magna mollis, mollis nunc luctus, imperdiet mi. \
+         Integer fringilla non sem ut lacinia. Fusce varius tortor a risus porttitor hendrerit. \
+         Morbi mauris dui, ultricies nec tempus vel, gravida nec quam.
 

[ayazhafiz]

But I would like to preserve the ending \
in each line, which mean that the configuration would not join multiline together.
For example, this diff is harder to read:

Yeah that makes sense. I agree the formatted version is harder to read. But I think it is unlikely that an option to only format the alignment of a string without formatting other parts of the string would be accepted. In some sense this is a custom formatting.

Also, is this a bug?

Yes, it looks like it. Can you share the entire bench function where that happened?

[tesuji]

Yes, it here: https:/rust-lang/rust/blob/4007d4ef26eab44bdabc2b7574d032152264d3ad/src/liballoc/benches/str.rs#L131

I was trying to use that formatting configuration on Rust repo. But I'm afraid it couldn't be accepted
as the result is not nicer to read.

[ayazhafiz]

Yes I think it’s unlikely to be accepted.

…

________________________________ От: lzutao <[email protected]> Отправлено: Saturday, July 11, 2020 9:40:52 PM Кому: rust-lang/rustfmt <[email protected]> Копия: hafiz <[email protected]>; Comment <[email protected]> Тема: Re: [rust-lang/rustfmt] String literals with unescaped \ in the end of line is not formatted (#4321) Yes, it here: https:/rust-lang/rust/blob/4007d4ef26eab44bdabc2b7574d032152264d3ad/src/liballoc/benches/str.rs#L131 I was trying to use that formatting configuration on Rust repo. But I'm afraid it couldn't be accepted as the result is not nicer to read. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#4321 (comment)>, or unsubscribe<https:/notifications/unsubscribe-auth/AE6GL6SXVEEI7KI4FJSYGT3R3EPDJANCNFSM4OXKHXWQ>.

[ayazhafiz]

@lzutao is there any further action we can take here, aside #4323? If not, is it worth closing this issue?

[tesuji]

I still don't like that strings are merged and formatted. But that's probably a separate issue/RFC for fmts.
But I don't have strong desire for that.
Thanks for your helpful feedback. Closing!