blob: 1c62046438fc1fa6116bcf2fa63ae20f8294aabf (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
|
//! 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 }
pub mod test {
pub struct A<T> { pub v: T }
impl<T> A<T> {
pub fn foo(&self) -> isize {
static a: isize = 5;
return a
}
pub fn bar(&self) -> isize {
static a: isize = 6;
return a;
}
}
}
impl<T> A<T> {
pub fn foo(&self) -> isize {
static a: isize = 1;
return a
}
pub fn bar(&self) -> isize {
static a: isize = 2;
return a;
}
}
impl<T> B<T> {
pub fn foo(&self) -> isize {
static a: isize = 3;
return a
}
pub fn bar(&self) -> isize {
static a: isize = 4;
return a;
}
}
pub fn foo() -> isize {
let a = A { v: () };
let b = B { v: () };
let c = test::A { v: () };
return a.foo() + a.bar() +
b.foo() + b.bar() +
c.foo() + c.bar();
}
|
