Rollup merge of #27521 - steveklabnik:doc_std_mem_forget, r=gankro
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.
Rollup merge of #27519 - JanLikar:rearrange-patterns, r=steveklabnik
- 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 [Wed, 5 Aug 2015 05:37:47 +0000 (05:37 +0000)]
Auto merge of #27520 - brson:bump, r=alexcrichton
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 [Wed, 5 Aug 2015 03:52:39 +0000 (03:52 +0000)]
Auto merge of #27439 - vberger:more_perseverant_resolve, r=nrc
(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?
bors [Wed, 5 Aug 2015 02:00:46 +0000 (02:00 +0000)]
Auto merge of #27393 - alexcrichton:no-std-changes, r=brson
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.
bors [Tue, 4 Aug 2015 22:55:31 +0000 (22:55 +0000)]
Auto merge of #27351 - pnkfelix:dst-size-and-align-issue-27023, r=nikomatsakis
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*
bors [Tue, 4 Aug 2015 21:15:54 +0000 (21:15 +0000)]
Auto merge of #26470 - l0kod:process-session-leader, r=alexcrichton
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.
Alex Crichton [Thu, 30 Jul 2015 15:53:22 +0000 (08:53 -0700)]
syntax: Don't assume `std` exists for tests
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 [Tue, 4 Aug 2015 19:57:54 +0000 (15:57 -0400)]
Improve docs for mem::forget()
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.
bors [Tue, 4 Aug 2015 19:37:50 +0000 (19:37 +0000)]
Auto merge of #27515 - Eljay:rustdoc-search, r=alexcrichton
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 [Tue, 4 Aug 2015 18:22:42 +0000 (20:22 +0200)]
Rearrange sections in "Patterns"
- 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.
Rollup merge of #27397 - Dangthrimble:master, r=steveklabnik
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 [Tue, 4 Aug 2015 03:51:32 +0000 (03:51 +0000)]
Auto merge of #27500 - michaelwoerister:bring-gdb-pp-tests-back, r=alexcrichton
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 `:)`
Alex Crichton [Thu, 30 Jul 2015 00:01:14 +0000 (17:01 -0700)]
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.
bors [Mon, 3 Aug 2015 23:47:02 +0000 (23:47 +0000)]
Auto merge of #26783 - eddyb:methrec, r=huonw
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
bors [Mon, 3 Aug 2015 20:29:21 +0000 (20:29 +0000)]
Auto merge of #27134 - fhartwig:derive, r=huonw
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.
The only outright goofiness I couldn't bear to remove is "these modules are the bedrock upon which all of Rust is forged, and they have mighty names like `std::slice` and `std::cmp`", which I believe the greatest sentence I have ever created.
Vadim Chugunov [Sat, 1 Aug 2015 23:07:38 +0000 (16:07 -0700)]
When a `nounwind` function has a personality routine, LLVM messes up .seh directives (happens to `rust_try` in optimized builds). A workaround is to give `rust_try` the `uwtable` attribute.
Also, make sure that the dummy "load from null" instruction inserted by init_function() gets cleaned up.
bors [Sun, 2 Aug 2015 02:42:24 +0000 (02:42 +0000)]
Auto merge of #27205 - Gankro:travis-extreme, r=alexcrichton
Only `make -j4` takes ~50 mins
`make check` bumps it up to ~1hr 30min
Travis seems more than happy to let this happen.
Time limits appear to be meaningless.
Similar to the previous PR, it's easy to tell how much your PR definitely builds by checking the current logs or just considering how long it's been building for.
Rollup merge of #26982 - nham:orphan-explanations, r=Gankro
part of #24407
I'm not sure whether I should be trying to explain the general rule in the E0210 explanation or just point people to the RFC. However, if we go with the latter option I think that the RFC will need to be revised slightly, since it is not quite as gentle as I would like.
Also, the link to RFC 1023 is not the correct one (it should be https://github.com/rust-lang/rfcs/blob/master/text/1023-rebalancing-coherence.md), but the correct one is too long. I'm aware of @michaelsproul's PR https://github.com/rust-lang/rust/pull/26290 from awhile back, but it doesn't seem to be working. Has there not been a new snapshot yet?
bors [Sat, 1 Aug 2015 03:14:38 +0000 (03:14 +0000)]
Auto merge of #27441 - dhuseby:adding_freebsd32_snap, r=brson
@alexcrichton please upload the FreeBSD 32-bit snapshot file when landing this patch:
https://github.com/dhuseby/rust-manual-snapshots/raw/master/rust-stage0-2015-07-26-a5c12f4-freebsd-i386-2fee22adec101e2f952a5548fd1437ce1bd8d26f.tar.bz2
Auto merge of #27424 - jashank:patch-1, r=alexcrichton
#27360 removed a padding field full of uint8_t's, but didn't remove
the use. This didn't get picked up presumably because (a) bors
doesn't have any BSD builders, and/or (b) #[cfg]'d out blocks don't
get linted.
```
rustc: x86_64-unknown-freebsd/stage1/lib/rustlib/x86_64-unknown-freebsd/lib/liblibc
src/liblibc/lib.rs:1099:42: 1099:49 error: unused import, #[deny(unused_imports)] on by default
src/liblibc/lib.rs:1099 use types::common::c99::{uint8_t, uint32_t, int32_t};
^~~~~~~
error: aborting due to previous error
fatal runtime error: Could not unwind stack, error = 159555904
```
Auto merge of #27418 - taliesinb:tarpl-typo, r=alexcrichton
this makes the second code block consistent with the first code block -- other than being in reversed order, the first code block claims b is u16 and c is u32, whereas the second code block claims the opposite. seems to be an obvious typo.
Victor Berger [Fri, 31 Jul 2015 16:58:59 +0000 (18:58 +0200)]
More perseverant about indeterminate imports.
Most errors generated by resolve might be caused by
not-yet-resolved glob imports. This changes the behavior of the
resolve imports algorithms to not fail prematurally on first
error, but instead buffer intermediate errors and report them
only when stuck.
Jashank Jeremy [Fri, 31 Jul 2015 08:11:10 +0000 (18:11 +1000)]
Fix #27360's unused import
#27360 removed a padding field full of uint8_t's, but didn't remove
the use. This didn't get picked up presumably because (a) bors
doesn't have any BSD builders, and/or (b) #[cfg]'d out blocks don't
get linted.
```
rustc: x86_64-unknown-freebsd/stage1/lib/rustlib/x86_64-unknown-freebsd/lib/liblibc
src/liblibc/lib.rs:1099:42: 1099:49 error: unused import, #[deny(unused_imports)] on by default
src/liblibc/lib.rs:1099 use types::common::c99::{uint8_t, uint32_t, int32_t};
^~~~~~~
error: aborting due to previous error
fatal runtime error: Could not unwind stack, error = 159555904
```
projects / rust.git / log