fix panic when rustc tries to reduce intermediate filenames length with multi byte chars

The issue cannot be reproduced with the former testcase of creating external crates because
rust refuses to use "external crate 28_找出字符串中第一个匹配项的下标"
because it is not a valid indentifier (starts with number, and contain non ascii chars)

But still using 28_找出字符串中第一个匹配项的下标.rs as a filename is accepted by previous rustc releases
So we consider it valid, and add an integration test for it to catch any regression on other code related to non ascii filenames.

(cherry picked from commit c6acffe)

Author: tardyp

compiler/rustc_session/src/config.rs

@@ -1207,13 +1207,22 @@ fn maybe_strip_file_name(mut path: PathBuf) -> PathBuf {
     if path.file_name().map_or(0, |name| name.len()) > MAX_FILENAME_LENGTH {
         let filename = path.file_name().unwrap().to_string_lossy();
         let hash_len = 64 / 4; // Hash64 is 64 bits encoded in hex
-        let stripped_len = filename.len() - MAX_FILENAME_LENGTH + hash_len;
+        let hyphen_len = 1; // the '-' we insert between hash and suffix
+
+        // number of bytes of suffix we can keep so that "hash-<suffix>" fits
+        let allowed_suffix = MAX_FILENAME_LENGTH.saturating_sub(hash_len + hyphen_len);
+
+        // number of bytes to remove from the start
+        let stripped_bytes = filename.len().saturating_sub(allowed_suffix);
+
+        // ensure we don't cut in a middle of a char
+        let split_at = filename.ceil_char_boundary(stripped_bytes);
 
         let mut hasher = StableHasher::new();
-        filename[..stripped_len].hash(&mut hasher);
+        filename[..split_at].hash(&mut hasher);
         let hash = hasher.finish::<Hash64>();
 
-        path.set_file_name(format!("{:x}-{}", hash, &filename[stripped_len..]));
+        path.set_file_name(format!("{:x}-{}", hash, &filename[split_at..]));
     }
     path
 }

compiler/rustc_session/src/lib.rs

@@ -1,5 +1,6 @@
 // tidy-alphabetical-start
 #![allow(internal_features)]
+#![cfg_attr(bootstrap, feature(round_char_boundary))]
 #![feature(default_field_values)]
 #![feature(iter_intersperse)]
 #![feature(rustc_attrs)]

tests/run-make/lto-long-filenames/rmake.rs

@@ -9,8 +9,6 @@
 
 //@ ignore-cross-compile
 
-use std::fs;
-
 use run_make_support::{rfs, rustc};
 
 // This test make sure we don't get such following error:

tests/run-make/lto-long-filenames_cn/rmake.rs

@@ -0,0 +1,25 @@
+//@ ignore-cross-compile
+// gnu ld is confused with intermediate files having multibytes characters in their names:
+// = note: ld.exe: cannot find f0d5ff18d6510ebc-???_???_??????????_?_?????_?_???????.d50c2 \
+// 4c0c4ea93cc-cgu.0.rcgu.o: Invalid argument
+// as this is not something rustc can fix by itself,
+// we just skip the test on windows-gnu for now. Hence:
+//@ ignore-windows-gnu
+
+use run_make_support::{rfs, rustc};
+
+// This test make sure we don't crash when lto creates output files with long names.
+// cn characters can be multi-byte and thus trigger the long filename reduction code more easily.
+// we need to make sure that the code is properly generating names at char boundaries.
+// as reported in issue #147975
+fn main() {
+    let lto_flags = ["-Clto", "-Clto=yes", "-Clto=off", "-Clto=thin", "-Clto=fat"];
+    for prefix_len in 0..4 {
+        let prefix: String = std::iter::repeat("_").take(prefix_len).collect();
+        let main_file = format!("{}ⵅⴻⵎⵎⴻⵎ_ⴷⵉⵎⴰ_ⵖⴻⴼ_ⵢⵉⵙⴻⴽⴽⵉⵍⴻⵏ_ⵏ_ⵡⴰⵟⴰⵙ_ⵏ_ⵢⵉⴱⵢⵜⴻⵏ.rs", prefix);
+        rfs::write(&main_file, "fn main() {}\n");
+        for flag in lto_flags {
+            rustc().input(&main_file).arg(flag).run();
+        }
+    }
+}