- 05 8月, 2015 17 次提交
-
-
由 Manish Goregaokar 提交于
Just some grammar fixes and an assumed missing word. r? @Gankro
-
由 Manish Goregaokar 提交于
I thought this was actually a huge error and I'd have to rewrite a bunch but it looks like everything else was correct. Closes #27457 r? @aturon
-
由 Manish Goregaokar 提交于
We were burying the reason to use this function below a bunch of caveats about its usage. That's backwards. Why a function should be used belongs at the top of the docs, not the bottom. Also, add some extra links to related functions mentioned in the body. /cc @abhijeetbhagat who pointed this out on IRC
-
由 Manish Goregaokar 提交于
- Move "Destructuring" after "Multiple patterns", because some of later sections include examples which make use of destructuring. - Move "Ignoring bindings" after "Destructoring", because the former features Result<T,E> destructuring. Some of examples in later sections use "_" and "..", so "Ignoring bindings" must be positioned before them. - Fix #27347 by moving "Ref and mut ref" before "Ranges" and "Bindings", because "Bindings" section includes a somewhat difficult example, which also makes use of "ref" and "mut ref" operators.
-
由 bors 提交于
This probably wants to go in tomorrow. If it lands today then there will be one day where nightly is on 1.4 and stable is still on 1.1. Not a big deal either way.
-
由 bors 提交于
(This is a second try at #26242. This time I think things should be ok.) The current algorithm handling import resolutions works sequentially, handling imports in the order they appear in the source file, and blocking/bailing on the first one generating an error/being unresolved. This can lead to situations where the order of the `use` statements can make the difference between "this code compiles" and "this code fails on an unresolved import" (see #18083 for example). This is especially true when considering glob imports. This PR changes the behaviour of the algorithm to instead try to resolve all imports in a module. If one fails, it is recorded and the next one is tried (instead of directly giving up). Also, all errors generated are stored (and not reported directly). The main loop of the algorithms guaranties that the algorithm will always finish: if a round of resolution does not resolve anything new, we are stuck and give up. At this point, the new version of the algorithm will display all errors generated by the last round of resolve. This way we are sure to not silence relevant errors or help messages, but also to not give up too early. **As a consequence, the import resolution becomes independent of the order in which the `use` statements are written in the source files.** I personally don't see any situations where this could be a problem, but this might need some thought. I passed `rpass` and `cfail` tests on my computer, and now am compiling a full stage2 compiler to ensure the crates reporting errors in my previous attempts still build correctly. I guess once I have checked it, this will need a crater run? Fixes #18083. r? @alexcrichton , cc @nrc @brson
-
由 bors 提交于
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 Closes #27394
-
由 Ivan Jager 提交于
-
由 bors 提交于
Change the behavior of the glue code emitted for `size_and_align_of_dst`. This thus changes the behavior of `std::mem::size_of_val` and `std::mem::align_of_val`. It tries to move us towards a world where the following property holds: Given type `T` implements `Trait` and a value `b: Box<T>`, where `std::mem::size_of::<T>()` returns `k`, then: * `std::mem::size_of_val(b)` returns `k` * `std::mem::size_of_val(b as Box<Trait>)` returns `k` Note that one might legitimately question whether the above property *should* hold. The property certainly does not hold today, as illustrated by #27023. (A follow-up task is to make various tests that check that the above property holds for a wide variety of types ... I chose not to invest effort in writing such a test before we actually determine that the above property is desirable.) nmatsakis and pnkfelix agree that this PR does not require an RFC. cc @rust-lang/lang (since others may disagree). (It also *might* break code, though it is hard for me to imagine that it could break code that wasn't already going to assert-fail when run in e.g. debug builds...) Fix issue #27023 Also, this (or something like it) is a prerequisite for *fixing`make check` on `--enable-optimize --enable-debug` builds*
-
由 Alexis Beingessner 提交于
I thought this was actually a huge error and I'd have to rewrite a bunch but it looks like everything else was correct. Closes #27457
-
由 bors 提交于
Add a new method `CommandExt::session_leader(&mut self, on: bool)` to create a new session (cf. `setsid(2)`) for the child process. This means that the child is the leader of a new process group. The parent process remains the child reaper of the new process. This is not enough to create a daemon process. The *init* process should be the child reaper of a daemon. This can be achieved if the parent process exit. Moreover, a daemon should not have a controlling terminal. To acheive this, a session leader (the child) must spawn another process (the daemon) in the same session. cc rust-lang/rfcs#941 cc #17176
-
由 Alex Crichton 提交于
This commit removes the injection of `std::env::args()` from `--test` expanded code, relying on the test runner itself to call this funciton. This is more hygienic because we can't assume that `std` exists at the top layer all the time, and it meaks the injected test module entirely self contained.
-
由 Steve Klabnik 提交于
We were burying the reason to use this function below a bunch of caveats about its usage. That's backwards. Why a function should be used belongs at the top of the docs, not the bottom. Also, add some extra links to related functions mentioned in the body.
-
由 Brian Anderson 提交于
-
由 bors 提交于
Some small changes to (hopefully) make search more useful: * Less strict filtering, e.g: * searching for "fn: foo" now matches methods and trait functions as well. * searching for types also matches primitive types. * searching for const will also match associated constants (but there aren't any in std yet) * Changed searching for types to use the actual keyword "type" instead of the strange C-like "typedef". * Added const and macro to allowed keywords.
-
由 Jan Likar 提交于
- Move "Destructuring" after "Multiple patterns", because some of later sections include examples which make use of destructuring. - Move "Ignoring bindings" after "Destructoring", because the former features Result<T,E> destructuring. Some of examples in later sections use "_" and "..", so "Ignoring bindings" must be positioned before them. - Fix #27347 by moving "Ref and mut ref" before "Ranges" and "Bindings", because "Bindings" section includes a somewhat difficult example, which also makes use of "ref" and "mut ref" operators.
-
由 bors 提交于
For #27501 r? @steveklabnik
-
- 04 8月, 2015 23 次提交
-
-
由 Eljay 提交于
-
由 bors 提交于
- Successful merges: #27397, #27398, #27460, #27470, #27491, #27498, #27502 - Failed merges:
-
由 Manish Goregaokar 提交于
this grammar isn't correct this should also get backported to beta /cc @brson
-
由 Manish Goregaokar 提交于
r? @Gankro
-
由 Manish Goregaokar 提交于
-
-
由 Manish Goregaokar 提交于
- Fix #26968 by noting the difference between ".." and "_" more explicitly - Change one of the examples to show the match-all behaviour of ".." - Merge "Ignoring variants" and "Ignoring bindings" sections into the latter r? @steveklabnik
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
Clarifications for those new to Rust and Cargo: * It's a good idea to get rid of the original `main.exe` in project root * Slight clarification on the use of `main.rs` vs `lib.rs` * Clarify that the TOML file needs to be in project root
-
由 bors 提交于
Fixes #27467.
-
由 bors 提交于
Closes #27412 r? @brson
-
由 Victor Berger 提交于
-
由 bors 提交于
This test case has been removed a while ago because it allegedly was broken. But I don't think it is (at least I couldn't reproduce any failure on Linux). Let's give it another chance `:)`
-
由 Matt Friedman 提交于
-
由 Eli Friedman 提交于
Fixes #27467.
-
由 Alex Crichton 提交于
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
-
由 bors 提交于
After #26694, the overloaded operator and "impl not known at method lookup time" cases started triggering the lint. I've also added checks for overloaded autoderef and method calls via paths (i.e. `T::method()`). All new 8 test cases did not trigger the lint before #26694. r? @huonw
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 bors 提交于
After this change, the only remaining symbol we are pulling from libgcc on Win64 is `__chkstk_ms` - the stack probing routine.
-
由 Jonathan Hansford 提交于
-
由 bors 提交于
Fixes #25022 This adapts the deriving mechanism to not repeat bounds for the same type parameter. To give an example: for the following code: ```rust #[derive(Clone)] pub struct FlatMap<I, U: IntoIterator, F> { iter: I, f: F, frontiter: Option<U::IntoIter>, backiter: Option<U::IntoIter>, } ``` the latest nightly generates the following impl signature: ```rust impl <I: ::std::clone::Clone, U: ::std::clone::Clone + IntoIterator, F: ::std::clone::Clone> ::std::clone::Clone for FlatMap<I, U, F> where I: ::std::clone::Clone, F: ::std::clone::Clone, U::IntoIter: ::std::clone::Clone, U::IntoIter: ::std::clone::Clone ``` With these changes, the signature changes to this: ```rust impl <I, U: IntoIterator, F> ::std::clone::Clone for FlatMap<I, U, F> where I: ::std::clone::Clone, F: ::std::clone::Clone, U::IntoIter: ::std::clone::Clone ``` (Nothing in the body of the impl changes) Note that the second impl is more permissive, as it doesn't have a `Clone` bound on `U` at all. There was a compile-fail test that failed due to this. I don't understand why we would want the old behaviour (and nobody on IRC could tell me either), so please tell me if there is a good reason that I missed.
-
由 Steve Klabnik 提交于
this grammar isn't correct
-