Ulrik Sverdrup [Fri, 4 Mar 2016 20:01:59 +0000 (21:01 +0100)]
Do not trigger unused_assignments for overloaded AssignOps
If `v` were a type with some kind of indirection, so that `v += 1` would
have an effect even if `v` were not used anymore, the unused_assignments lint
would mark a false positive.
This exempts overloaded (non-primitive) assign ops from being treated as
assignments (they are method calls).
The previous compile-fail tests that ensure x += 1 can trigger for
primitive types continue to pass. Added a representative test for the
"view" indirection.
bors [Fri, 4 Mar 2016 13:47:02 +0000 (13:47 +0000)]
Auto merge of #32022 - gohyda:master, r=alexcrichton
- Empty `.sidebar .location` caused "grey line" on top of the documentation page (under 700px) fixed.
- `.sidebar .location` appearance improvement in responsive mode.
bors [Fri, 4 Mar 2016 06:55:11 +0000 (06:55 +0000)]
Auto merge of #32006 - jseyfried:fix_expanded_mod_path, r=nikomatsakis
This PR changes the search paths for macro-expanded non-inline modules so that they match ordinary non-inline modules (fixes #31624). This is a [breaking-change].
Right now, the search paths for a macro-expanded non-inline module are computed as if the module were declared in the top level of the file in which the macro was defined.
For example, consider `./foo/mod.rs`:
```rust
mod inconsequential { // moving the macro outside this module wouldn't change anything
macro_rules! mod_decl {
($i:ident) => { mod $i; }
}
}
```
and `./lib.rs`:
```rust
mod foo;
mod bar {
mod_decl!(baz);
//^ Now, rustc expects `./foo/baz.rs` (or `./foo/baz/mod.rs`)
//| After this PR, rustc will expect `./bar/baz.rs` (or `./bar/baz/mod.rs`)
}
```
r? @alexcrichton
bors [Thu, 3 Mar 2016 17:41:13 +0000 (17:41 +0000)]
Auto merge of #32007 - nikomatsakis:compiletest-incremental, r=alexcrichton
This PR extends compiletest to support **test revisions** and with a preliminary **incremental testing harness**. run-pass, compile-fail, and run-fail tests may be tagged with
```
// revisions: a b c d
```
This will cause the test to be re-run four times with `--cfg {a,b,c,d}` in turn. This means you can write very closely related things using `cfg`. You can also configure the headers/expected-errors by writing `//[foo] header: value` or `//[foo]~ ERROR bar`, where `foo` is the name of your revision. See the changes to `coherence-cow.rs` as a proof of concept.
The main point of this work is to support the incremental testing harness. This PR contains an initial, unused version. The code that uses it will land later. The incremental testing harness compiles each revision in turn, and requires that the revisions have particular names (e.g., `rpass2`, `cfail3`), which tell it whether a particular revision is expected to compile or not.
Two questions:
- Is there compiletest documentation anywhere I can update?
- Should I hold off on landing the incremental testing harness until I have the code to exercise it? (That will come in a separate PR, still fixing a few details)
r? @alexcrichton
cc @rust-lang/compiler <-- new testing capabilities
Andrea Canciani [Thu, 3 Mar 2016 09:06:09 +0000 (10:06 +0100)]
Hide gated cfg attributes from the output of `--print cfg`
Gated cfg attributes are not available on the stable and beta release
channels, therefore they should not be presented to users of those
channels in order to avoid confusion.
bors [Thu, 3 Mar 2016 08:35:51 +0000 (08:35 +0000)]
Auto merge of #32012 - bluss:more-drop-in-place, r=alexcrichton
Use `drop_in_place` in Vec and VecDeque
We can use drop_in_place's DST capabilities directly in Vec::drop and similarly in VecDeque::drop. I verfied this has the same effect as the previous `needs_drop` code; `drop_in_place` it itself an intrinsic.
The VecDeque replacement should be more efficient too, even in release mode (slice iteration makes a more efficient loop than the deque iterator).
bors [Thu, 3 Mar 2016 02:21:28 +0000 (02:21 +0000)]
Auto merge of #31824 - jseyfried:privacy_in_resolve, r=nikomatsakis
This PR privacy checks paths as they are resolved instead of in `librustc_privacy` (fixes #12334 and fixes #31779). This removes the need for the `LastPrivate` system introduced in PR #9735, the limitations of which cause #31779.
This PR also reports privacy violations in paths to intra- and inter-crate items the same way -- it always reports the first inaccessible segment of the path.
Since it fixes #31779, this is a [breaking-change]. For example, the following code would break:
```rust
mod foo {
pub use foo::bar::S;
mod bar { // `bar` should be private to `foo`
pub struct S;
}
}
impl foo::S {
fn f() {}
}
fn main() {
foo::bar::S::f(); // This is now a privacy error
}
```
Andrea Canciani [Wed, 2 Mar 2016 21:07:03 +0000 (22:07 +0100)]
Build the same configuration when compiling and for `--print cfg`
The configuration returned by `config::build_configuration` needs to
be modified with `target_features::add_configuration` in order to also
contain the target features. This is already done for the
configuration used when compiling and when creating the documentation,
but was missing in the `cfg` printing code.
Ulrik Sverdrup [Wed, 2 Mar 2016 16:54:43 +0000 (17:54 +0100)]
Use ptr::drop_in_place in VecDeque::drop
Just like for Vec. This should benefit both non-optimized and optimized
performance. Non-optimized since the intrinsic drop_in_place is easily
removed, and optimized because iterating the slices is more efficient
than using the VecDeque iterators.
bors [Wed, 2 Mar 2016 14:35:33 +0000 (14:35 +0000)]
Auto merge of #32000 - xaocon:master, r=steveklabnik
Vectors come up in sections dedicated to ownership with the assumption that we know something about it but we haven't seen it yet. On the other hand, you need not know anything about ownership or lifetimes to understand the basics of vectors covered in the vector section of the book. Additionally, by moving it where it is there is a natural progression from loops to an iterative type which discusses for loops. This kind of interaction is generally better for learning.
I would like to have moved the struct section as well but I'm less confident about how to handle it since the ownership sections discuss structs and the structs section talks about mutable borrow.
Rollup merge of #31985 - ashleysommer:libbackgrace_emscripten_fix, r=alexcrichton
Was getting error:
```
running: "sh" "/home/flubba86/rust/src/libstd/../libbacktrace/configure" "--with-pic" "--disable-multilib" "--disable-shared" "--disable-host-shared" "--host=asmjs-unknown-emscripten" "--build=x86_64-unknown-linux-gnu"
...
Invalid configuration `asmjs-unknown-emscripten': system `emscripten' not recognized
```
This commit adds the emscripten target to the libbacktrace configure script so it is no longer unrecognized.
Rollup merge of #31982 - apasel422:sync, r=alexcrichton
These types were already `!Sync`, but this improves error messages when they are used in contexts that require `Sync`, aligning them with conventions used with `Rc`, among others.
Evan [Wed, 2 Mar 2016 00:50:11 +0000 (19:50 -0500)]
Make book ordering more natural
Vectors come up in sections dedicated to ownership with the assumption that we know something about it but we haven't seen it yet. On the other hand, you need not know anything about ownership or lifetimes to understand the basics of vectors covered in the vector section of the book. Additionally, by moving it where it is there is a natural progression from loops to an iterative type which discusses for loops. This kind of interaction is generally better for learning.
I would like to have moved the struct section as well but I'm less confident about how to handle it since the ownership sections discuss structs and the structs section talks about mutable borrow.
Explicitly opt out of `Sync` for `cell` and `mpsc` types
These types were already `!Sync`, but this improves error messages when
they are used in contexts that require `Sync`, aligning them with
conventions used with `Rc`, among others.
Steve Klabnik [Tue, 1 Mar 2016 18:39:42 +0000 (13:39 -0500)]
Rollup merge of #31984 - xaocon:master, r=steveklabnik
Had a discussion at https://www.reddit.com/r/rust/comments/488mjv/borrowing_or_returning_ownership/ about how an example could be worded more clearly and tried to take my recommendation and expand upon it with further information provided in the post.
Steve Klabnik [Tue, 1 Mar 2016 18:39:41 +0000 (13:39 -0500)]
Rollup merge of #31965 - miqid:doc, r=steveklabnik
Hello.
Quite a few of the links in the `core` module concerning redirection to additional primitive type documentation are broken. I noticed in #30214 that there seemed to be a consensus with linking across to `std` module documentation from the `core` module. This is what I've done with the `core` modules for primitive types.
If the changes here are good to go forward with, I'll happily tend to adding more documentation links for the extension traits in the aforementioned issue if need be.
bors [Tue, 1 Mar 2016 14:46:04 +0000 (14:46 +0000)]
Auto merge of #31939 - killercup:patch-17, r=brson
Use unordered nested list for stabilised APIs to improve readability. This makes the release notes for 1.7 a bit longer, but I don't think we should optimise for brevity here. It's a bit inconsistent since the other releases are not done this way, so feel free to ignore this change.
Also:
- Add link to `u32::checked_neg`
- Remove trailing back tick from BTreeMap line
bors [Tue, 1 Mar 2016 07:43:52 +0000 (07:43 +0000)]
Auto merge of #31335 - SimonSapin:ascii-into, r=alexcrichton
The default implementations (with `where Self: Sized`) are so that methods that take `self` by value can exist in a trait that’s implemented for dynamically-sized types (`str` and `[u8]`).
CC https://github.com/rust-lang/rust/issues/27809#issuecomment-177564950
CC @alexcrichton
bors [Tue, 1 Mar 2016 04:44:56 +0000 (04:44 +0000)]
Auto merge of #31713 - alexcrichton:rustbuild-docs, r=brson
This commit implements documentation generation of the nomicon, the book, the
style guide, and the standalone docs. New steps were added for each one as well
as appropriate makefile targets for each one as well.
Evan [Tue, 1 Mar 2016 04:22:30 +0000 (23:22 -0500)]
Clarified the details of a borrowing example.
Had a discussion at https://www.reddit.com/r/rust/comments/488mjv/borrowing_or_returning_ownership/ about how an example could be worded more clearly and tried to take my recommendation and expand upon it with further information provided in the post.
bors [Mon, 29 Feb 2016 22:30:44 +0000 (22:30 +0000)]
Auto merge of #31884 - alexcrichton:no-bootstrap-from-existing, r=brson
These commits add support to the rustbuild build system to compile non-build-system compilers. For example this will allow creating an ARM compiler on a x86 system. The high level way this works is:
* The only compiler ever run is the build target compiler. No other compiler is assumed to be runnable.
* As a result, all output artifacts come from the build compiler.
* The libs for the stageN cross-compiled compiler will be linked into place after the build target builds them.
This will break the assumption that a compiler never links to anything it didn't itself produce, but it retains the assumption that a compiler only ever links to anything built in the same stage. I believe this means that the stage1 cross-compiled compilers will still be usable.
I tested this by creating an `arm-unknown-linux-gnueabihf` compiler. So far the linking ended up all working OK (including LLVM being cross compiled), but I haven't been able to run it yet (in QEMU for a raspberry pi). I think that's because my system linker is messed up or something like that (some newer option is assumed when it's not actually there).
Overall, though, this means that rustbuild can compile an arm-unknown-linux-gnueabihf compiler. Ideally we could even start shipping nightlies based on this at some point!
Alex Crichton [Mon, 29 Feb 2016 17:34:13 +0000 (09:34 -0800)]
test: Mark all rpass-valgrind as no-prefer-dynamic
This applies the same fix as added in 595d5b2f which is to just compile all
valgrind tests statically instead of dynamically. It looks like this is a
resurgence of either #30383 or #31328 in some weird fashion.
I'm not actually sure what's going on with the bots, and it's unclear whether
this is a valgrind bug or a libstd bug, but for now let's just get things
landing again.