about summary refs log tree commit diff
path: root/src/doc
AgeCommit message (Collapse)AuthorLines
2017-04-16Auto merge of #40409 - mbrubeck:calloc, r=sfacklerbors-0/+5
Specialize Vec::from_elem to use calloc Fixes #38723. This specializes the implementation for `u8` only, but it could be extended to other zeroable types if desired. I haven't tested this extensively, but I did verify that it gives the expected performance boost for large `vec![0; n]` allocations with both alloc_system and jemalloc, on Linux. (I have not tested or even built the Windows code.)
2017-04-15document :vis in unstable bookAlex Burka-0/+15
2017-04-15Specialize Vec::from_elem<u8> to use calloc or memsetMatt Brubeck-0/+5
Fixes #38723.
2017-04-14Add Unstable Book entry for 'overlapping-marker-traits'.Corey Farwell-0/+8
2017-04-14Rollup merge of #40702 - mrhota:global_asm, r=nagisaCorey Farwell-0/+81
Implement global_asm!() (RFC 1548) This is a first attempt. ~~One (potential) problem I haven't solved is how to handle multiple usages of `global_asm!` in a module/crate. It looks like `LLVMSetModuleInlineAsm` overwrites module asm, and `LLVMAppendModuleInlineAsm` is not provided in LLVM C headers 😦~~ I can provide more detail as needed, but honestly, there's not a lot going on here. r? @eddyb CC @Amanieu @jackpot51 Tracking issue: #35119
2017-04-14fix: add missing link in SUMMARY.mdEvgeny Safronov-0/+2
2017-04-14docs: track newly introduced unstable featureEvgeny Safronov-0/+7
2017-04-13Update various bookshelf repositories.steveklabnik-0/+0
The book and the reference have both had changes lately; this integrates them upstream.
2017-04-13Rename compiler_barrier to compiler_fenceJon Gjengset-11/+11
This addresses concerns raised following the merge of #41092. Specifically: > The naming of these seems surprising: the multithreaded functions (and > both the single and multithreaded intrinsics themselves) are fences, > but this is a barrier. It's not incorrect, but the latter is both > inconsistent with the existing functions and slightly confusing with > another type in std (e.g., `Barrier`). `compiler_fence` carries the same semantic implication that this is a compiler-only operation, while being more in line with the fence/barrier concepts already in use in `std`.
2017-04-13Address the PR reviewalexey zabelin-2/+1
2017-04-13Auto merge of #41009 - scottmcm:toowned-clone-into, r=alexcrichtonbors-0/+8
Add a resource-reusing method to `ToOwned` `ToOwned::to_owned` generalizes `Clone::clone`, but `ToOwned` doesn't have an equivalent to `Clone::clone_from`. This PR adds such a method as `clone_into` under a new unstable feature `toowned_clone_into`. Analogous to `clone_from`, this has the obvious default implementation in terms of `to_owned`. I've updated the `libcollections` impls: for `T:Clone` it uses `clone_from`, for `[T]` I moved the code from `Vec::clone_from` and implemented that in terms of this, and for `str` it's a predictable implementation in terms of `[u8]`. Used it in `Cow::clone_from` to reuse resources when both are `Cow::Owned`, and added a test that `Cow<str>` thus keeps capacity in `clone_from` in that situation. The obvious question: is this the right place for the method? - It's here so it lives next to `to_owned`, making the default implementation reasonable, and avoiding another trait. But allowing method syntax forces a name like `clone_into`, rather than something more consistent like `owned_from`. - Another trait would allow `owned_from` and could support multiple owning types per borrow type. But it'd be another single-method trait that generalizes `Clone`, and I don't know how to give it a default impl in terms of `ToOwned::to_owned`, since a blanket would mean overlapping impls problems. I did it this way as it's simpler and many of the `Borrow`s/`AsRef`s don't make sense with `owned_from` anyway (`[T;1]:Borrow<[T]>`, `Arc<T>:Borrow<T>`, `String:AsRef<OsStr>`...). I'd be happy to re-do it the other way, though, if someone has a good solution for the default handling. (I can also update with `CStr`, `OsStr`, and `Path` once a direction is decided.)
2017-04-12Fix old docsalexey zabelin-0/+8
#41158
2017-04-12Add ToOwned::clone_into (unstable as toowned_clone_into)Scott McMurray-0/+8
to_owned generalizes clone; this generalizes clone_from. Use to_owned to give it a default impl. Customize the impl for [T], str, and T:Clone. Use it in Cow::clone_from to reuse resources when cloning Owned into Owned.
2017-04-12Add global_asm testsA.J. Gardner-1/+1
2017-04-12Update unstable book with global_asm featureA.J. Gardner-0/+81
2017-04-11Rollup merge of #40559 - nagisa:manually-drop, r=alexcrichtonCorey Farwell-0/+1
Implement Manually Drop As the RFC has been from approx a week in FCP without any major comments, I’m taking the opportunity to submit the PR early.
2017-04-11Auto merge of #41096 - clarcharr:as_bytes_mut, r=alexcrichtonbors-0/+9
Reduce str transmutes, add mut versions of methods. When I was working on the various parts involved in #40380 one of the comments I got was the excess of transmutes necessary to make the changes work. This is part of a set of multiple changes I'd like to offer to fix this problem. I think that having these methods is reasonable because they're already possible via transmutes, and it makes the code that uses them safer. I can also add `pub(crate)` to these methods for now if the libs team would rather not expose them to the public without an RFC.
2017-04-10Auto merge of #40018 - japaric:ld, r=alexcrichtonbors-0/+62
-Z linker-flavor (Please read the commit message first) This PR is an alternative to rust-lang/rust#36120 (internal lld linker). The main goal of this PR is to make it *possible* to use LLD as a linker to allow out of tree experimentation. Now that LLD is going to be shipped with LLVM 4.0, it should become easier to get a hold of LLD (hopefully, it will be packaged by Linux distros soon). Since LLD is a multiarch linker, it has the potential to make cross compilation easier (less tools need to be installed). Supposedly, LLD is also faster than the gold linker so LLD may improve build times where link times are significant (e.g. 100% incremental compilation reuse). The place where LLD shines is at linking Rust programs that don't depend on system libraries. For example, here's how you would link a bare metal ARM Cortex-M program: ``` $ xargo rustc --target thumbv7m-none-eabi -- -Z linker-flavor=ld -C linker=ld.lld -Z print-link-args "ld.lld" \ "-L" \ "$XARGO_HOME/lib/rustlib/thumbv7m-none-eabi/lib" \ "$PWD/target/thumbv7m-none-eabi/debug/deps/app-de1f86df314ad68c.0.o" \ "-o" \ "$PWD/target/thumbv7m-none-eabi/debug/deps/app-de1f86df314ad68c" \ "--gc-sections" \ "-L" \ "$PWD/target/thumbv7m-none-eabi/debug/deps" \ "-L" \ "$PWD/target/debug/deps" \ "-L" \ "$XARGO_HOME/lib/rustlib/thumbv7m-none-eabi/lib" \ "-Bstatic" \ "-Bdynamic" \ "$XARGO_HOME/lib/rustlib/thumbv7m-none-eabi/lib/libcore-11670d2bd4951fa7.rlib" $ file target/thumbv7m-none-eabi/debug/app app: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped, with debug_info ``` This doesn't require installing the `arm-none-eabi-gcc` toolchain. Even cooler (but I'm biased) is that you can link Rust programs that use [`steed`] (`steed` is a `std` re-implementation free of C dependencies for Linux systems) instead of `std` for a bunch of different architectures without having to install a single cross toolchain. [`steed`]: https://github.com/japaric/steed ``` $ xargo rustc --target aarch64-unknown-linux-steed --example hello --release -- -Z print-link-args "ld.lld" \ "-L" \ "$XARGO_HOME/lib/rustlib/aarch64-unknown-linux-steed/lib" \ "$PWD/target/aarch64-unknown-linux-steed/release/examples/hello-80c130ad884c0f8f.0.o" \ "-o" \ "$PWD/target/aarch64-unknown-linux-steed/release/examples/hello-80c130ad884c0f8f" \ "--gc-sections" \ "-L" \ "$PWD/target/aarch64-unknown-linux-steed/release/deps" \ "-L" \ "$PWD/target/release/deps" \ "-L" \ "$XARGO_HOME/lib/rustlib/aarch64-unknown-linux-steed/lib" \ "-Bstatic" \ "-Bdynamic" \ "/tmp/rustc.lAybk9Ltx93Q/libcompiler_builtins-589aede02de78434.rlib" $ file target/aarch64-unknown-linux-steed/release/examples/hello hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, not stripped, with debug_info ``` All these targets (architectures) worked with LLD: - [aarch64-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/aarch64-unknown-linux-steed.json) - [arm-unknown-linux-steedeabi](https://github.com/japaric/steed/blob/lld/docker/arm-unknown-linux-steedeabi.json) - [arm-unknown-linux-steedeabihf](https://github.com/japaric/steed/blob/lld/docker/arm-unknown-linux-steedeabihf.json) - [armv7-unknown-linux-steedeabihf](https://github.com/japaric/steed/blob/lld/docker/armv7-unknown-linux-steedeabihf.json) - [i686-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/i686-unknown-linux-steed.json) - [mips-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/mips-unknown-linux-steed.json) - [mipsel-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/mipsel-unknown-linux-steed.json) - [powerpc-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/powerpc-unknown-linux-steed.json) - [powerpc64-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/powerpc64-unknown-linux-steed.json) - [x86_64-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/x86_64-unknown-linux-steed.json) --- The case where lld is unergonomic is linking binaries that depend on system libraries. Like "Hello, world" for `x86_64-unknown-linux-gnu`. Because you have to pass as linker arguments: the path to the startup objects, the path to the dynamic linker and the library search paths. And all those are system specific so they can't be encoded in the target itself. ``` $ cargo \ rustc \ --release \ -- \ -C \ linker=ld.lld \ -Z \ linker-flavor=ld \ -C \ link-args='-dynamic-linker /lib64/ld-linux-x86-64.so.2 -L/usr/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1 /usr/lib/Scrt1.o /usr/lib/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/crtbeginS.o /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/crtendS.o /usr/lib/crtn.o' ``` --- Another case where `-Z linker-flavor` may come in handy is directly calling Solaris' linker which is also a multiarch linker (or so I have heard). cc @binarycrusader cc @alexcrichton Heads up: [breaking-change] due to changes in the target specification format.
2017-04-09Reduce str transmutes, add mut versions of methods.Clar Charr-0/+9
2017-04-09Fix test failuresSimonas Kazlauskas-0/+1
2017-04-09Auto merge of #41095 - clarcharr:as_extras, r=alexcrichtonbors-0/+9
Add as_c_str Again, tying up some consistencies with `CString`.
2017-04-08Auto merge of #41092 - jonhoo:std-fence-intrinsics, r=alexcrichtonbors-0/+107
Add safe wrapper for atomic_compilerfence intrinsics This PR adds a proposed safe wrapper for the `atomic_singlethreadfence_*` intrinsics introduced by [RFC #888](https://github.com/rust-lang/rfcs/pull/888). See #41091 for further discussion.
2017-04-08this code block is text not Rust codeJorge Aparicio-1/+1
2017-04-08Address @parched's commentsJon Gjengset-8/+3
2017-04-08Rollup merge of #41135 - japaric:unstable-docs, r=steveklabnikTim Neumann-4/+123
document some existing unstable features "msp430-interrupt", "ptx-kernel" and #![compiler_builtins_lib] r? @steveklabnik
2017-04-07Add as_c_str.Clar Charr-0/+9
2017-04-07hack: add a linker_flavor feature gateJorge Aparicio-1/+1
to make tidy accept `-Z linker-flavor` documentation
2017-04-07add some documentation to the unstable bookJorge Aparicio-0/+62
2017-04-07change the format of the linked issue numberJorge Aparicio-2/+3
2017-04-07Mention interrupts and green threadsJon Gjengset-1/+6
2017-04-07rustdoc needs space after # to ignoreJon Gjengset-6/+6
2017-04-07document some existing unstable featuresJorge Aparicio-4/+122
"msp430-interrupt", "ptx-kernel" and #![compiler_builtins_lib]
2017-04-07Auto merge of #39987 - japaric:used, r=arielb1bors-0/+154
#[used] attribute (For an explanation of what this feature does, read the commit message) I'd like to propose landing this as an experimental feature (experimental as in: no clear stabilization path -- like `asm!`, `#[linkage]`) as it's low maintenance (I think) and relevant to the "Usage in resource-constrained environments" exploration area. The main use case I see is running code before `main`. This could be used, for instance, to cheaply initialize an allocator before `main` where the alternative is to use `lazy_static` to initialize the allocator on its first use which it's more expensive (atomics) and doesn't work on ARM Cortex-M0 microcontrollers (no `AtomicUsize` on that platform) Here's a `std` example of that: ``` rust unsafe extern "C" fn before_main_1() { println!("Hello"); } unsafe extern "C" fn before_main_2() { println!("World"); } #[link_section = ".init_arary"] #[used] static INIT_ARRAY: [unsafe extern "C" fn(); 2] = [before_main_1, before_main_2]; fn main() { println!("Goodbye"); } ``` ``` $ rustc -C lto -C opt-level=3 before_main.rs $ ./before_main Hello World Goodbye ``` In general, this pattern could be used to let *dependencies* run code before `main` (which sounds like it could go very wrong in some cases). There are probably other use cases; I hope that the people I have cc-ed can comment on those. Note that I'm personally unsure if the above pattern is something we want to promote / allow and that's why I'm proposing this feature as experimental. If this leads to more footguns than benefits then we can just axe the feature. cc @nikomatsakis ^ I know you have some thoughts on having a process for experimental features though I'm fine with writing an RFC before landing this. - `dead_code` lint will have to be updated to special case `#[used]` symbols. - Should we extend `#[used]` to work on non-generic functions? cc rust-lang/rfcs#1002 cc rust-lang/rfcs#1459 cc @dpc @JinShil
2017-04-06Correct book examples for hardware re-orderingJon Gjengset-54/+62
2017-04-06ignore the .init_array doctestJorge Aparicio-1/+1
as it's specific to ELF and won't pass on macOS / Windows
2017-04-06add link to issue number, ignore snippet that requires custom linkingJorge Aparicio-2/+3
2017-04-06Point to tracking issue, not PRJon Gjengset-2/+2
2017-04-06Add unstable book entryJon Gjengset-0/+99
2017-04-06add documentation to the unstable bookJorge Aparicio-0/+153
2017-04-05Rollup merge of #41065 - jorendorff:slice-rsplit-41020, r=alexcrichtonAriel Ben-Yehuda-0/+11
[T]::rsplit() and rsplit_mut(), #41020
2017-04-05Rollup merge of #40943 - Amanieu:offset_to, r=alexcrichtonAriel Ben-Yehuda-0/+8
Add ptr::offset_to This PR adds a method to calculate the signed distance (in number of elements) between two pointers. The resulting value can then be passed to `offset` to get one pointer from the other. This is similar to pointer subtraction in C/C++. There are 2 special cases: - If the distance is not a multiple of the element size then the result is rounded towards zero. (in C/C++ this is UB) - ZST return `None`, while normal types return `Some(isize)`. This forces the user to handle the ZST case in unsafe code. (C/C++ doesn't have ZSTs)
2017-04-05Add tracking issue for offset_toAmanieu d'Antras-2/+2
2017-04-04add [T]::rsplit() and rsplit_mut() #41020Jason Orendorff-0/+11
2017-04-03Add ptr::offset_toAmanieu d'Antras-0/+8
2017-04-01rustc: Stabilize the `#![windows_subsystem]` attributeAlex Crichton-11/+0
This commit stabilizes the `#![windows_subsystem]` attribute which is a conservative exposure of the `/SUBSYSTEM` linker flag on Widnows platforms. This is useful for creating applications as well as console programs. Closes #37499
2017-03-31Rollup merge of #40925 - DaseinPhaos:patch-5, r=steveklabnikCorey Farwell-0/+2
Add missing link in unstable-book add link to specialization's tracking issue
2017-03-31Sync all unstable features with Unstable Book; add tidy lint.Corey Farwell-16/+16
Add a tidy lint that checks for... * Unstable Book sections with no corresponding SUMMARY.md links * unstable features that don't have Unstable Book sections * Unstable Book sections that don't have corresponding unstable features
2017-03-30Add missing link in unstable-bookLuxko-0/+2
add link to specialization's tracking issue
2017-03-29Rollup merge of #40901 - MaloJaffre:fix-double-redirect, r=steveklabnikCorey Farwell-1/+1
Avoid linking to a moved page in rust.html
2017-03-29Avoid linking to a moved page in rust.htmlMalo Jaffré-1/+1
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-02 22:03:56 +0000