rust/tests/ui/inner-static.rs

//@ run-pass
//@ aux-build:inner_static.rs


extern crate inner_static;

pub fn main() {
    let a = inner_static::A::<()> { v: () };
    let b = inner_static::B::<()> { v: () };
    let c = inner_static::test::A::<()> { v: () };
    assert_eq!(a.bar(), 2);
    assert_eq!(b.bar(), 4);
    assert_eq!(c.bar(), 6);
}
tests: Add missing run-pass annotations 2019-07-26 21:54:25 +00:00			`//@ run-pass`
Fix inner statics having the same symbol 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). This fixes the problem by adding the method name to symbol path when building the ast_map. In doing so, two symbols in two different methods are disambiguated against. 2013-08-30 05:29:26 +00:00			`//@ aux-build:inner_static.rs`

rustdoc: Replace no-pretty-expanded with pretty-expanded Now that features must be declared expanded source often does not compile. This adds 'pretty-expanded' to a bunch of test cases that still work. 2015-03-22 20:13:15 +00:00
extern mod => extern crate This was previously implemented, and it just needed a snapshot to go through 2014-02-14 18:10:06 +00:00			`extern crate inner_static;`
Fix inner statics having the same symbol 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). This fixes the problem by adding the method name to symbol path when building the ast_map. In doing so, two symbols in two different methods are disambiguated against. 2013-08-30 05:29:26 +00:00
			`pub fn main() {`
Fallout: tests. As tests frequently elide things, lots of changes here. Some of this may have been poorly rebased, though I tried to be careful and preserve the spirit of the test. 2015-02-12 15:29:52 +00:00			`let a = inner_static::A::<()> { v: () };`
			`let b = inner_static::B::<()> { v: () };`
			`let c = inner_static::test::A::<()> { v: () };`
Remove __extensions__ in names for a "pretty name" As with the previous commit, this is targeted at removing the possibility of collisions between statics. The main use case here is when there's a type-parametric function with an inner static that's compiled as a library. Before this commit, any impl would generate a path item of "__extensions__". This changes this identifier to be a "pretty name", which is either the last element of the path of the trait implemented or the last element of the type's path that's being implemented. That doesn't quite cut it though, so the (trait, type) pair is hashed and again used to append information to the symbol. Essentially, __extensions__ was removed for something nicer for debugging, and then some more information was added to symbol name by including a hash of the trait being implemented and type it's being implemented for. This should prevent colliding names for inner statics in regular functions with similar names. 2013-08-30 07:47:10 +00:00			`assert_eq!(a.bar(), 2);`
			`assert_eq!(b.bar(), 4);`
			`assert_eq!(c.bar(), 6);`
Fix inner statics having the same symbol 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). This fixes the problem by adding the method name to symbol path when building the ast_map. In doing so, two symbols in two different methods are disambiguated against. 2013-08-30 05:29:26 +00:00			`}`