rust/tests/ui/linkage-attr/linkage2.rs

// check-fail

#![feature(linkage)]

extern "C" {
    #[linkage = "extern_weak"]
    static foo: i32;
//~^ ERROR: invalid type for variable with `#[linkage]` attribute
}

fn main() {
    println!("{}", unsafe { foo });
}
Move linkage type check to HIR analysis and fix semantics issues. This ensures that the error is printed even for unused variables, as well as unifying the handling between the LLVM and GCC backends. This also fixes unusual behavior around exported Rust-defined variables with linkage attributes. With the previous behavior, it appears to be impossible to define such a variable such that it can actually be imported and used by another crate. This is because on the importing side, the variable is required to be a pointer, but on the exporting side, the type checker rejects static variables of pointer type because they do not implement `Sync`. Even if it were possible to import such a type, it appears that code generation on the importing side would add an unexpected additional level of pointer indirection, which would break type safety. This highlighted that the semantics of linkage on Rust-defined variables is different to linkage on foreign items. As such, we now model the difference with two different codegen attributes: linkage for Rust-defined variables, and import_linkage for foreign items. This change gives semantics to the test src/test/ui/linkage-attr/auxiliary/def_illtyped_external.rs which was previously expected to fail to compile. Therefore, convert it into a test that is expected to successfully compile. The update to the GCC backend is speculative and untested. 2022-11-23 20:13:30 -06:00			`// check-fail`
normalize away spurious error 2019-04-09 15:08:57 -05:00
Convert most code to new inner attribute syntax. Closes #2569 2014-03-21 20:05:05 -05:00			`#![feature(linkage)]`
rustc: Support various flavors of linkages It is often convenient to have forms of weak linkage or other various types of linkage. Sadly, just using these flavors of linkage are not compatible with Rust's typesystem and how it considers some pointers to be non-null. As a compromise, this commit adds support for weak linkage to external symbols, but it requires that this is only placed on extern statics of type `T`. Codegen-wise, we get translations like: // rust code extern { #[linkage = "extern_weak"] static foo: i32; } // generated IR @foo = extern_weak global i32 @_some_internal_symbol = internal global *i32 @foo All references to the rust value of `foo` then reference `_some_internal_symbol` instead of the symbol `_foo` itself. This allows us to guarantee that the address of `foo` will never be null while the value may sometimes be null. An example was implemented in `std::rt::thread` to determine if `__pthread_get_minstack()` is available at runtime, and a test is checked in to use it for a static value as well. Function pointers a little odd because you still need to transmute the pointer value to a function pointer, but it's thankfully better than not having this capability at all. 2014-02-25 18:15:10 -06:00
Update tests for extern block linting 2020-09-01 16:12:52 -05:00			`extern "C" {`
			`#[linkage = "extern_weak"]`
			`static foo: i32;`
Support Option and similar enums as type of static variable with linkage attribute. Compiler MCP: https://github.com/rust-lang/compiler-team/issues/565 2022-11-23 20:15:50 -06:00			//~^ ERROR: invalid type for variable with `#[linkage]` attribute
rustc: Support various flavors of linkages It is often convenient to have forms of weak linkage or other various types of linkage. Sadly, just using these flavors of linkage are not compatible with Rust's typesystem and how it considers some pointers to be non-null. As a compromise, this commit adds support for weak linkage to external symbols, but it requires that this is only placed on extern statics of type `T`. Codegen-wise, we get translations like: // rust code extern { #[linkage = "extern_weak"] static foo: i32; } // generated IR @foo = extern_weak global i32 @_some_internal_symbol = internal global *i32 @foo All references to the rust value of `foo` then reference `_some_internal_symbol` instead of the symbol `_foo` itself. This allows us to guarantee that the address of `foo` will never be null while the value may sometimes be null. An example was implemented in `std::rt::thread` to determine if `__pthread_get_minstack()` is available at runtime, and a test is checked in to use it for a static value as well. Function pointers a little odd because you still need to transmute the pointer value to a function pointer, but it's thankfully better than not having this capability at all. 2014-02-25 18:15:10 -06:00			`}`

			`fn main() {`
Issue deprecation warnings for safe accesses to extern statics 2016-08-26 11:23:42 -05:00			`println!("{}", unsafe { foo });`
rustc: Support various flavors of linkages It is often convenient to have forms of weak linkage or other various types of linkage. Sadly, just using these flavors of linkage are not compatible with Rust's typesystem and how it considers some pointers to be non-null. As a compromise, this commit adds support for weak linkage to external symbols, but it requires that this is only placed on extern statics of type `T`. Codegen-wise, we get translations like: // rust code extern { #[linkage = "extern_weak"] static foo: i32; } // generated IR @foo = extern_weak global i32 @_some_internal_symbol = internal global *i32 @foo All references to the rust value of `foo` then reference `_some_internal_symbol` instead of the symbol `_foo` itself. This allows us to guarantee that the address of `foo` will never be null while the value may sometimes be null. An example was implemented in `std::rt::thread` to determine if `__pthread_get_minstack()` is available at runtime, and a test is checked in to use it for a static value as well. Function pointers a little odd because you still need to transmute the pointer value to a function pointer, but it's thankfully better than not having this capability at all. 2014-02-25 18:15:10 -06:00			`}`