Rollup merge of #41056 - michaelwoerister:central-defpath-hashes, r=nikomatsakis
Handle DefPath hashing centrally as part of DefPathTable (+ save work during SVH calculation)
In almost all cases where we construct a `DefPath`, we just hash it and throw it away again immediately.
With this PR, the compiler will immediately compute and store the hash for each `DefPath` as it is allocated. This way we
+ can get rid of any subsequent `DefPath` hash caching (e.g. the `DefPathHashes`),
+ don't need to allocate a transient `Vec` for holding the `DefPath` (although I'm always surprised how little these small, dynamic allocations seem to hurt performance), and
+ we don't hash `DefPath` prefixes over and over again.
That last part is because we construct the hash for `prefix::foo` by hashing `(hash(prefix), foo)` instead of hashing every component of prefix.
The last commit of this PR is pretty neat, I think:
```
The SVH (Strict Version Hash) of a crate is currently computed
by hashing the ICHes (Incremental Computation Hashes) of the
crate's HIR. This is fine, expect that for incr. comp. we compute
two ICH values for each HIR item, one for the complete item and
one that just includes the item's interface. The two hashes are
are needed for dependency tracking but if we are compiling
non-incrementally and just need the ICH values for the SVH,
one of them is enough, giving us the opportunity to save some
work in this case.
```
r? @nikomatsakis
This PR depends on https://github.com/rust-lang/rust/pull/40878 to be merged first (you can ignore the first commit for reviewing, that's just https://github.com/rust-lang/rust/pull/40878).
Rollup merge of #41047 - cuviper:src_is_git, r=alexcrichton
Only use cargo-vendor if building from git sources
The only time we need to vendor sources is when building from git. If one is
building from a rustc source tarball, everything should already be in place.
This also matters for distros which do offline builds, as they can't install
cargo-vendor this way.
This adds a common `Build::src_is_git` flag, and then uses it in the dist-src
target to decide whether to install or use `cargo-vendor` at all.
SVH: Don't hash the HIR twice when once is enough.
The SVH (Strict Version Hash) of a crate is currently computed
by hashing the ICHes (Incremental Computation Hashes) of the
crate's HIR. This is fine, expect that for incr. comp. we compute
two ICH values for each HIR item, one for the complete item and
one that just includes the item's interface. The two hashes are
are needed for dependency tracking but if we are compiling
non-incrementally and just need the ICH values for the SVH,
one of them is enough, giving us the opportunity to save some
work in this case.
Auto merge of #40873 - cramertj:on-demandify-queries, r=nikomatsakis
On demandify reachability
cc https://github.com/rust-lang/rust/issues/40746
I tried following this guidance from #40746:
> The following tasks currently execute before a tcx is built, but they could be easily converted into queries that are requested after tcx is built. The main reason they are the way they are was to avoid a gratuitious refcell (but using the refcell map seems fine)...
but the result of moving `region_maps` out of `TyCtxt` and into a query caused a lot of churn, and seems like it could potentially result in a rather large performance hit, since it means a dep-graph lookup on every use of `region_maps` (rather than just a field access). Possibly `TyCtxt` could store a `RefCell<Option<RegionMap>>` internally and use that to prevent repeat lookups, but that feels like it's duplicating the work of the dep-graph. @nikomatsakis What did you have in mind for this?
(For an explanation of what this feature does, read the commit message)
I'd like to propose landing this as an experimental feature (experimental as in:
no clear stabilization path -- like `asm!`, `#[linkage]`) as it's low
maintenance (I think) and relevant to the "Usage in resource-constrained
environments" exploration area.
The main use case I see is running code before `main`. This could be used, for
instance, to cheaply initialize an allocator before `main` where the alternative
is to use `lazy_static` to initialize the allocator on its first use which it's
more expensive (atomics) and doesn't work on ARM Cortex-M0 microcontrollers (no
`AtomicUsize` on that platform)
In general, this pattern could be used to let *dependencies* run code before
`main` (which sounds like it could go very wrong in some cases). There are
probably other use cases; I hope that the people I have cc-ed can comment on
those.
Note that I'm personally unsure if the above pattern is something we want to
promote / allow and that's why I'm proposing this feature as experimental. If
this leads to more footguns than benefits then we can just axe the feature.
cc @nikomatsakis ^ I know you have some thoughts on having a process for
experimental features though I'm fine with writing an RFC before landing this.
- `dead_code` lint will have to be updated to special case `#[used]` symbols.
- Should we extend `#[used]` to work on non-generic functions?
cc rust-lang/rfcs#1002
cc rust-lang/rfcs#1459
cc @dpc @JinShil
Auto merge of #40863 - eddyb:coerce-only-once, r=arielb1
Avoid type-checking addition and indexing twice.
Fixes #40610 by moving the common `check_expr_coercable_to_type` call before the error reporting logic for binops and removing the one from `check_str_addition`.
Fixes #40861 by removing an unnecessary `check_expr_coercable_to_type` call.
Rollup merge of #41112 - ollie27:rustdoc_pull, r=GuillaumeGomez
rustdoc: Use pulldown-cmark for Markdown HTML rendering
Instead of rendering all of the HTML in rustdoc this relies on
pulldown-cmark's `push_html` to do most of the work. A few iterator
adapters are used to make rustdoc specific modifications to the output.
This also fixes MarkdownHtml and link titles in plain_summary_line.
https://ollie27.github.io/rust_doc_test/ is the docs built with this change and #41111.
Rollup merge of #41111 - ollie27:docs_markdown_fix, r=GuillaumeGomez
Fix Markdown issues in the docs
* Since the switch to pulldown-cmark reference links need a blank line
before the URLs. (#40912)
* Reference link references are not case sensitive.
* Doc comments need to be indented uniformly otherwise rustdoc gets
confused.
Rollup merge of #41090 - rap2hpoutre:patch-2, r=steveklabnik
Add example to std::process::abort
This is a second step in order to complete this issue: https://github.com/rust-lang/rust/issues/29370
I submitted this PR with the help of @steveklabnik again. Thanks to him! More info here: https://github.com/rust-lang/rust/issues/29370#issuecomment-290653877
Rollup merge of #40878 - michaelwoerister:dmh, r=nikomatsakis
Introduce HashStable trait and base ICH implementations on it.
This PR introduces the `HashStable` trait which marks that a type can be hashed in a way that is stable across multiple compilation sessions. The PR also moves HIR incr. comp. hashing over to implementations of this trait instead of doing this via a HIR visitor. It also provides many `HashStable` implementations that are not used yet (e.g. for MIR types) but soon will be used when we directly hash crate metadata for incr. comp.
I've only done superficial performance measurements but it looks like the new implementation is a bit faster than the current one (due, I suppose, to some bugs I fixed and some unnecessary inefficiencies I removed). Here is the time in seconds for the `compute_incremental_hashes_map` pass for various crates:
Some notes regarding the implementation:
* Most `HashStable` implementations are provided via the `impl_hash_stable_for!` macro (as suggested by @nikomatsakis). This works out quite well. A custom_derive would have been better but Macros 1.1 are not available in the compiler.
* The trait implementation take care to exhaustively destructure everything they hash so that fields added in the future don't fall through the cracks. This is a bit verbose but I think it's well worth the trouble since we've had quite a few issues with missing fields or visitor callbacks in this area in the past. Most of it is behind the macro anyway.
rustdoc: Use pulldown-cmark for Markdown HTML rendering
Instead of rendering all of the HTML in rustdoc this relies on
pulldown-cmark's `push_html` to do most of the work. A few iterator
adapters are used to make rustdoc specific modifications to the output.
This also fixes MarkdownHtml and link titles in plain_summary_line.
* Since the switch to pulldown-cmark reference links need a blank line
before the URLs.
* Reference link references are not case sensitive.
* Doc comments need to be indented uniformly otherwise rustdoc gets
confused.
`src/bootstrap/clean.rs` has a custom implementation of removing a tree
`fn rm_rf` that used `std::path::Path::{is_file, is_dir, exists}` while
recursively deleting directories and files. Unfortunately, `Path`'s
implementation of `is_file()` and `is_dir()` and `exists()` always
unconditionally follow symlinks, which is the exact opposite of standard
implementations of deleting file trees.
It appears that this custom implementation is being used to workaround a
behavior in Windows where the files often get marked as read-only, which
prevents us from simply using something nice and simple like
`std::fs::remove_dir_all`, which properly deletes links instead of
following them.
So it looks like the fix is to use `.symlink_metadata()` to figure out
whether tree items are files/symlinks/directories. The one corner case
this won't cover is if there is a broken symlink in the "root"
`build/$MYARCH` directory, because those initial entries are run through
`Path::canonicalize()`, which panics with broken symlinks. So lets just
never use symlinks in that one directory. :-)
Rollup merge of #41011 - CleanCut:bootstrap-help, r=alexcrichton
Overhaul Bootstrap (x.py) Command-Line-Parsing & Help Output
While working on #40417, I got frustrated with the behavior of x.py and the bootstrap binary it wraps, so I decided to do something about it. This PR should improve documentation, make the command-line-parsing more flexible, and clean up some of the internals. No command that worked before should stop working. At least that's the theory. :-)
This should resolve at least #40920 and #38373.
Changes:
- No more manual args manipulation -- getopts used everywhere except the one place it's not possible. As a result, options can be in any position, now, even before the subcommand.
- The additional options for test, bench, and dist now appear in the help output.
- No more single-letter variable bindings used internally for large scopes.
- Don't output the time measurement when just invoking `x.py` or explicitly passing `-h` or `--help`
- Logic is now much more linear. We build strings up, and then print them.
- Refer to subcommands as subcommands everywhere (some places we were saying "command")
- Other minor stuff.
@alexcrichton This is my first PR. Do I need to do something specific to request reviewers or anything?
Rollup merge of #40908 - dotdash:pers_lt, r=arielb1
Emit proper lifetime start intrinsics for personality slots
We currently only emit a single call to the lifetime start intrinsic
for the personality slot alloca. This happens because we create that
call at the time that we create the alloca, instead of creating it each
time we start using it. Because LLVM usually removes the alloca before
the lifetime intrinsics are even considered, this didn't cause any
problems yet, but we should fix this anyway.
Rollup merge of #41052 - topecongiro:overlapping_inherent_impls, r=estebank
Make 'overlapping_inherent_impls' lint a hard error
This is ought to be implemented in PR #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`
Rollup merge of #41028 - bluss:rev-rfind, r=alexcrichton
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
Rollup merge of #41015 - arielb1:new-block-stack, r=alexcrichton
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.
Rollup merge of #40943 - Amanieu:offset_to, r=alexcrichton
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)
Rollup merge of #40709 - lifthrasiir:leaner-unicode-debug-str, 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 (0aeb9c129 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.
Rollup merge of #40561 - arthurprs:hm-adapt2, r=pczarn
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.
This is a second (2/3?) step in order to complete this issue: https://github.com/rust-lang/rust/issues/29370
I submitted this PR with the help of @steveklabnik again. Thanks to him! More info here: https://github.com/rust-lang/rust/issues/29370#issuecomment-290653877
Jorge Aparicio [Mon, 20 Feb 2017 19:42:47 +0000 (14:42 -0500)]
add an #[used] attribute
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.
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.
Rollup merge of #41076 - alexcrichton:update-sccache, r=frewsxcv
travis: Update sccache binaries
I've tracked down what I believe is the last spurious sccache failure on #40240
to behavior in mio (carllerche/mio#583), and this commit updates the binaries to
a version which has that fix incorporated.
Rollup merge of #41062 - estebank:private-field, r=arielb1
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 #27654.
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.
Rollup merge of #41019 - mandeep:fix-vec-swapremove-docs, r=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. ```
Rollup merge of #40997 - donniebishop:from_utf8_linking, r=steveklabnik
Added links to types in from_utf8 description
References #29375. Link to types mentioned in the documentation for `from_utf8` (`str`, `&[u8`], etc). Paragraphs were reformatted to keep any one line from being excessively long, but are otherwise unchanged.
Rollup merge of #40870 - alexcrichton:stabilize-windows-subsystem, r=aturon
rustc: Stabilize the `#![windows_subsystem]` attribute
This commit stabilizes the `#![windows_subsystem]` attribute which is a
conservative exposure of the `/SUBSYSTEM` linker flag on Widnows platforms. This
is useful for creating applications as well as console programs.
Kang Seonghoon [Tue, 21 Mar 2017 18:27:06 +0000 (03:27 +0900)]
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.
Auto merge of #40811 - estebank:issue-32540, r=jonathandturner
Point at last valid token on failed `expect_one_of`
```rust
error: expected one of `.`, `;`, `?`, `}`, or an operator, found `)`
--> $DIR/token-error-correct-3.rs:29:9
|
25 | foo()
| - expected one of `.`, `;`, `?`, `}`, or an operator after this
...
29 | } else {
| ^ unexpected token
```
Alex Crichton [Tue, 4 Apr 2017 22:55:23 +0000 (15:55 -0700)]
travis: Update sccache binaries
I've tracked down what I believe is the last spurious sccache failure on #40240
to behavior in mio (carllerche/mio#583), and this commit updates the binaries to
a version which has that fix incorporated.
arthurprs [Wed, 15 Mar 2017 22:26:27 +0000 (23:26 +0100)]
Simplify HashMap Bucket interface
* Store capacity_mask instead of capacity
* Move bucket index into RawBucket
* Bucket index is now always within [0..table_capacity)
* Clone RawTable using RawBucket
* Simplify iterators by moving logic into RawBuckets
* Make retain aware of the number of elements
Tim Neumann [Tue, 4 Apr 2017 13:41:17 +0000 (15:41 +0200)]
Rollup merge of #40998 - alexcrichton:split-dist, r=TimNN
travis: Split all dist builders in two
Previously we would use one builder on Travis to produce two sets of host
compilers for two different targets. Unfortunately though we've recently
increased how much we're building for each target so this is starting to take
unnecessarily long (#40804). This commit splits the dist builders in two by
ensuring that we only dist one target on each builder, which should take a much
shorter amount of time. This should also unblock other work such as landing the
RLS (#40584).