- 29 4月, 2015 5 次提交
-
-
由 Tamir Duberstein 提交于
-
由 bors 提交于
Implement Vec::drain(\<range type\>) from rust-lang/rfcs#574, tracking issue #23055. This is a big step forward for vector usability. This is an introduction of an API for removing a range of *m* consecutive elements from a vector, as efficently as possible. New features: - Introduce trait `std::collections::range::RangeArgument` implemented by all four built-in range types. - Change `Vec::drain()` to use `Vec::drain<R: RangeArgument>(R)` Implementation notes: - Use @Gankro's idea for memory safety: Use `set_len` on the source vector when creating the iterator, to make sure that the part of the vector that will be modified is unreachable. Fix up things in Drain's destructor — but even if it doesn't run, we don't expose any moved-out-from slots of the vector. - This `.drain<R>(R)` very close to how it is specified in the RFC. - Introduced as unstable - Drain reuses the slice iterator — copying and pasting the same iterator pointer arithmetic again felt very bad - The `usize` index as a range argument in the RFC is not included. The ranges trait would have to change to accomodate it. Please help me with: - Name and location of the new ranges trait. - Design of the ranges trait - Understanding Niko's comments about variance (Note: for a long time I was using a straight up &mut Vec in the iterator, but I changed this to permit reusing the slice iterator). Previous PR and discussion: #23071
-
由 bors 提交于
These commits build on [some great work on reddit](http://www.reddit.com/r/rust/comments/33boew/weekend_experiment_link_rust_programs_against/) for adding MUSL support to the compiler. This goal of this PR is to enable a `--target x86_64-unknown-linux-musl` argument to the compiler to work A-OK. The outcome here is that there are 0 compile-time dependencies for a MUSL-targeting build *except for a linker*. Currently this also assumes that MUSL is being used for statically linked binaries so there is no support for dynamically linked binaries with MUSL. MUSL support largely just entailed munging around with the linker and where libs are located, and the major highlights are: * The entirety of `libc.a` is included in `liblibc.rlib` (statically included as an archive). * The entirety of `libunwind.a` is included in `libstd.rlib` (like with liblibc). * The target specification for MUSL passes a number of ... flavorful options! Each option is documented in the relevant commit. * The entire test suite currently passes with MUSL as a target, except for: * Dynamic linking tests are all ignored as it's not supported with MUSL * Stack overflow detection is not working MUSL yet (I'm not sure why) * There is a language change included in this PR to add a `target_env` `#[cfg]` directive. This is used to conditionally build code for only MUSL (or for linux distros not MUSL). I highly suspect that this will also be used by Windows to target MSVC instead of a MinGW-based toolchain. To build a compiler targeting MUSL you need to follow these steps: 1. Clone the current MUSL repo from `git://git.musl-libc.org/musl`. Build this as usual and install it. 2. Clone and build LLVM's [libcxxabi](http://libcxxabi.llvm.org/) library. Only the `libunwind.a` artifact is needed. I have tried using upstream libunwind's source repo but I have not gotten unwinding to work with it unfortunately. Move `libunwind.a` adjacent to MUSL's `libc.a` 3. Configure a Rust checkout with `--target=x86_64-unknown-linux-musl --musl-root=$MUSL_ROOT` where `MUSL_ROOT` is where you installed MUSL in step 1. I hope to improve building a copy of libunwind as it's still a little sketchy and difficult to do today, but other than that everything should "just work"! This PR is not intended to include 100% comprehensive support for MUSL, as future modifications will probably be necessary.
-
由 bors 提交于
dropck: Remove `Copy` from special-cased traits Fix #24895. [breaking-change] What does this break? Basically, code that implements `Drop` and is using `T:Copy` for one of its type parameters and is relying on the Drop Check rule not applying to it. Here is an example: ```rust #![allow(dead_code,unused_variables,unused_assignments)] struct D<T:Copy>(T); impl<T:Copy> Drop for D<T> { fn drop(&mut self) { } } trait UserT { fn c(&self) { } } impl<T:Copy> UserT for T { } struct E<T:UserT>(T); impl<T:UserT> Drop for E<T> { fn drop(&mut self) { } } // This one will start breaking. fn foo() { let (d2, d1); d1 = D(34); d2 = D(&d1); } #[cfg(this_one_does_and_should_always_break)] fn bar() { let (e2, e1); e1 = E(34); e2 = E(&e1); } fn main() { foo(); } ```
-
由 Alex Crichton 提交于
There were a few test cases to fix: * Dynamic libraries are not supported with MUSL right now, so all of those related test which force or require dylibs are ignored. * Looks like the default stack for MUSL is smaller than glibc, so a few stack allocations in benchmarks were boxed up (shouldn't have a perf impact). * Some small linkage tweaks here and there * Out-of-stack detection does not currently work with MUSL
-
- 28 4月, 2015 22 次提交
-
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
[breaking-change] What does this break? Basically, code that implements `Drop` and is using `T:Copy` for one of its type parameters and is relying on the Drop Check rule not applying to it. Here is an example: ```rust #![allow(dead_code,unused_variables,unused_assignments)] struct D<T:Copy>(T); impl<T:Copy> Drop for D<T> { fn drop(&mut self) { } } trait UserT { fn c(&self) { } } impl<T:Copy> UserT for T { } struct E<T:UserT>(T); impl<T:UserT> Drop for E<T> { fn drop(&mut self) { } } // This one will start breaking. fn foo() { let (d2, d1); d1 = D(34); d2 = D(&d1); } #[cfg(this_one_does_and_should_always_break)] fn bar() { let (e2, e1); e1 = E(34); e2 = E(&e1); } fn main() { foo(); } ```
-
由 bors 提交于
`Type` should be `Trait` to match the next example line. r? @steveklabnik
-
由 Ulrik Sverdrup 提交于
Old `.drain()` on vec is performed using `.drain(..)` now. `.drain(range)` is unstable and under feature(collections_drain) [breaking-change]
-
由 Toni Cárdenas 提交于
`Type` should be `Trait` to match the next example line. r? @steveklabnik
-
由 bors 提交于
This commit gets `make check-stage1` working again after #24718. cc @tamird r? @alexcrichton
-
由 bors 提交于
Inspecting the current thread's info may not always work due to the TLS value having been destroyed (or is actively being destroyed). The code for printing a panic message assumed, however, that it could acquire the thread's name through this method. Instead this commit propagates the `Option` outwards to allow the `std::panicking` module to handle the case where the current thread isn't present. While it solves the immediate issue of #24313, there is still another underlying issue of panicking destructors in thread locals will abort the process. Closes #24313
-
由 Alex Crichton 提交于
Inspecting the current thread's info may not always work due to the TLS value having been destroyed (or is actively being destroyed). The code for printing a panic message assumed, however, that it could acquire the thread's name through this method. Instead this commit propagates the `Option` outwards to allow the `std::panicking` module to handle the case where the current thread isn't present. While it solves the immediate issue of #24313, there is still another underlying issue of panicking destructors in thread locals will abort the process. Closes #24313
-
由 bors 提交于
Instead of using the O(n) defaults, define O(1) shortcuts. I also copied (and slightly modified) the relevant tests from the iter tests into the slice tests just in case someone comes along and changes them in the future. Partially implements #24214.
-
由 Alex Crichton 提交于
Don't need so much manual #[doc(hidden)] and #[unstable] as much of it is inherited!
-
由 bors 提交于
Inspect enum discriminant *after* calling its destructor Includes some drive-by cleanup (e.g. changed some field and method names to reflect fill-on-drop; added comments about zero-variant enums being classified as `_match::Single`). Probably the most invasive change was the expansion of the maps `available_drop_glues` and `drop_glues` to now hold two different kinds of drop glues; there is the (old) normal drop glue, and there is (new) drop-contents glue that jumps straight to dropping the contents of a struct or enum, skipping its destructor. * For all types that do not have user-defined Drop implementations, the normal glue is generated as usual (i.e. recursively dropping the fields of the data structure). (And this actually is exactly what the newly-added drop-contents glue does as well.) * For types that have user-defined Drop implementations, the "normal" drop glue now schedules a cleanup before invoking the `Drop::drop` method that will call the drop-contents glue after that invocation returns. Fix #23611. ---- Is this a breaking change? The prior behavior was totally unsound, and it seems unreasonable that anyone was actually relying on it. Nonetheless, since there is a user-visible change to the language semantics, I guess I will conservatively mark this as a: [breaking-change] (To see an example of what sort of user-visible change this causes, see the comments in the regression test.)
-
由 Ulrik Sverdrup 提交于
RangeArgument is introduced as unstable under the feature(collections_range)
-
由 Alex Crichton 提交于
Add the ability to ignore a test based on the environment of the triple being used.
-
由 Alex Crichton 提交于
Statically linked executables do not succeed (aka MUSL-based executables).
-
由 Alex Crichton 提交于
MUSL support is currently only with static builds, so building a dylib will always fail.
-
由 Alex Crichton 提交于
This commit modifies the standard library and its dependencies to link correctly when built against MUSL. This primarily ensures that the right libraries are linked against and when they're linked against they're linked against statically.
-
由 Alex Crichton 提交于
MUSL for example provides its own start/end objects in place of the standard ones shipped by gcc.
-
由 Alex Crichton 提交于
This commit adds support for x86_64-unknown-linux-musl as a target of the compiler. There's some comments in the commit about some of the more flavorful flags passed to the linker as it's not quite as trivial as the normal specs.
-
由 Alex Crichton 提交于
This commit adds support to the makefiles, configuration script, and build system to understand MUSL. This is broken up into a few parts: * Any target of the form `*-musl` requires the `--musl-root` option to `./configure` which will indicate the root of the MUSL installation. It is also expected that there is a libunwind build inside of that installation built against that MUSL. * Objects from MUSL are copied into the build tree for Rust to be statically linked into the appropriate Rust library. * Objects for binary startup and shutdown are included in each Rust installation by default for MUSL. This requires MUSL to only be installed on the machine compiling rust. Only a linker will be necessary for compiling against MUSL on a target machine. Eventually a MUSL and/or libunwind build may be integrated by default into the build but for now they are just always assumed to exist externally.
-
由 bors 提交于
Closes #17841. The majority of the work should be done, e.g. trait and inherent impls, different forms of UFCS syntax, defaults, and cross-crate usage. It's probably enough to replace the constants in `f32`, `i8`, and so on, or close to good enough. There is still some significant functionality missing from this commit: - ~~Associated consts can't be used in match patterns at all. This is simply because I haven't updated the relevant bits in the parser or `resolve`, but it's *probably* not hard to get working.~~ - Since you can't select an impl for trait-associated consts until partway through type-checking, there are some problems with code that assumes that you can check constants earlier. Associated consts that are not in inherent impls cause ICEs if you try to use them in array sizes or match ranges. For similar reasons, `check_static_recursion` doesn't check them properly, so the stack goes ka-blooey if you use an associated constant that's recursively defined. That's a bit trickier to solve; I'm not entirely sure what the best approach is yet. - Dealing with consts associated with type parameters will raise some new issues (e.g. if you have a `T: Int` type parameter and want to use `<T>::ZERO`). See rust-lang/rfcs#865. - ~~Unused associated consts don't seem to trigger the `dead_code` lint when they should. Probably easy to fix.~~ Also, this is the first time I've been spelunking in rustc to such a large extent, so I've probably done some silly things in a couple of places.
-
由 Alex Crichton 提交于
This adds a new `#[cfg]` matcher against the `target_env` property of the destination target triple. For example all windows triples today end with `-gnu` but we will also hopefully support non-`gnu` targets for Windows, at which point we'll need to differentiate between the two. This new `target_env` matches is provided and filled in with the target's environment name. Currently the only non-empty value of this name is `gnu`, but `musl` will be shortly added for the linux triples.
-
由 Alex Crichton 提交于
-
- 27 4月, 2015 13 次提交
-
-
由 bors 提交于
- Successful merges: #24797, #24804, #24848, #24854, #24855, #24860, #24863, #24866, #24867, #24868 - Failed merges:
-
由 Steve Klabnik 提交于
-
由 Steve Klabnik 提交于
-
由 Steve Klabnik 提交于
-
由 Steve Klabnik 提交于
Remove the name "multi-line string literal" since the rule appears to affect each line-break individually rather than the whole string literal. Re-word, and remove the stray reference to raw strings.
-
由 Steve Klabnik 提交于
A user in IRC was having trouble because they used `main.rs` when they were trying to migrate a library. The `[[lib]]` key is not easily found, and the `main.rs`/`lib.rs` distinction doesn't seem to exist in trpl r? @steveklabnik
-
由 Steve Klabnik 提交于
-
由 Steve Klabnik 提交于
-
由 Steve Klabnik 提交于
Improve example for as_string and add example for as_vec Provide a better example of `as_string` / `DerefString`'s unique capabilities. Use an example where (for an unspecified reason) you need a &String, and show how `as_string` solves the problem without needing an allocation.
-
由 Steve Klabnik 提交于
Fixes #24441 Preview: ![new-trait-color](https://cloud.githubusercontent.com/assets/346530/7331922/d6cbcf72-eb58-11e4-8a1d-4ca5e3683ed2.png)
-
由 Steve Klabnik 提交于
The minus sign ‘−’ is the same width as the plus sign ‘+’, so the button’s transition between the two symbols will look slightly smoother. If you don’t want to use literal Unicode characters, I can change ‘−’ to `\u2212`. I’m not starting with that suggestion because ‘−’ is easier to read and understand, and if I used `\u2212`, it would probably be necessary to also comment the usage on each line to explain what character is being used.
-
由 Felix S. Klock II 提交于
Kudos to dotdash for tracking down this fix. Presumably the use of `ByRef` was because this value is a reference to the drop-flag; but an Lvalue will serve just as well for that. dotdash argues: > since the drop_flag is in its "final home", Lvalue seems to be the > correct choice.
-
由 Tshepang Lekhonkhobe 提交于
-