Rollup of 3 pull requests #41276
Closed
Rollup of 3 pull requests #41276
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
frewsxcv
commented
Apr 13, 2017
frewsxcv
commented
- Successful merges: Updating docs for std::sync::Weak #29377 #41240, Fix invalid 128-bit division on 32-bit target (#41228) #41250, Updating docs for std::rc::Rc #41266
- Failed merges: [beta] Update compiler-rt to fix SPARC LLVM bug 11663. #41274
std::thread docs: fix link to current()
…BurntSushi Fixed typo in doc comments for swap_remove While reading the Vec docs, I came across the docs for swap_remove. I believe there is a typo in the comment and ```return``` should be ```returns```. This PR fixes this issue. I also feel that the entire doc comment is a bit of a run-on and could be changed to something along the lines of ```Removes an element from anywhere in the vector and returns it. The vector is mutated and the removed element is replaced by the last element of the vector. ``` Thoughts?
…aturon Revert "Implement AsRawFd/IntoRawFd for RawFd" This reverts commit 2cf686f (rust-lang#40842) RawFd is a type alias for c_int, which is itself a type alias for i32. As a result, adding AsRawFd and IntoRawFd impls for RawFd actually adds them for i32. As a result, the reverted commit makes this valid: ``` use std::os::unix::io::AsRawFd; fn arf<T: AsRawFd>(_: T) {} fn main() { arf(32i32) } ``` Implimenting AsRawFd and IntoRawFd for i32 breaks the promises of both those traits that their methods return a valid RawFd. r? @aturon cc @Mic92 @kamalmarhubi
…labnik Replace ^ with <sup> html balise r? @steveklabnik
…, r=frewsxcv Handle ordered lists as well Part of rust-lang#40912. r? @rust-lang/docs
Do not recommend private fields called as method ```rust error: no method named `dog_age` found for type `animal::Dog` in the current scope --> $DIR/private-field.rs:26:23 | 26 | let dog_age = dog.dog_age(); | ^^^^^^^ private field, not a method ``` Fix rust-lang#27654.
Fix links part of rust-lang#40912 []\n() is not actually a link. r? @frewsxcv @GuillaumeGomez
…sxcv travis: Update sccache binaries I've tracked down what I believe is the last spurious sccache failure on rust-lang#40240 to behavior in mio (tokio-rs/mio#583), and this commit updates the binaries to a version which has that fix incorporated.
…ichton Properly adjust filenames when multiple emissions Fixes rust-lang#40993 Should backport just fine to beta but not sure if we want to do this since this is quite old stable regression.
Rollup of 19 pull requests - Successful merges: rust-lang#40608, rust-lang#40870, rust-lang#40949, rust-lang#40977, rust-lang#40981, rust-lang#40988, rust-lang#40992, rust-lang#40997, rust-lang#40999, rust-lang#41007, rust-lang#41014, rust-lang#41019, rust-lang#41035, rust-lang#41043, rust-lang#41049, rust-lang#41062, rust-lang#41066, rust-lang#41076, rust-lang#41085 - Failed merges:
Fix diagnostic suggestion from: ```rust help: try parenthesizing the first index | (1, (2, 3)).((1, (2, 3)).1).1; ``` to the correct: ```rust help: try parenthesizing the first index | ((1, (2, 3)).1).1; ```
This is a random stab towards rust-lang#38618, no idea if it'll work. But hey more up-to-date software is better, right?
similar to GCC's __attribute((used))__. This attribute prevents LLVM from
optimizing away a non-exported symbol, within a compilation unit (object file),
when there are no references to it.
This is better explained with an example:
```
#[used]
static LIVE: i32 = 0;
static REFERENCED: i32 = 0;
static DEAD: i32 = 0;
fn internal() {}
pub fn exported() -> &'static i32 {
&REFERENCED
}
```
Without optimizations, LLVM pretty much preserves all the static variables and
functions within the compilation unit.
```
$ rustc --crate-type=lib --emit=obj symbols.rs && nm -C symbols.o
0000000000000000 t drop::h1be0f8f27a2ba94a
0000000000000000 r symbols::REFERENCED::hb3bdfd46050bc84c
0000000000000000 r symbols::DEAD::hc2ea8f9bd06f380b
0000000000000000 r symbols::LIVE::h0970cf9889edb56e
0000000000000000 T symbols::exported::h6f096c2b1fc292b2
0000000000000000 t symbols::internal::h0ac1aadbc1e3a494
```
With optimizations, LLVM will drop dead code. Here `internal` is dropped because
it's not a exported function/symbol (i.e. not `pub`lic). `DEAD` is dropped for
the same reason. `REFERENCED` is preserved, even though it's not exported,
because it's referenced by the `exported` function. Finally, `LIVE` survives
because of the `#[used]` attribute even though it's not exported or referenced.
```
$ rustc --crate-type=lib -C opt-level=3 --emit=obj symbols.rs && nm -C symbols.o
0000000000000000 r symbols::REFERENCED::hb3bdfd46050bc84c
0000000000000000 r symbols::LIVE::h0970cf9889edb56e
0000000000000000 T symbols::exported::h6f096c2b1fc292b2
```
Note that the linker knows nothing about `#[used]` and will drop `LIVE`
because no other object references to it.
```
$ echo 'fn main() {}' >> symbols.rs
$ rustc symbols.rs && nm -C symbols | grep LIVE
```
At this time, `#[used]` only works on `static` variables.
This is a second (2/3?) step in order to complete this issue: rust-lang#29370 I submitted this PR with the help of @steveklabnik again. Thanks to him! More info here: rust-lang#29370 (comment)
Handle extern functions and statics in save-analysis r? @eddyb
Fixes other targets rustlibs installation When the user select more than one target to generate rustlibs for, rustbuild will only install the host one. This patch fixes it, more info in rust-lang#39235 (comment)
Simplify HashMap Bucket interface > Simplify HashMap Bucket interface > > * Store capacity_mask instead of capacity > * Move bucket index into RawBucket > * Valid bucket index is now always within [0..table_capacity) > * Simplify iterators by moving logic into RawBuckets > * Clone RawTable using RawBucket > * Make retain aware of the number of elements The idea was to put idx in RawBucket instead of the other Bucket types and simplify next() and prev() as much as possible. The rest was a side-effect of that change, except maybe the last 2. This change makes iteration and other next/prev() heavy operations noticeably faster. Clone is way faster. ``` ➜ hashmap2 git:(adapt) ✗ cargo benchcmp pre:: adp:: bench.txt name pre:: ns/iter adp:: ns/iter diff ns/iter diff % clone_10_000 74,364 39,736 -34,628 -46.57% grow_100_000 8,343,553 8,233,785 -109,768 -1.32% grow_10_000 817,825 723,958 -93,867 -11.48% grow_big_value_100_000 18,418,979 17,906,186 -512,793 -2.78% grow_big_value_10_000 1,219,242 1,103,334 -115,908 -9.51% insert_1000 74,546 58,343 -16,203 -21.74% insert_100_000 6,743,770 6,238,017 -505,753 -7.50% insert_10_000 798,079 719,123 -78,956 -9.89% insert_1_000_000 275,215,605 266,975,875 -8,239,730 -2.99% insert_int_bigvalue_10_000 1,517,387 1,419,838 -97,549 -6.43% insert_str_10_000 316,179 278,896 -37,283 -11.79% insert_string_10_000 770,927 747,449 -23,478 -3.05% iter_keys_100_000 386,099 333,104 -52,995 -13.73% iterate_100_000 387,320 355,707 -31,613 -8.16% lookup_100_000 206,757 193,063 -13,694 -6.62% lookup_100_000_unif 219,366 193,180 -26,186 -11.94% lookup_1_000_000 206,456 205,716 -740 -0.36% lookup_1_000_000_unif 659,934 629,659 -30,275 -4.59% lru_sim 20,194,334 18,442,149 -1,752,185 -8.68% merge_shuffle 1,168,044 1,063,055 -104,989 -8.99% ``` Note 2: I may have messed up porting the diff, let's see what CI says.
…r, r=alexcrichton Reduce a table used for `Debug` impl of `str`. This commit shrinks the size of the aforementioned table from 2,102 bytes to 1,197 bytes. This is achieved by an observation that most `u16` entries are common in its upper byte. Specifically: - `SINGLETONS` now uses two tables, one for (upper byte, lower count) and another for a series of lower bytes. For each upper byte given number of lower bytes are read and compared. - `NORMAL` now uses a variable length format for the count of "true" codepoints and "false" codepoints (one byte with MSB unset, or two big-endian bytes with the first MSB set). The code size and relative performance roughly remains same as this commit tries to optimize for both. The new table and algorithm has been verified for the equivalence to older ones. In my x86-64 macOS laptop with `rustc 1.17.0-nightly (0aeb9c1 2017-03-15)`, `-C opt-level=3 -C lto` gives the following: * The old routine compiles to 2,102 bytes of data and 416 bytes of code. * The new routine compiles to 1,197 bytes of data and 448 bytes of code. Counting a number of all printable Unicode scalar values (128,003, if you wonder) by filtering `0..0x110000` with `std::char::from_u32` and `is_printable` took 50±7ms for both. This can be surprising as the new routine *has* to do more calculations; this is partly explained by the fact that a linear search of `SINGLETONS` has been replaced by *two* linear searches for upper and lower bytes, which greatly reduces the iteration count.
Identify missing item category in `impl`s
```rust
struct S;
impl S {
pub hello_method(&self) {
println!("Hello");
}
}
fn main() { S.hello_method(); }
```
```rust
error: missing `fn` for method declaration
--> file.rs:3:4
|
3 | pub hello_method(&self) {
| ^ missing `fn`
```
Fix rust-lang#40006. r? @pnkfelix CC @jonathandturner @GuillaumeGomez
…chton Allow using Vec::<T>::place_back for T: !Clone The place_back was likely put into block with `T: Clone` bound by mistake.
… r=alexcrichton Add a note about overflow for fetch_add/fetch_sub Fixes rust-lang#40916 Fixes rust-lang#34618 r? @steveklabnik
Add ptr::offset_to This PR adds a method to calculate the signed distance (in number of elements) between two pointers. The resulting value can then be passed to `offset` to get one pointer from the other. This is similar to pointer subtraction in C/C++. There are 2 special cases: - If the distance is not a multiple of the element size then the result is rounded towards zero. (in C/C++ this is UB) - ZST return `None`, while normal types return `Some(isize)`. This forces the user to handle the ZST case in unsafe code. (C/C++ doesn't have ZSTs)
…hton mark build::cfg::start_new_block as inline(never) LLVM has a bug - [PR32488](https://bugs.llvm.org//show_bug.cgi?id=32488) - where it fails to deduplicate allocas in some circumstances. The function `start_new_block` has allocas totalling 1216 bytes, and when LLVM inlines several copies of that function into the recursive function `expr::into`, that function's stack space usage goes into tens of kiBs, causing stack overflows. Mark `start_new_block` as inline(never) to keep it from being inlined, getting stack usage under control. Fixes rust-lang#40493. Fixes rust-lang#40573. r? @eddyb
Let .rev()'s find use the underlying rfind and vice versa - Connect the plumbing in an obvious way from Rev's find → underlying rfind and vice versa - A style change in the provided implementation for Iterator::rfind, using simple next_back when it is enough
…pls, r=estebank Make 'overlapping_inherent_impls' lint a hard error This is ought to be implemented in PR rust-lang#40728. Unfortunately, when I rebased the PR to resolve merge conflict, the "hard error" code disappeared. This PR complements the initial PR. Now the following rust code gives the following error: ```rust struct Foo; impl Foo { fn id() {} } impl Foo { fn id() {} } fn main() {} ``` ``` error[E0592]: duplicate definitions with name `id` --> /home/topecongiro/test.rs:4:5 | 4 | fn id() {} | ^^^^^^^^^^ duplicate definitions for `id` ... 8 | fn id() {} | ---------- other definition for `id` error: aborting due to previous error ```
Replace magic number with readable sig constant SIG_ERR is defined as 'pub const SIG_ERR: sighandler_t = !0 as sighandler_t;'
…excrichton [T]::rsplit() and rsplit_mut(), rust-lang#41020
…h-final, r=nikomatsakis ICH: Replace old, transitive metadata hashing with direct hashing approach. This PR replaces the old crate metadata hashing strategy with a new one that directly (but stably) hashes all values we encode into the metadata. Previously we would track what data got accessed during metadata encoding and then hash the input nodes (HIR and upstream metadata) that were transitively reachable from the accessed data. While this strategy was sound, it had two major downsides: 1. It was susceptible to generating false positives, i.e. some input node might have changed without actually affecting the content of the metadata. That metadata entry would still show up as changed. 2. It was susceptible to quadratic blow-up when many metadata nodes shared the same input nodes, which would then get hashed over and over again. The new method does not have these disadvantages and it's also a first step towards caching more intermediate results in the compiler. Metadata hashing/cross-crate incremental compilation is still kept behind the `-Zincremental-cc` flag even after this PR. Once the new method has proven itself with more tests, we can remove the flag and enable cross-crate support by default again. r? @nikomatsakis cc @rust-lang/compiler
Update cargo submodules Brings in a fix for rust-lang#40955 through rust-lang/cargo#3898. Closes rust-lang#40955
…imNN COPYRIGHT: remove hoedown license Hoedown was removed in b96fef8 Also cleanup src/tools/tidy/src/main.rs
…, r=nikomatsakis
Highlight and simplify mismatched types
Shorten mismatched types errors by replacing subtypes that are not
different with `_`, and highlighting only the subtypes that are
different.
Given a file
```rust
struct X<T1, T2> {
x: T1,
y: T2,
}
fn foo() -> X<X<String, String>, String> {
X { x: X {x: "".to_string(), y: 2}, y: "".to_string()}
}
fn bar() -> Option<String> {
"".to_string()
}
```
provide the following output
```rust
error[E0308]: mismatched types
--> file.rs:6:5
|
6 | X { x: X {x: "".to_string(), y: 2}, y: "".to_string()}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `std::string::String`, found {integer}
|
= note: expected type `X<X<_, std::string::String>, _>`
^^^^^^^^^^^^^^^^^^^ // < highlighted
found type `X<X<_, {integer}>, _>`
^^^^^^^^^ // < highlighted
error[E0308]: mismatched types
--> file.rs:6:5
|
10 | "".to_string()
| ^^^^^^^^^^^^^^ expected struct `std::option::Option`, found `std::string::String`
|
= note: expected type `Option<std::string::String>`
^^^^^^^ ^ // < highlighted
found type `std::string::String`
```
Fix rust-lang#21025. Re: rust-lang#40186. Follow up to rust-lang#39906.
I'm looking to change how this output is accomplished so that it doesn't create list of strings to pass around, but rather add an elided `Ty` placeholder, and use the same string formatting for normal types. I'll be doing that soonish.
r? @nikomatsakis
Fix pairs of doubles using an illegal <8 x i8> vector. Accidentally introduced in rust-lang#40658 and discovered in some Objective-C bindings (returning `NSPoint`). Turns out LLVM will widen element types of illegal vectors instead of increasing element count, i.e. it will zero-extend `<8 x i8>` to `<8 x i16>`, interleaving the bytes, instead of using the first 8 of `<16 x i8>`.
move rvalue checking to MIR
…eGomez Minor nits in primitive str Some minor updates to linking, added some links, doc format, etc. r? @GuillaumeGomez
Rollup of 9 pull requests - Successful merges: rust-lang#41063, rust-lang#41087, rust-lang#41141, rust-lang#41166, rust-lang#41183, rust-lang#41205, rust-lang#41206, rust-lang#41232, rust-lang#41243 - Failed merges:
…g#41228. Added test cases to cover all special-cased branches of udivmodti4.
Derive Hash for ThreadId + better example Derive `Hash` for `ThreadId` (see comments in rust-lang#21507). Useful for making maps based on thread, e.g. `HashMap<ThreadId, ?>`. Also update example code for thread IDs to be more useful.
to_owned generalizes clone; this generalizes clone_from. Use to_owned to give it a default impl. Customize the impl for [T], str, and T:Clone. Use it in Cow::clone_from to reuse resources when cloning Owned into Owned.
…h-obligation, r=arielb1
Handle subtyping in inference through obligations
We currently store subtyping relations in the `TypeVariables` structure as a kind of special case. This branch uses normal obligations to propagate subtyping, thus converting our inference variables into normal fallback. It also does a few other things:
- Removes the (unstable, outdated) support for custom type inference fallback.
- It's not clear how we want this to work, but we know that we don't want it to work the way it currently does.
- The existing support was also just getting in my way.
- Fixes rust-lang#30225, which was caused by the trait caching code pretending type variables were normal unification variables, when indeed they were not (but now are).
There is one fishy part of these changes: when computing the LUB/GLB of a "bivariant" type parameter, I currently return the `a` value. Bivariant type parameters are only allowed in a very particular situation, where the type parameter is only used as an associated type output, like this:
```rust
pub struct Foo<A, B>
where A: Fn() -> B
{
data: A
}
```
In principle, if one had `T=Foo<A, &'a u32>` and `U=Foo<A, &'b u32>` and (e.g.) `A: for<'a> Fn() -> &'a u32`, then I think that computing the LUB of `T` and `U` might do the wrong thing. Probably the right behavior is just to create a fresh type variable. However, that particular example would not compile (because the where-clause is illegal; `'a` does not appear in any input type). I was not able to make an example that *would* compile and demonstrate this shortcoming, and handling the LUB/GLB was mildly inconvenient, so I left it as is. I am considering whether to revisit this or what.
I have started a crater run to test the impact of these changes.
This commit enables the `rust-analysis` package to be produced for all targets that are part of the `dist-*` suite of docker images on Travis. Currently these packages are showing up with `available = false` in the `channel-rust-nightly.toml` manifest where we'd prefer to have them show up for all targets. Unfortunately rustup isn't handling the `available = false` section well right now, so this should also inadvertently fix the nightly regression.
…ichton Add a resource-reusing method to `ToOwned` `ToOwned::to_owned` generalizes `Clone::clone`, but `ToOwned` doesn't have an equivalent to `Clone::clone_from`. This PR adds such a method as `clone_into` under a new unstable feature `toowned_clone_into`. Analogous to `clone_from`, this has the obvious default implementation in terms of `to_owned`. I've updated the `libcollections` impls: for `T:Clone` it uses `clone_from`, for `[T]` I moved the code from `Vec::clone_from` and implemented that in terms of this, and for `str` it's a predictable implementation in terms of `[u8]`. Used it in `Cow::clone_from` to reuse resources when both are `Cow::Owned`, and added a test that `Cow<str>` thus keeps capacity in `clone_from` in that situation. The obvious question: is this the right place for the method? - It's here so it lives next to `to_owned`, making the default implementation reasonable, and avoiding another trait. But allowing method syntax forces a name like `clone_into`, rather than something more consistent like `owned_from`. - Another trait would allow `owned_from` and could support multiple owning types per borrow type. But it'd be another single-method trait that generalizes `Clone`, and I don't know how to give it a default impl in terms of `ToOwned::to_owned`, since a blanket would mean overlapping impls problems. I did it this way as it's simpler and many of the `Borrow`s/`AsRef`s don't make sense with `owned_from` anyway (`[T;1]:Borrow<[T]>`, `Arc<T>:Borrow<T>`, `String:AsRef<OsStr>`...). I'd be happy to re-do it the other way, though, if someone has a good solution for the default handling. (I can also update with `CStr`, `OsStr`, and `Path` once a direction is decided.)
…xcrichton travis: Enable rust-analysis package for more targets This commit enables the `rust-analysis` package to be produced for all targets that are part of the `dist-*` suite of docker images on Travis. Currently these packages are showing up with `available = false` in the `channel-rust-nightly.toml` manifest where we'd prefer to have them show up for all targets. Unfortunately rustup isn't handling the `available = false` section well right now, so this should also inadvertently fix the nightly regression.
Improve the LLVM IR we generate for trivial functions, especially #[naked] ones. These two small changes fix edef1c/libfringe#68: * Don't emit ZST allocas, such as when returning `()` * Don't emit a branch from LLVM's entry block to MIR's `START_BLOCK` unless needed * That is, if a loop branches back to it, although I'm not sure that's even valid MIR
Updating docs for std::sync::Weak rust-lang#29377 I will duplicate these changes for [`std::rc::Weak`] if they are approved. [`std::rc::Weak`]: https://doc.rust-lang.org/std/rc/struct.Weak.html r? @jonathandturner
Fix invalid 128-bit division on 32-bit target (rust-lang#41228) The bug of rust-lang#41228 is a typo, this line: https://github.com/rust-lang/rust/blob/1dca19ae3fd195fa517e326a39bfee729da7cadb/src/libcompiler_builtins/lib.rs#L183 ```rust // 1 <= sr <= u64::bits() - 1 q = n.wrapping_shl(64u32.wrapping_sub(sr)); ``` The **64** should be **128**. (Compare with https://github.com/rust-lang-nursery/compiler-builtins/blob/280d19f1127aa80739f4179152b11a5f7d36d79f/src/int/udiv.rs#L213-L214: ```rust // 1 <= sr <= <hty!($ty)>::bits() - 1 q = n << (<$ty>::bits() - sr); ``` Or compare with the C implementation https://github.com/llvm-mirror/compiler-rt/blob/master/lib/builtins/udivmodti4.c#L113-L116 ```c /* 1 <= sr <= n_udword_bits - 1 */ /* q.all = n.all << (n_utword_bits - sr); */ q.s.low = 0; q.s.high = n.s.low << (n_udword_bits - sr); ``` ) Added a bunch of randomly generated division test cases to try to cover every described branch of `udivmodti4`.
Updating docs for std::rc::Rc The same changes as PR [rust-lang#41240 ](rust-lang#41240), but for [`std::rc::Weak`](https://doc.rust-lang.org/std/rc/struct.Weak.html). At least, as far as I am aware, the Weak pointer is the same for both, and they're basically the same, just one is thread-safe and the other is not. r? @alexcrichton
|
Some changes occurred in HTML/CSS. |
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @eddyb (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.