rust/tests/run-make/use-extern-for-plugins/bar.rs

#![feature(no_core)]
#![no_core]
#![crate_type = "lib"]
#![crate_name = "a"]

#[macro_export]
macro_rules! bar {
    () => ()
}
syntax: Implement #![no_core] This commit is an implementation of [RFC 1184][rfc] which tweaks the behavior of the `#![no_std]` attribute and adds a new `#![no_core]` attribute. The `#![no_std]` attribute now injects `extern crate core` at the top of the crate as well as the libcore prelude into all modules (in the same manner as the standard library's prelude). The `#![no_core]` attribute disables both std and core injection. [rfc]: https://github.com/rust-lang/rfcs/pull/1184 2015-07-29 19:01:14 -05:00			`#![feature(no_core)]`
			`#![no_core]`
rustc: Don't fall back to -L if using --extern The compiler would previously fall back to using `-L` and normal lookup paths if a `--extern` path was specified but it did not match (wrong architecture, for example). This commit removes this behavior and forces the hand of the crate loader to always use the `--extern` path if specified, no matter whether it is correct or not. This fixes a bug today where the compiler's own libraries are favored in cross compilation by accident. For example when a crate using the crates.io version of `log` was cross compiled, Cargo would compile `log` for the target architecture. When loading the macros, however, the compiler currently favors using the host architecture (for plugins), and because the `--extern log=...` pointed at an rlib for the target architecture, that lookup failed. The crate loader then fell back on `-L` paths to find the compiler-used `log` crate (the wrong one!) and then a compile failure happened because the logging macros are slightly different. 2015-02-06 15:40:00 -06:00			`#![crate_type = "lib"]`
			`#![crate_name = "a"]`

			`#[macro_export]`
			`macro_rules! bar {`
			`() => ()`
			`}`