bors [Mon, 22 Aug 2016 15:29:41 +0000 (08:29 -0700)]
Auto merge of #35871 - bluss:cstring-new, r=alexcrichton
cstring: avoid excessive growth just to 0-terminate
Based on following what happens in CString::new("string literal"):
1. Using `Into<Vec<u8>>`, a Vec is allocated with capacity exactly equal
to the string's input length.
2. By `v.push(0)`, the Vec is grown to twice capacity, since it was full.
3. By `v.into_boxed_slice()`, the Vec capacity is shrunk to fit the length again.
If we use `.reserve_exact(1)` just before the push, then we avoid the
capacity doubling that we're going to have to shrink anyway.
Growing by just 1 byte means that the step (2) is less likely to have to
move the memory to a larger allocation chunk, and that the step (3) does
not have to reallocate.
bors [Mon, 22 Aug 2016 12:39:53 +0000 (05:39 -0700)]
Auto merge of #35848 - Mark-Simulacrum:make-tidy-in-tree, r=alexcrichton
Check that executable file is in-tree before failing tidy check
I silenced stdout and stderr for ls-files, not sure if that's appropriate (is `make tidy` intended to give debugging information)? Otherwise it prints each file it find to stdout/stderr, which currently prints nothing (only executable files are checked).
I have not done major testing regarding the behavior of ls-files when the file is ignored, but judging by the man page everything should be fine.
I've duplicated the code which makes the path git-friendly from the `Cargo.lock` checking code; I can extract that into a common helper if wanted (it's only two lines).
bors [Mon, 22 Aug 2016 05:30:46 +0000 (22:30 -0700)]
Auto merge of #35821 - nbaksalyar:solaris-trans-fix, r=alexcrichton
Fix linker on Solaris/Illumos
This patch provides a fix for the `GnuLinker::export_symbols` function that currently relies on a `--retain-symbols-file` option which is not supported by the Solaris & Illumos linker.
Instead, a [version script](https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html) is used on this platform to achieve the same goal. Here's an example of a similar approach in LLVM's CMake script: https://github.com/llvm-mirror/llvm/blob/master/cmake/modules/AddLLVM.cmake#L88-L94.
Perhaps other platforms like OpenBSD could benefit from this as well. /cc @semarie
bors [Sun, 21 Aug 2016 22:12:43 +0000 (15:12 -0700)]
Auto merge of #35777 - nrc:carrier3, r=@nikomatsakis
Carrier trait (third attempt)
This adds a `Carrier` trait to operate with `?`. The only public implementation is for `Result`, so effectively the trait does not exist, however, it ensures future compatibility for the `?` operator. This is not intended to be used, nor is it intended to be a long-term solution.
Although this exact PR has not been through Crater, I do not expect it to be a breaking change based on putting numerous similar PRs though Crater in the past.
cc:
* [? tracking issue](https://github.com/rust-lang/rust/issues/31436)
* [previous PR](https://github.com/rust-lang/rust/pull/35056)
* [RFC issue](https://github.com/rust-lang/rfcs/issues/1718) for discussion of long-term Carrier trait solutions.
Ulrik Sverdrup [Sun, 21 Aug 2016 11:33:28 +0000 (13:33 +0200)]
cstring: avoid excessive growth just to 0-terminate
Based on following what happens in CString::new("string literal"):
1. Using `Into<Vec<u8>>`, a Vec is allocated with capacity exactly equal
to the string's input length.
2. By `v.push(0)`, the Vec is grown to twice capacity, since it was full.
3. By `v.into_boxed_slice()`, the Vec capacity is shrunk to fit the length again.
If we use `.reserve_exact(1)` just before the push, then we avoid the
capacity doubling that we're going to have to shrink anyway.
Growing by just 1 byte means that the step (2) is less likely to have to
move the memory to a larger allocation chunk, and that the step (3) does
not have to reallocate.
Jonathan Turner [Sat, 20 Aug 2016 14:09:37 +0000 (07:09 -0700)]
Rollup merge of #35839 - jonathandturner:error_touchup, r=Aatch
Wording fixes in error messages
This PR is largely wording fixes to existing PRs that I found going back through the ones that have already been updated. Sometimes seeing the message in context made me think "oh there's a better wording!"
There's one additional fix. This will also prevent the secondary underlining of derive call (since they look like macros to the system in the way I was using):
```
error[E0184]: the trait `Copy` may not be implemented for this type; the type has a destructor
--> src/test/compile-fail/E0184.rs:11:10
|
11 | #[derive(Copy)] //~ ERROR E0184
| ^^^^
| |
| in this macro invocation
```
Is now just:
```
error[E0184]: the trait `Copy` may not be implemented for this type; the type has a destructor
--> src/test/compile-fail/E0184.rs:11:10
|
11 | #[derive(Copy)] //~ ERROR E0184
| ^^^^
```
Jonathan Turner [Sat, 20 Aug 2016 14:09:36 +0000 (07:09 -0700)]
Rollup merge of #35811 - jonathandturner:fix_rustbuild_version_test, r=alexcrichton
Add workaround to detect correct compiler version
This adds a workaround which fixes a rustbuild issue where the wrong compiler is checked for the version number. The bug would arise if you build the system correctly then changed to any other version (eg doing a `git pull`). After changing to the new version, building would fail and complain that crates were built with the wrong compiler.
There are actually two compilers at play, the bootstrapping compiler (called the "snapshot" compiler) and the actual compiler being built (the "real" compiler). In the case of this issue, the wrong compiler was being checked for version mismatch.
Jonathan Turner [Sat, 20 Aug 2016 14:09:34 +0000 (07:09 -0700)]
Rollup merge of #35709 - matthew-piziak:add-trait-example, r=GuillaumeGomez
replace `Add` example with something more evocative of addition
Currently most of the operator traits use trivial implementation
examples that only perform side effects. Honestly, that might not be too
bad for the sake of documentation; but anyway, here's a proposal to move
a slightly modified version of the module-level point-addition example
into the `Add` documentation, since it's more evocative of addition
semantics.
bors [Sat, 20 Aug 2016 01:14:53 +0000 (18:14 -0700)]
Auto merge of #33922 - estebank:doc-comment, r=alexcrichton
Specific error message for missplaced doc comments
Identify when documetation comments have been missplaced in the following places:
* After a struct element:
```rust
// file.rs:
struct X {
a: u8 /** document a */,
}
```
```bash
$ rustc file.rs
file.rs:2:11: 2:28 error: found documentation comment that doesn't
document anything
file.rs:2 a: u8 /** document a */,
^~~~~~~~~~~~~~~~~
file.rs:2:11: 2:28 help: doc comments must come before what they document,
maybe a comment was intended with `//`?
```
```bash
$ rustc file.rs
file.rs:3:5: 3:27 error: found a documentation comment that doesn't
document anything
file.rs:3 /// incorrect documentation
^~~~~~~~~~~~~~~~~~~~~~
file.rs:3:5: 3:27 help: doc comments must come before what they document,
maybe a comment was intended with `//`?
```
* As the last line of a `fn`:
```rust
// file.rs:
fn main() {
let x = 1;
/// incorrect documentation
}
```
```bash
$ rustc file.rs
file.rs:3:5: 3:27 error: found a documentation comment that doesn't
document anything
file.rs:3 /// incorrect documentation
^~~~~~~~~~~~~~~~~~~~~~
file.rs:3:5: 3:27 help: doc comments must come before what they document,
maybe a comment was intended with `//`?
```
bors [Fri, 19 Aug 2016 18:17:11 +0000 (11:17 -0700)]
Auto merge of #35655 - ollie27:rustdoc_search_static_prim, r=steveklabnik
rustdoc: Fix a couple of issues with the search results
* Fix links to static items in the search results.
* Don't include the path for primitive methods in the search results. Displaying `std::u32::max_value` is misleading so just display `u32::max_value`.
bors [Thu, 18 Aug 2016 15:54:10 +0000 (08:54 -0700)]
Auto merge of #35684 - nikomatsakis:incr-comp-metadata-audit-35111, r=mw
Restructure metadata encoder to track deps precisely
This issue restructures meta-data encoding to track dependencies very precisely. It uses a cute technique I hope to spread elsewhere, where we can guard the data flowing into a new dep-graph task and ensure that it is not "leaking" information from the outside, which would result in missing edges. There are no tests because we don't know of any bugs in the old system, but it's clear that there was leaked data.
The commit series is standalone, but the refactorings are kind of "windy". It's a good idea to read the comment in `src/librustc_metadata/index_builder.rs` to get a feeling for the overall strategy I was aiming at.
In several cases, I wound up adding some extra hashtable lookups, I think primarily for looking up `AdtDef` instances. We could remove these by implementing `DepGraphRead` for an `AdtDef` and then having it register a read to the adt-defs table, I guess, but I doubt it is really noticeable.
Eventually I think I'd like to extend this pattern to the dep-graph more generally, since it effectively guarantees that data cannot leak.
bors [Thu, 18 Aug 2016 12:39:11 +0000 (05:39 -0700)]
Auto merge of #35732 - jonathandturner:region_error_labels, r=nikomatsakis
Move 'doesn't live long enough' errors to labels
This patch moves the "doesn't live long enough" region-style errors to instead use labels.
An example follows.
Before:
```
error: `x` does not live long enough
--> src/test/compile-fail/send-is-not-static-ensures-scoping.rs:26:18
|
26 | let y = &x;
| ^
|
note: reference must be valid for the block at 23:10...
--> src/test/compile-fail/send-is-not-static-ensures-scoping.rs:23:11
|
23 | fn main() {
| ^
note: ...but borrowed value is only valid for the block suffix following statement 0 at 25:18
--> src/test/compile-fail/send-is-not-static-ensures-scoping.rs:25:19
|
25 | let x = 1;
| ^
```
After:
```
error: `x` does not live long enough
--> src/test/compile-fail/send-is-not-static-ensures-scoping.rs:26:18
|
26 | let y = &x;
| ^ does not live long enough
...
32 | };
| - borrowed value only valid until here
...
35 | }
| - borrowed value must be valid until here
```
Rollup merge of #35751 - nagisa:mir-scope-fix-again, r=eddyb
Fix the invalidation of the MIR early exit cache
~~The #34307 introduced a cache for early exits in order to help with O(n*m) explosion of cleanup blocks but the cache is invalidated incorrectly and I can’t seem to figure out why (caching is hard!)~~
~~Remove the cache for now to fix the immediate correctness issue and worry about the performance later.~~
Rollup merge of #35734 - japaric:mips-uclibc, r=alexcrichton
add mips-uclibc targets
These targets cover OpenWRT 15.05 devices, which use the soft float ABI
and the uclibc library. None of the other built-in mips targets covered
those devices (mips-gnu is hard float and glibc-based, mips-musl is
musl-based).
With this commit one can now build std for these devices using these
commands:
```
$ configure --enable-rustbuild --target=mips-unknown-linux-uclibc
$ make
```
cc #35673
---
r? @alexcrichton
cc @felixalias This is the target the rust-tessel project should be using.
Note that the libc crate doesn't support the uclibc library and will have to be updated. We are lucky that uclibc and glibc are somewhat similar and one can build std and even run the libc-test test suite with the current, unmodified libc. About that last part, I tried to run the libc-test and got a bunch of compile errors. I don't intend to fix them but I'll post some instruction about how to run libc-test in the rust-lang/libc issue tracker.
bors [Thu, 18 Aug 2016 02:57:22 +0000 (19:57 -0700)]
Auto merge of #35702 - jonathandturner:add_backtrace_labels, r=nikomatsakis
Replace macro backtraces with labeled local uses
This PR (which builds on https://github.com/rust-lang/rust/pull/35688) follows from the conversations on how best to [handle the macro backtraces](https://internals.rust-lang.org/t/improving-macro-errors/3809). The feeling there was that there were two different "groups" of users.
The first group, the macro users, rarely (and likely never) want to see the macro backtrace. This is often more confusing to users as it will be talking about code they didn't write.
The second group, the macro writers, are trying to debug a macro. They'll want to see something of the backtrace so that they can see where it's going wrong and what the steps were to get there.
For the first group, it seems clear that we don't want to show *any* macro backtrace. For the second group, we want to show enough to help the macro writer.
This PR uses a heuristic. It will only show any backtrace steps if they are in the same crate that is being compiled. This keeps errors in foreign crates from showing to users that didn't need them.
Additionally, in asking around I repeated heard that the middle steps of the backtrace are rarely, if ever, used in practice. This PR takes and applies this knowledge. Now, instead of a full backtrace, the user is given the error underline inside of a local macro as well as the use site as a secondary label. This effectively means seeing the root of the error and the top of the backtrace, eliding the middle steps.
Rather than being the "perfect solution", this PR opts to take an incremental step towards a better experience. Likely it would help to have additional macro debugging tools, as they could be much more verbose than we'd likely want to use in the error messages themselves.
Matthew Piziak [Tue, 16 Aug 2016 08:11:48 +0000 (04:11 -0400)]
replace Add example with something more evocative of addition
Currently most of the operator traits use trivial implementation
examples that only perform side effects. Honestly, that might not be too
bad for the sake of documentation; but anyway, here's a proposal to move
a slightly modified version of the module-level point-addition example
into the `Add` documentation, since it's more evocative of addition
semantics.
Part of #29365
wrap identifiers in backticks
minor rephrasing
fix module-level documentation to be more truthful
This branch changes the example for `Add` to no longer be a "minimum implementation that prints something to the screen".
projects / rust.git / log