Rename some "issue-#" crates

Author: mejrs

src/tools/tidy/src/issues.txt

@@ -276,13 +276,7 @@ ui/auto-traits/issue-23080-2.rs
 ui/auto-traits/issue-23080.rs
 ui/auto-traits/issue-83857-ub.rs
 ui/auto-traits/issue-84075.rs
-ui/auxiliary/issue-13560-1.rs
-ui/auxiliary/issue-13560-2.rs
-ui/auxiliary/issue-13560-3.rs
 ui/auxiliary/issue-16822.rs
-ui/auxiliary/issue-18502.rs
-ui/auxiliary/issue-24106.rs
-ui/auxiliary/issue-76387.rs
 ui/bench/issue-32062.rs
 ui/binding/issue-40402-1.rs
 ui/binding/issue-40402-2.rs
@@ -1378,12 +1372,8 @@ ui/intrinsics/issue-28575.rs
 ui/intrinsics/issue-84297-reifying-copy.rs
 ui/invalid/issue-114435-layout-type-err.rs
 ui/issue-11881.rs
-ui/issue-13560.rs
 ui/issue-15924.rs
 ui/issue-16822.rs
-ui/issue-18502.rs
-ui/issue-24106.rs
-ui/issue-76387-llvm-miscompile.rs
 ui/issues-71798.rs
 ui/issues/auxiliary/issue-11224.rs
 ui/issues/auxiliary/issue-11508.rs

tests/ui/attributes/no_link/auxiliary/issue-13560-1.rs renamed to tests/ui/attributes/no_link/auxiliary/empty-crate-1.rs

@@ -0,0 +1,6 @@
+//@ no-prefer-dynamic
+
+#![crate_type = "rlib"]
+
+#[macro_use] #[no_link] extern crate empty_crate_1 as t1;
+#[macro_use] extern crate empty_crate_2 as t2;

tests/ui/attributes/no_link/auxiliary/issue-13560-2.rs renamed to tests/ui/attributes/no_link/auxiliary/empty-crate-2.rs

@@ -0,0 +1,13 @@
+//@ run-pass
+//@ ignore-cross-compile (needs dylibs and compiletest doesn't have a more specific header)
+//@ aux-build:empty-crate-1.rs
+//@ aux-build:empty-crate-2.rs
+//@ aux-build:no_link-crate.rs
+
+// Regression test for issue #13560, the test itself is all in the dependent
+// libraries. The fail which previously failed to compile is `no_link_crate`.
+
+extern crate empty_crate_2 as t2;
+extern crate no_link_crate as t3;
+
+fn main() {}

tests/ui/attributes/no_link/auxiliary/issue-13560-3.rs

@@ -0,0 +1,12 @@
+//! Dpn't ice on using an inlined function from another crate
+//! See <https://github.com/rust-lang/rust/issues/18502> and
+//! <https://github.com/rust-lang/rust/issues/18501>
+
+//@ run-pass
+//@ aux-build:inline-cross-crate.rs
+
+extern crate inline_cross_crate as fmt;
+
+fn main() {
+    ::fmt::baz();
+}

tests/ui/attributes/no_link/auxiliary/no_link-crate.rs

@@ -1,13 +1,13 @@
 //@ compile-flags: -C opt-level=3
-//@ aux-build: issue-76387.rs
+//@ aux-build: llvm-miscompile-MarkValue-MaybeLive.rs
 //@ run-pass
 
-// Regression test for issue #76387
+// Regression test for <https://github.com/rust-lang/rust/issues/76387>
 // Tests that LLVM doesn't miscompile this
 
-extern crate issue_76387;
+extern crate llvm_miscompile_MarkValue_MaybeLive;
 
-use issue_76387::FatPtr;
+use llvm_miscompile_MarkValue_MaybeLive::FatPtr;
 
 fn print(data: &[u8]) {
     println!("{:#?}", data);

tests/ui/attributes/no_link/issue-13560.rs

@@ -0,0 +1,13 @@
+//! Test that we can match on enum constants across crates.
+//!
+//! See <https://github.com/rust-lang/rust/issues/24106>.
+
+
+//@ run-pass
+//@ aux-build:cross-crate-enum-pattern.rs
+
+extern crate cross_crate_enum_pattern;
+
+fn main() {
+    cross_crate_enum_pattern::go::<()>();
+}

tests/ui/attributes/no_link/multiple-crates-and-no_link.rs

@@ -1,3 +1,19 @@
+//! Test for inner statics with the same name.
+//!
+//! Before, the path name for all items defined in methods of traits and impls never
+//! took into account the name of the method. This meant that if you had two statics
+//! of the same name in two different methods the statics would end up having the
+//! same symbol named (even after mangling) because the path components leading to
+//! the symbol were exactly the same (just __extensions__ and the static name).
+//!
+//! It turns out that if you add the symbol "A" twice to LLVM, it automatically
+//! makes the second one "A1" instead of "A". What this meant is that in local crate
+//! compilations we never found this bug. Even across crates, this was never a
+//! problem. The problem arises when you have generic methods that don't get
+//! generated at compile-time of a library. If the statics were re-added to LLVM by
+//! a client crate of a library in a different order, you would reference different
+//! constants (the integer suffixes wouldn't be guaranteed to be the same).
+
 pub struct A<T> { pub v: T }
 pub struct B<T> { pub v: T }
 

tests/ui/cross-crate/auxiliary/issue-18502.rs renamed to tests/ui/cross-crate/auxiliary/inline-cross-crate.rs

@@ -1,3 +1,19 @@
+//! Test for inner statics with the same name.
+//!
+//! Before, the path name for all items defined in methods of traits and impls never
+//! took into account the name of the method. This meant that if you had two statics
+//! of the same name in two different methods the statics would end up having the
+//! same symbol named (even after mangling) because the path components leading to
+//! the symbol were exactly the same (just __extensions__ and the static name).
+//!
+//! It turns out that if you add the symbol "A" twice to LLVM, it automatically
+//! makes the second one "A1" instead of "A". What this meant is that in local crate
+//! compilations we never found this bug. Even across crates, this was never a
+//! problem. The problem arises when you have generic methods that don't get
+//! generated at compile-time of a library. If the statics were re-added to LLVM by
+//! a client crate of a library in a different order, you would reference different
+//! constants (the integer suffixes wouldn't be guaranteed to be the same).
+
 //@ run-pass
 //@ aux-build:inner_static.rs