There are no more poor hash functions left in the codebase, and it makes
sense to rely on there being a good hash function thanks to the
inclusion of SipHash and the ease of using it with custom types.
Closes#3041
Updated the rustc manpage based on the usage message for 0.6 (including -Z options). Also added an example showing how to compile with debug info.
This targets incoming rather than master. #4936 can be closed.
I removed the unused wrappers methods named `calloc` because they relied on the malloc wrapper having a `bool zero = true` default parameter (which resulted in some accidental zeroing). Perhaps wrapping the actual calloc function would be useful, but I don't know of an existing use case that could use it so I just removed these.
This gives an ~1% performance improvement for TreeMap, which does a lot of small allocations. Vectors use `realloc` which didn't zero before these changes so there's no measurable change in performance.
This is a natural extension of #4887, and handles the following three cases:
~~~~
a line with only /s
////////////////////////////////////////////
a line with only /s followed by whitespace
////////////////////////////////////////////
a block comment with only *s between two /s
/********************************/
~~~~
Using `noinline` causes a 3-10% hit in performance for most compiled Rust code. For the TreeMap it's ~15% and that's where I first noticed it.
Removing the noinline attribute doesn't slow down unoptimized builds, but it does significantly increase the time spent in LLVM passes for optimized builds. The improved speed of the compiler actually improves compile-times when optimization is off.
However, the reason for the increase is because more optimization is being done - I'm sure it would speed up compiles to mark *everything* with noinline, but it wouldn't be a good idea.
LLVM is clever enough with the inlining heuristics that this doesn't cause a notable increase in code size - some code becomes a bit bigger, some becomes a bit smaller. There are some cases where it's able to strip out a ton of code thanks to inlining.
I tried out `optsize` for glue code instead but it caused the same hit for LLVM passes in the compile time and the compiled code was a bit slower than just trusting LLVM to make the decisions.
* [TIME_PASSES=1 benchmarks](http://ompldr.org/vaGdxaA) (showing the performance increase in `rustc` and also the extra time spent in LLVM passes for more optimization)
