Dan Robertson [Sat, 12 May 2018 19:04:44 +0000 (19:04 +0000)]
typeck: Save the index of private fields
Save the index of all fields regardless of their visibility. Problems
could occur later when attempting to index fields in error recovery if
they are not inserted.
bors [Sat, 12 May 2018 09:42:11 +0000 (09:42 +0000)]
Auto merge of #50352 - porglezomp:btree-no-empty-alloc, r=Gankro
Don't allocate when creating an empty BTree
Following the discussion in #50266, this adds a static instance of `LeafNode` that empty BTrees point to, and then replaces it on `insert`, `append`, and `entry`. This avoids allocating for empty maps.
bors [Sat, 12 May 2018 05:42:10 +0000 (05:42 +0000)]
Auto merge of #50476 - zackmdavis:tame_unreachable_pub_suggestion, r=Manishearth
don't make crazy suggestion for unreachable braced pub-use
The Higher Intermediate Representation doesn't have spans for visibility
keywords, so we were assuming that the first whitespace-delimited token
in the item span was the `pub` to be weakened. This doesn't work for
brace-grouped `use`s, which get lowered as if they were several
individual `use` statements, but with spans that only cover the braced
path-segments. Constructing a correct suggestion here presents some
challenges—until someone works those out, we can at least protect the
dignity of our compiler by not offering any suggestion at all for `use` items.
This resolves #50455 (but again, it would be desirable in the future to
make a correct suggestion instead of copping out like this).
bors [Fri, 11 May 2018 23:06:27 +0000 (23:06 +0000)]
Auto merge of #50161 - rizakrko:impl_note, r=estebank
added missing implementation hint
Fixes [#50151](https://github.com/rust-lang/rust/issues/50151).
Actually, i don't know, should following code
`let x = |ref x: isize| { x += 1; };`
emit
`note: an implementation of std::ops::AddAssign might be missing for &isize`
or
`note: this is a reference to a type that + can be applied to; you need to dereference this variable once for this operation to work`
or both
bors [Fri, 11 May 2018 19:46:16 +0000 (19:46 +0000)]
Auto merge of #50105 - mixi:crt-included, r=alexcrichton
Use the correct crt*.o files when linking musl targets.
This is supposed to support optionally using the system copy of musl
libc instead of the included one if supported. This currently only
affects the start files, which is enough to allow building rustc on musl
targets.
Most of the changes are analogous to crt-static.
Excluding the start files is something musl based distributions usually patch into their copy of rustc:
- https://github.com/alpinelinux/aports/blob/eb064c8/community/rust/musl-fix-linux_musl_base.patch
- https://github.com/voidlinux/void-packages/blob/77400fc/srcpkgs/rust/patches/link-musl-dynamically.patch
For third-party distributions that not yet carry those patches it would be nice if it was supported without the need to patch upstream sources.
## Reasons
### What breaks?
Some start files were missed when originally writing the logic to swap in musl start files (gcc comes with its own start files, which are suppressed by -nostdlib, but not manually included later on). This caused #36710, which also affects rustc with the internal llvm copy or any other system libraries that need crtbegin/crtend.
### How is it fixed?
The system linker already has all the logic to decide which start files to include, so we can just defer to it (except of course if it doesn't target musl).
### Why is it optional?
In #40113 it was first tried to remove the start files, which broke compiling musl-targeting static binaries with a glibc-targeting compiler. This is why it eventually landed without removing the start files. Being an option side-steps the issue.
### Why are the start files still installed?
This has the nice side-effect, that the produced rust-std-* binaries can still be used by on a glibc-targeting system with a rustc built against glibc.
## Does it work?
With the following build script (using [musl-cross-make](https://github.com/richfelker/musl-cross-make)): https://shadowice.org/~mixi/rust-musl/build.sh, I was able to cross-compile a musl-host musl-targeting rustc on a glibc-based system. The resulting binaries are at https://shadowice.org/~mixi/rust-musl/binaries/. This also requires #50103 and #50104 (which are also applied to the branch the build script uses).
bors [Fri, 11 May 2018 07:28:51 +0000 (07:28 +0000)]
Auto merge of #50620 - alexcrichton:change-names-again, r=nikomatsakis
Rename the 2018 edition lint names
* `rust_2018_breakage` -> `rust_2018_compatibility` - the lint for ensuring
that your code, in the 2015 edition, is compatible with the 2018 edition's
semantics. This is required to pass *before* you enable the 2018 edition.
* `rust_2018_migration` -> `rust_2018_idioms` - the lint for writing idiomatic
code after you've already enabled the 2018 edition
Zack M. Davis [Sun, 6 May 2018 05:14:33 +0000 (22:14 -0700)]
don't make crazy suggestion for unreachable braced pub-use
The Higher Intermediate Representation doesn't have spans for visibility
keywords, so we were assuming that the first whitespace-delimited token
in the item span was the `pub` to be weakened. This doesn't work for
brace-grouped `use`s, which get lowered as if they were several
individual `use` statements, but with spans that only cover the braced
path-segments. Constructing a correct suggestion here presents some
challenges—until someone works those out, we can at least protect the
dignity of our compiler marking the suggestion for `use` items as
potentially incorrect.
This resolves #50455 (but again, it would be desirable in the future to
make a correct suggestion instead of copping out like this).
bors [Fri, 11 May 2018 02:14:25 +0000 (02:14 +0000)]
Auto merge of #50440 - nikomatsakis:single-use-lifetimes, r=cramertj
Improve single-use and zero-use lifetime lints
The code now correctly identifies *when* to lint -- or more correctly, anyhow -- but it doesn't yet offer suggestions for how to fix.
(I just remembered when writing this I had meant to go back over some of these cases around e.g. impl Trait and double check that everything is right...)
bors [Thu, 10 May 2018 23:33:13 +0000 (23:33 +0000)]
Auto merge of #50611 - alexcrichton:rollup, r=alexcrichton
Rollup of 18 pull requests
Successful merges:
- #49423 (Extend tests for RFC1598 (GAT))
- #50010 (Give SliceIndex impls a test suite of girth befitting the implementation (and fix a UTF8 boundary check))
- #50447 (Fix update-references for tests within subdirectories.)
- #50514 (Pull in a wasm fix from LLVM upstream)
- #50524 (Make DepGraph::previous_work_products immutable)
- #50532 (Don't use Lock for heavily accessed CrateMetadata::cnum_map.)
- #50538 ( Make CrateNum allocation more thread-safe. )
- #50564 (Inline `Span` methods.)
- #50565 (Use SmallVec for DepNodeIndex within dep_graph.)
- #50569 (Allow for specifying a linker plugin for cross-language LTO)
- #50572 (Clarify in the docs that `mul_add` is not always faster.)
- #50574 (add fn `into_inner(self) -> (Idx, Idx)` to RangeInclusive (#49022))
- #50575 (std: Avoid `ptr::copy` if unnecessary in `vec::Drain`)
- #50588 (Move "See also" disambiguation links for primitive types to top)
- #50590 (Fix tuple struct field spans)
- #50591 (Restore RawVec::reserve* documentation)
- #50598 (Remove unnecessary mutable borrow and resizing in DepGraph::serialize)
- #50606 (Retry when downloading the Docker cache.)
Failed merges:
- #50161 (added missing implementation hint)
- #50558 (Remove all reference to DepGraph::work_products)
Alex Crichton [Thu, 10 May 2018 18:28:11 +0000 (11:28 -0700)]
Rename the 2018 edition lint names
* `rust_2018_breakage` -> `rust_2018_compatibility` - the lint for ensuring
that your code, in the 2015 edition, is compatible with the 2018 edition's
semantics. This is required to pass *before* you enable the 2018 edition.
* `rust_2018_migration` -> `rust_2018_idioms` - the lint for writing idiomatic
code after you've already enabled the 2018 edition
Alex Crichton [Thu, 10 May 2018 16:35:37 +0000 (11:35 -0500)]
Rollup merge of #50598 - whitfin:unnecessary-mut-borrow, r=michaelwoerister
Remove unnecessary mutable borrow and resizing in DepGraph::serialize
I might be mistaken, but I noticed this whilst in this file for something else. It appears that this mutable borrow is unnecessary and since it's locking it should be removed. The resizing looks redundant since nothing additional is added to the fingerprints in this function, so that can also be removed.
Alex Crichton [Thu, 10 May 2018 16:35:35 +0000 (11:35 -0500)]
Rollup merge of #50591 - glandium:cleanup, r=dtolnay
Restore RawVec::reserve* documentation
When the RawVec::try_reserve* methods were added, they took the place of
the ::reserve* methods in the source file, and new ::reserve* methods
wrapping the new try_reserve* methods were created. But the
documentation didn't move along, such that:
- reserve_* methods are barely documented.
- try_reserve_* methods have unmodified documentation from reserve_*,
such that their documentation indicate they are panicking/aborting.
This moves the documentation back to the right methods, with a
placeholder documentation for the try_reserve* methods.
Alex Crichton [Thu, 10 May 2018 16:35:32 +0000 (11:35 -0500)]
Rollup merge of #50575 - alexcrichton:faster-drain-drop, r=sfackler
std: Avoid `ptr::copy` if unnecessary in `vec::Drain`
This commit is spawned out of a performance regression investigation in #50496.
In tracking down this regression it turned out that the `expand_statements`
function in the compiler was taking quite a long time. Further investigation
showed two key properties:
* The function was "fast" on glibc 2.24 and slow on glibc 2.23
* The hottest function was memmove from glibc
Combined together it looked like glibc gained an optimization to the memmove
function in 2.24. Ideally we don't want to rely on this optimization, so I
wanted to dig further to see what was happening.
The hottest part of `expand_statements` was `Drop for Drain` in the call to
`splice` where we insert new statements into the original vector. This *should*
be a cheap operation because we're draining and replacing iterators of the exact
same length, but under the hood memmove was being called a lot, causing a
slowdown on glibc 2.23.
It turns out that at least one of the optimizations in glibc 2.24 was that
`memmove` where the src/dst are equal becomes much faster. [This program][prog]
executes in ~2.5s against glibc 2.23 and ~0.3s against glibc 2.24, exhibiting
how glibc 2.24 is optimizing `memmove` if the src/dst are equal.
And all that brings us to what this commit itself is doing. The change here is
purely to `Drop for Drain` to avoid the call to `ptr::copy` if the region being
copied doesn't actually need to be copied. For normal usage of just `Drain`
itself this check isn't really necessary, but because `Splice` internally
contains `Drain` this provides a nice speed boost on glibc 2.23. Overall this
should fix the regression seen in #50496 on glibc 2.23 and also fix the
regression on Windows where `memmove` looks to not have this optimization.
Note that the way `splice` was called in `expand_statements` would cause a
quadratic number of elements to be copied via `memmove` which is likely why the
tuple-stress benchmark showed such a severe regression.
Alex Crichton [Thu, 10 May 2018 16:35:28 +0000 (11:35 -0500)]
Rollup merge of #50569 - michaelwoerister:cross-lang-lto-2, r=alexcrichton
Allow for specifying a linker plugin for cross-language LTO
This PR makes the `-Zcross-lang-lto` flag optionally take the path to the `LLVMgold.so` linker plugin. If this path is specified, `rustc` will invoke the linker with the correct arguments (i.e. `-plugin` and various `-plugin-opt`s).
This can be used to ergonomically enable cross-language LTO for Rust programs with C/C++ dependencies:
```
clang -O2 test.c -otest.o -c -flto=thin
llvm-ar -rv libxxx.a test.o
rustc -L. main.rs -Zcross-lang-lto=/usr/lib64/LLVMgold.so -O -Clink-arg=-fuse-ld=gold
```
- Note that in theory this should work with Gold, LLD, and newer versions of binutils' LD but on my current system I could only get it to work with Gold.
- Also note that this will work best if the Clang version and Rust's LLVM version are close enough. Clang 6.0 works well with the current nightly.
Alex Crichton [Thu, 10 May 2018 16:35:24 +0000 (11:35 -0500)]
Rollup merge of #50538 - michaelwoerister:atomic-cnums, r=Zoxc
Make CrateNum allocation more thread-safe.
This PR makes sure that we can't have race conditions when assigning CrateNums. It's a slight improvement but a larger refactoring of the CrateStore/CrateLoader infrastructure would be good, I think.
Alex Crichton [Thu, 10 May 2018 16:35:23 +0000 (11:35 -0500)]
Rollup merge of #50532 - michaelwoerister:lockless-cnum-map, r=Zoxc
Don't use Lock for heavily accessed CrateMetadata::cnum_map.
The `cnum_map` in `CrateMetadata` is used for two things:
1. to map `CrateNums` between crates (used a lot during decoding)
2. to construct the (reverse) post order of the crate graph
For the second case, we need to modify the map after the fact, which is why the map is wrapped in a `Lock`. This is bad for the first case, which does not need the modification and does lots of small reads from the map.
This PR splits case (2) out into a separate `dependencies` field. This allows to make the `cnum_map` immutable (and shifts the interior mutability to a less busy data structure).
Alex Crichton [Thu, 10 May 2018 16:35:17 +0000 (11:35 -0500)]
Rollup merge of #50010 - ExpHP:slice-bounds, r=alexcrichton
Give SliceIndex impls a test suite of girth befitting the implementation (and fix a UTF8 boundary check)
So one day I was writing something in my codebase that basically amounted to `impl SliceIndex for (Bound<usize>, Bound<usize>)`, and I said to myself:
*Boy, gee, golly! I never realized bounds checking was so tricky!*
At some point when I had around 60 lines of tests for it, I decided to go see how the standard library does it to see if I missed any edge cases. ...That's when I discovered that libcore only had about 40 lines of tests for slicing altogether, and none of them even used `..=`.
---
This PR includes:
* **Literally the first appearance of the word `get_unchecked_mut` in any directory named `test` or `tests`.**
* Likewise the first appearance of `get_mut` used with _any type of range argument_ in these directories.
* Tests for the panics on overflow with `..=`.
* I wanted to test on `[(); usize::MAX]` as well but that takes linear time in debug mode </3
* A horrible and ugly test-generating macro for the `should_panic` tests that increases the DRYness by a single order of magnitude (which IMO wasn't enough, but I didn't want to go any further and risk making the tests inaccessible to next guy).
* Same stuff for str!
* Actually, the existing `str` tests were pretty good. I just helped filled in the holes.
* [A fix for the bug it caught](https://github.com/rust-lang/rust/issues/50002). (only one ~~sadly~~)
Alex Crichton [Thu, 10 May 2018 16:35:16 +0000 (11:35 -0500)]
Rollup merge of #49423 - gavento:gavento-dev, r=nikomatsakis
Extend tests for RFC1598 (GAT)
More GAT tests, namely some usage for `Iterable` and `StreamingIterator`, shadowing (lifetimes and type params), `Collection<T>` and `CollectionFamily` from [the series](http://smallcultfollowing.com/babysteps/blog/2016/11/03/associated-type-constructors-part-2-family-traits/) with default associated types. Tracking issue: #44265
r? @nikomatsakis
Wrong GAT argument numbers / kinds and default values are next.
bors [Thu, 10 May 2018 16:27:32 +0000 (16:27 +0000)]
Auto merge of #49823 - Zoxc:term-str, r=alexcrichton
Remove usages of Term::as_str and mark it for removal
Returning references to rustc internal data structures is a bad idea since their lifetimes are unrelated to the lifetimes of proc_macro values.
See https://github.com/rust-lang/rust/pull/46972 and the `Taming thread-local storage` section of https://internals.rust-lang.org/t/parallelizing-rustc-using-rayon/6606
bors [Thu, 10 May 2018 14:14:35 +0000 (14:14 +0000)]
Auto merge of #50395 - Zoxc:small-tys, r=michaelwoerister
Optimize layout of TypeVariants
This makes references to `Slice` use thin pointers by storing the slice length in the slice itself. `GeneratorInterior` is replaced by storing the movability of generators in `TyGenerator` and the interior witness is stored in `GeneratorSubsts` (which is just a wrapper around `&'tcx Substs`, like `ClosureSubsts`). Finally the fields of `TypeAndMut` is stored inline in `TyRef`. These changes combine to reduce `TypeVariants` from 48 bytes to 24 bytes on x86_64.
Mike Hommey [Thu, 10 May 2018 00:16:10 +0000 (09:16 +0900)]
Restore RawVec::reserve* documentation
When the RawVec::try_reserve* methods were added, they took the place of
the ::reserve* methods in the source file, and new ::reserve* methods
wrapping the new try_reserve* methods were created. But the
documentation didn't move along, such that:
- reserve_* methods are barely documented.
- try_reserve_* methods have unmodified documentation from reserve_*,
such that their documentation indicate they are panicking/aborting.
This moves the documentation back to the right methods, with a
placeholder documentation for the try_reserve* methods.
Alex Crichton [Tue, 24 Apr 2018 15:34:14 +0000 (08:34 -0700)]
ci: Compile LLVM with Clang 6.0.0
Currently on CI we predominately compile LLVM with the default system compiler
which means gcc on Linux, some version of Clang on OSX, MSVC on Windows, and
gcc on MinGW. This commit switches Linux, OSX, and Windows to all use Clang
6.0.0 to build LLVM (aka the C/C++ compiler as part of the bootstrap). This
looks to generate faster code according to #49879 which translates to a faster
rustc (as LLVM internally is faster)
The major changes here were to the containers that build Linux releases,
basically adding a new step that uses the previous gcc 4.8 compiler to compile
the next Clang 6.0.0 compiler. Otherwise the OSX and Windows scripts have been
updated to download precompiled versions of Clang 6 and configure the build to
use them.
Note that `cc` was updated here to fix using `clang-cl` with `cc-rs` on MSVC, as
well as an update to `sccache` on Windows which was needed to correctly work
with `clang-cl`. Finally the MinGW compiler is entirely left out here
intentionally as it's currently thought that Clang can't generate C++ code for
MinGW and we need to use gcc, but this should be verified eventually.
bors [Wed, 9 May 2018 16:56:30 +0000 (16:56 +0000)]
Auto merge of #49711 - ibabushkin:auto_trait_refactor, r=nikomatsakis
Refactor auto trait handling in librustdoc to be accessible from librustc.
These commits transfer some of the functionality introduced in https://github.com/rust-lang/rust/pull/47833 to librustc with the intention of making the tools to work with auto traits accessible to third-party code, for example [rust-semverver](https://github.com/rust-lang-nursery/rust-semverver).
Some rough edges remain, and I'm certain some of the FIXMEs introduced will need some discussion, most notably the fairly ugly overall approach to pull out the core logic into librustc, which was previously fairly tightly coupled with various bits and bobs from librustdoc.
Alex Crichton [Wed, 9 May 2018 15:33:49 +0000 (08:33 -0700)]
std: Avoid `ptr::copy` if unnecessary in `vec::Drain`
This commit is spawned out of a performance regression investigation in #50496.
In tracking down this regression it turned out that the `expand_statements`
function in the compiler was taking quite a long time. Further investigation
showed two key properties:
* The function was "fast" on glibc 2.24 and slow on glibc 2.23
* The hottest function was memmove from glibc
Combined together it looked like glibc gained an optimization to the memmove
function in 2.24. Ideally we don't want to rely on this optimization, so I
wanted to dig further to see what was happening.
The hottest part of `expand_statements` was `Drop for Drain` in the call to
`splice` where we insert new statements into the original vector. This *should*
be a cheap operation because we're draining and replacing iterators of the exact
same length, but under the hood memmove was being called a lot, causing a
slowdown on glibc 2.23.
It turns out that at least one of the optimizations in glibc 2.24 was that
`memmove` where the src/dst are equal becomes much faster. [This program][prog]
executes in ~2.5s against glibc 2.23 and ~0.3s against glibc 2.24, exhibiting
how glibc 2.24 is optimizing `memmove` if the src/dst are equal.
And all that brings us to what this commit itself is doing. The change here is
purely to `Drop for Drain` to avoid the call to `ptr::copy` if the region being
copied doesn't actually need to be copied. For normal usage of just `Drain`
itself this check isn't really necessary, but because `Splice` internally
contains `Drain` this provides a nice speed boost on glibc 2.23. Overall this
should fix the regression seen in #50496 on glibc 2.23 and also fix the
regression on Windows where `memmove` looks to not have this optimization.
Note that the way `splice` was called in `expand_statements` would cause a
quadratic number of elements to be copied via `memmove` which is likely why the
tuple-stress benchmark showed such a severe regression.
bors [Wed, 9 May 2018 13:28:15 +0000 (13:28 +0000)]
Auto merge of #50546 - kennytm:rollup, r=kennytm
Rollup of 11 pull requests
Successful merges:
- #49988 (Mention Result<!, E> in never docs.)
- #50148 (turn `ManuallyDrop::new` into a constant function)
- #50456 (Update the Cargo submodule)
- #50460 (Make `String::new()` const)
- #50464 (Remove some transmutes)
- #50505 (Added regression function match value test)
- #50511 (Add some explanations for #[must_use])
- #50525 (Optimize string handling in lit_token().)
- #50527 (Cleanup a `use` in a raw_vec test)
- #50539 (Add more logarithm constants)
- #49523 (Update RELEASES.md for 1.26.0)
kennytm [Wed, 9 May 2018 09:23:31 +0000 (17:23 +0800)]
Rollup merge of #50525 - nnethercote:lit_token, r=michaelwoerister
Optimize string handling in lit_token().
In the common case, the string value in a string literal Token is the
same as the string value in a string literal LitKind. (The exception is
when escapes or \r are involved.) This patch takes advantage of that to
avoid calling str_lit() and re-interning the string in that case. This
speeds up incremental builds for a few of the rustc-benchmarks, the best
by 3%.
In the common case, the string value in a string literal Token is the
same as the string value in a string literal LitKind. (The exception is
when escapes or \r are involved.) This patch takes advantage of that to
avoid calling str_lit() and re-interning the string in that case. This
speeds up incremental builds for a few of the rustc-benchmarks, the best
by 3%.
C Jones [Tue, 8 May 2018 17:28:49 +0000 (13:28 -0400)]
Make an ensure_root_is_owned method to reduce duplication
Also remove some unnecessary debug_assert! when creating the shared
root, since the root should be stored in the rodata and thus be
impossible to accidentally modify.
bors [Tue, 8 May 2018 14:45:16 +0000 (14:45 +0000)]
Auto merge of #50497 - RalfJung:pinmut, r=withoutboats
Rename Pin to PinMut, and some more breaking changes
As discussed at [1] §3 and [2] and [3], a formal look at pinning requires considering a distinguished "shared pinned" mode/typestate. Given that, it seems desirable to at least eventually actually expose that typestate as a reference type. This renames Pin to PinMut, freeing the name Pin in case we want to use it for a shared pinned reference later on.
projects / rust.git / log