about summary refs log tree commit diff
path: root/src/test/run-make/use-extern-for-plugins
AgeCommit message (Collapse)AuthorLines
2018-03-22rustc: Add a `#[wasm_custom_section]` attributeAlex Crichton-76/+0
This commit is an implementation of adding custom sections to wasm artifacts in rustc. The intention here is to expose the ability of the wasm binary format to contain custom sections with arbitrary user-defined data. Currently neither our version of LLVM nor LLD supports this so the implementation is currently custom to rustc itself. The implementation here is to attach a `#[wasm_custom_section = "foo"]` attribute to any `const` which has a type like `[u8; N]`. Other types of constants aren't supported yet but may be added one day! This should hopefully be enough to get off the ground with *some* custom section support. The current semantics are that any constant tagged with `#[wasm_custom_section]` section will be *appended* to the corresponding section in the final output wasm artifact (and this affects dependencies linked in as well, not just the final crate). This means that whatever is interpreting the contents must be able to interpret binary-concatenated sections (or each constant needs to be in its own custom section). To test this change the existing `run-make` test suite was moved to a `run-make-fulldeps` folder and a new `run-make` test suite was added which applies to all targets by default. This test suite currently only has one test which only runs for the wasm target (using a node.js script to use `WebAssembly` in JS to parse the wasm output).
2016-01-31Add Illumos supportNikita Baksalyar-1/+1
2015-12-05std: Stabilize APIs for the 1.6 releaseAlex Crichton-1/+0
This commit is the standard API stabilization commit for the 1.6 release cycle. The list of issues and APIs below have all been through their cycle-long FCP and the libs team decisions are listed below Stabilized APIs * `Read::read_exact` * `ErrorKind::UnexpectedEof` (renamed from `UnexpectedEOF`) * libcore -- this was a bit of a nuanced stabilization, the crate itself is now marked as `#[stable]` and the methods appearing via traits for primitives like `char` and `str` are now also marked as stable. Note that the extension traits themeselves are marked as unstable as they're imported via the prelude. The `try!` macro was also moved from the standard library into libcore to have the same interface. Otherwise the functions all have copied stability from the standard library now. * The `#![no_std]` attribute * `fs::DirBuilder` * `fs::DirBuilder::new` * `fs::DirBuilder::recursive` * `fs::DirBuilder::create` * `os::unix::fs::DirBuilderExt` * `os::unix::fs::DirBuilderExt::mode` * `vec::Drain` * `vec::Vec::drain` * `string::Drain` * `string::String::drain` * `vec_deque::Drain` * `vec_deque::VecDeque::drain` * `collections::hash_map::Drain` * `collections::hash_map::HashMap::drain` * `collections::hash_set::Drain` * `collections::hash_set::HashSet::drain` * `collections::binary_heap::Drain` * `collections::binary_heap::BinaryHeap::drain` * `Vec::extend_from_slice` (renamed from `push_all`) * `Mutex::get_mut` * `Mutex::into_inner` * `RwLock::get_mut` * `RwLock::into_inner` * `Iterator::min_by_key` (renamed from `min_by`) * `Iterator::max_by_key` (renamed from `max_by`) Deprecated APIs * `ErrorKind::UnexpectedEOF` (renamed to `UnexpectedEof`) * `OsString::from_bytes` * `OsStr::to_cstring` * `OsStr::to_bytes` * `fs::walk_dir` and `fs::WalkDir` * `path::Components::peek` * `slice::bytes::MutableByteVector` * `slice::bytes::copy_memory` * `Vec::push_all` (renamed to `extend_from_slice`) * `Duration::span` * `IpAddr` * `SocketAddr::ip` * `Read::tee` * `io::Tee` * `Write::broadcast` * `io::Broadcast` * `Iterator::min_by` (renamed to `min_by_key`) * `Iterator::max_by` (renamed to `max_by_key`) * `net::lookup_addr` New APIs (still unstable) * `<[T]>::sort_by_key` (added to mirror `min_by_key`) Closes #27585 Closes #27704 Closes #27707 Closes #27710 Closes #27711 Closes #27727 Closes #27740 Closes #27744 Closes #27799 Closes #27801 cc #27801 (doesn't close as `Chars` is still unstable) Closes #28968
2015-08-03syntax: Implement #![no_core]Alex Crichton-4/+4
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-04-04fixing some tests and temporarily disabling others to get Bitrig build ↵Dave Huseby-2/+5
working 100%
2015-02-15Fix tests that fail on FreeBSDWill-2/+2
2015-02-08adapt run-make test suite for openbsdSébastien Marie-0/+5
- c-link-to-rust-staticlib: use EXTRACFLAGS defined by tools.mk for choose the good libraries to link to. - no-stack-check: disabled for openbsd (no segmented stacks here) - symbols-are-reasonable: use portable grep pattern - target-specs: use POSIX form for options when invoking grep - use-extern-for-plugins: disable as OpenBSD only support x86_64 for now
2015-02-06rustc: Don't fall back to -L if using --externAlex Crichton-0/+69
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.