auto merge of #16952 : alexcrichton/rust/windows-large-console-write, r=brson
I've found that 64k is still too much and continue to see the errors as reported
in #14940. I've locally found that 32k fails, and 24k succeeds, so I've trimmed
the size down to 10000 which the included links in the added comment end up
recommending.
It sounds like the limit can still be hit with many threads in play, but I have
yet to reproduce this, so I figure we can wait until that's hit (if it's
possible) and then take action.
Alex Crichton [Wed, 3 Sep 2014 01:39:19 +0000 (18:39 -0700)]
std: Turn down the stdout chunk size
I've found that 64k is still too much and continue to see the errors as reported
in #14940. I've locally found that 32k fails, and 24k succeeds, so I've trimmed
the size down to 8192 which libuv happens to use as well.
It sounds like the limit can still be hit with many threads in play, but I have
yet to reproduce this, so I figure we can wait until that's hit (if it's
possible) and then take action.
This was inspired by seeing a LLVM flatline of **~600MB** when running rustc with jemalloc (each type's `t_box_` is allocated on the heap, creating a lot of fragmentation, which jemalloc can deal with, unlike glibc).
auto merge of #17036 : pczarn/rust/issue-15913-ICE-with-call-trans, r=alexcrichton
A match in callee.rs was recognizing some foreign fns as named tuple constructors. A reproducible test case for this is nearly impossible since it depends on the way NodeIds happen to be assigned in different crates.
auto merge of #16942 : alexcrichton/rust/remove-net-assert, r=brson
This assert was likely inherited from some point, but it's not quite valid as a
no-timeout read may enter this loop, but data could be stolen by any other read
after the socket is deemed readable.
I saw this fail in a recent bors run where the assertion was tripped.
auto merge of #17035 : huonw/rust/moar-jquery, r=alexcrichton
Sometimes (e.g. on Rust CI) the "expand description" text of the
collapse toggle was displayed by default, when a page is first
loaded (even though the description is expanded), because some
Content-Security-Policy settings disable inline CSS.
Setting it the style with the `.css` method allows the output to be used
in more places.
auto merge of #16904 : inrustwetrust/rust/link-path-order, r=alexcrichton
Issue can be reproduced by the following:
```
$ cat main.rs
fn main() {}
$ rustc -Z print-link-args -Lfoo -Lbar main.rs
```
Run the rustc command a few times and observe that the order of the '-L' 'foo' '-L' 'bar' options randomly changes.
Actually hit this issue in practice on Windows when specifying two -L directories to rustc, one with rust-sdl2 in it and one with the C SDL2.dll. Since Windows file systems aren't case-sensitive, gcc randomly attempted to link against the rust sdl2.dll instead of SDL2.dll if that -L directory happened to come first.
The randomness was due to addl_lib_search_paths being a HashSet. Changed it to a Vec instead which maintains the ordering.
Unsure how to test this though since it is random by nature; suggestions very welcome.
auto merge of #17011 : nodakai/rust/rustdoc-stronger-crate, r=alexcrichton
If you browse to, say, http://doc.rust-lang.org/libc/types/os/common/posix01/struct.timeval.html , you will see the "location" window showing `libc::types::os::common::posix01`. The first element points to a crate and others point modules. This patch adds the bold attribute to the first (ie. crate) element so that it stands out more.
auto merge of #16367 : epdtry/rust/parallel-codegen, r=alexcrichton
This branch adds support for running LLVM optimization and codegen on different parts of a crate in parallel. Instead of translating the crate into a single LLVM compilation unit, `rustc` now distributes items in the crate among several compilation units, and spawns worker threads to optimize and codegen each compilation unit independently. This improves compile times on multicore machines, at the cost of worse performance in the compiled code. The intent is to speed up build times during development without sacrificing too much optimization.
On the machine I tested this on, `librustc` build time with `-O` went from 265 seconds (master branch, single-threaded) to 115s (this branch, with 4 threads), a speedup of 2.3x. For comparison, the build time without `-O` was 90s (single-threaded). Bootstrapping `rustc` using 4 threads gets a 1.6x speedup over the default settings (870s vs. 1380s), and building `librustc` with the resulting stage2 compiler takes 1.3x as long as the master branch (44s vs. 55s, single threaded, ignoring time spent in LLVM codegen).
The user-visible changes from this branch are two new codegen flags:
* `-C codegen-units=N`: Distribute items across `N` compilation units.
* `-C codegen-threads=N`: Spawn `N` worker threads for running optimization and codegen. (It is possible to set `codegen-threads` larger than `codegen-units`, but this is not very useful.)
Internal changes to the compiler are described in detail on the individual commit messages.
Note: The first commit on this branch is copied from #16359, which this branch depends on.
Huon Wilson [Sat, 6 Sep 2014 00:35:19 +0000 (10:35 +1000)]
Use more jQuery to avoid displaying Expand Description more often.
Sometimes (e.g. on Rust CI) the "expand description" text of the
collapse toggle was displayed by default, when a page is first
loaded (even though the description is expanded), because some
Content-Security-Policy settings disable inline CSS.
Setting it the style with the `.css` method allows the output to be used
in more places.
make separate compilation respect #[inline] attributes
Adjust the handling of `#[inline]` items so that they get translated into every
compilation unit that uses them. This is necessary to preserve the semantics
of `#[inline(always)]`.
Crate-local `#[inline]` functions and statics are blindly translated into every
compilation unit. Cross-crate inlined items and monomorphizations of
`#[inline]` functions are translated the first time a reference is seen in each
compilation unit. When using multiple compilation units, inlined items are
given `available_externally` linkage whenever possible to avoid duplicating
object code.
Add a post-processing pass to `trans` that converts symbols from external to
internal when possible. Translation with multiple compilation units initially
makes most symbols external, since it is not clear when translating a
definition whether that symbol will need to be accessed from another
compilation unit. This final pass internalizes symbols that are not reachable
from other crates and not referenced from other compilation units, so that LLVM
can perform more aggressive optimizations on those symbols.
avoid duplicate translation of monomorphizations, drop glue, and visit glue
Use a shared lookup table of previously-translated monomorphizations/glue
functions to avoid translating those functions in every compilation unit where
they're used. Instead, the function will be translated in whichever
compilation unit uses it first, and the remaining compilation units will link
against that original definition.
Rotate between compilation units while translating. The "worker threads"
commit added support for multiple compilation units, but only translated into
one, leaving the rest empty. With this commit, `trans` rotates between various
compilation units while translating, using a simple stragtegy: upon entering a
module, switch to translating into whichever compilation unit currently
contains the fewest LLVM instructions.
Most of the actual changes here involve getting symbol linkage right, so that
items translated into different compilation units will link together properly
at the end.
When inlining an item from another crate, use the original symbol from that
crate's metadata instead of generating a new symbol using the `ast::NodeId` of
the inlined copy. This requires exporting symbols in the crate metadata in a
few additional cases. Having predictable symbols for inlined items will be
useful later to avoid generating duplicate object code for inlined items.
Refactor the code in `llvm::back` that invokes LLVM optimization and codegen
passes so that it can be called from worker threads. (Previously, it used
`&Session` extensively, and `Session` is not `Share`.) The new code can handle
multiple compilation units, by compiling each unit to `crate.0.o`, `crate.1.o`,
etc., and linking together all the `crate.N.o` files into a single `crate.o`
using `ld -r`. The later linking steps can then be run unchanged.
The new code preserves the behavior of `--emit`/`-o` when building a single
compilation unit. With multiple compilation units, the `--emit=asm/ir/bc`
options produce multiple files, so combinations like `--emit=ir -o foo.ll` will
not actually produce `foo.ll` (they instead produce several `foo.N.ll` files).
The new code supports `-Z lto` only when using a single compilation unit.
Compiling with multiple compilation units and `-Z lto` will produce an error.
(I can't think of any good reason to do such a thing.) Linking with `-Z lto`
against a library that was built as multiple compilation units will also fail,
because the rlib does not contain a `crate.bytecode.deflate` file. This could
be supported in the future by linking together the `crate.N.bc` files produced
when compiling the library into a single `crate.bc`, or by making the LTO code
support multiple `crate.N.bytecode.deflate` files.
Break up `CrateContext` into `SharedCrateContext` and `LocalCrateContext`. The
local piece corresponds to a single compilation unit, and contains all
LLVM-related components. (LLVM data structures are tied to a specific
`LLVMContext`, and we will need separate `LLVMContext`s to safely run
multithreaded optimization.) The shared piece contains data structures that
need to be shared across all compilation units, such as the `ty::ctxt` and some
tables related to crate metadata.
Piotr Czarnecki [Tue, 15 Jul 2014 20:58:35 +0000 (21:58 +0100)]
std: Refine and document HashMap's code
* branchless `bucket.next()`
* robin_hood is a free function
* fixed the resize policy that was off by one
* documented the growth algorithm
* updated documentation after interface changes
* removed old fixmes
auto merge of #16883 : jakub-/rust/issue-16648, r=pcwalton
They were only correct in the simplest case. Some of the optimisations
are certainly possible but should be introduced carefully and only
when the whole pattern codegen infrastructure is in a better shape.
auto merge of #16909 : carols10cents/rust/docs-links, r=alexcrichton
This has the primary advantage of not interfering with browser default behavior for links like being able to cmd/ctrl+click on a result to open the result in a new tab but leave the current page as-is (previous behavior both opened a new tab and changed the current tab's location to the result's).
I've done my best to keep the rest of the behavior and the appearance the same-- the whole row still highlights, still has a hand cursor, still moves to the result page with a normal click, arrows+enter still work. If the result is on the current page, the search is simply hidden.
The biggest difference in behavior is that people using tab to navigate through the links will have to hit tab twice for each row, since each cell has its own `a` tag.. I could fix this by switching to `div`s and `span`s instead of a table, but that's potentially more CSS finicky?
The biggest difference in appearance is probably that all the text in the search results is Fira Sans now, instead of just the method name with the rest of the text in Source Serif Pro. I can put this appearance back, but it looks like all links anywhere on the page are Fira Sans. Only the name was in an `a` tag before, but the whole row was ACTING like a link, so I think this is actually more consistent.
[I've pushed these changes to a gh-pages repo](https://carols10cents.github.io/rustdoc-playground/std/index.html?search=t) if you'd like to take a look at the effects; note that I also have my changes for PR #16735 there too so the search results will be sorted differently than on master.