Auto merge of #28578 - gandro:nodefaultlibs, r=alexcrichton
This patch basically adds a target option for omitting the `-nodefaultlibs` flag when invoking the linker. I am not sure if this is the correct or only way to approach this problem, so any feedback is welcome.
Motivation: I'm currently working on a Rust target specification for the [rumprun](/rumpkernel/rumprun) unikernel. rumprun is based on rump kernels and uses NetBSDs libc and drivers to provide a POSIXy environment. It provides its own linker wrapper that generates binaries which can be "baked" into a unikernel after configuration. Using `-nodefaultlibs` on the rumprun linker will prevent it from selecting the search paths for the rumprun libraries. My current target implementation for rumprun is here: gandro/rust@295744b2ee2378f41a20d4b498b8f1991a75e93c
Currently, only a target that `is_like_windows` will omit the `-nodefaultlibs` flag, but since rumprun is not like Windows otherwise, I think a separate flag makes more sense. This might be a breaking change for target specifications that have the `is_like_windows` option set to true. Such targets need to set `no_default_libraries` to false in order to restore the old behavior.
Sebastian Wicki [Mon, 21 Sep 2015 17:02:46 +0000 (19:02 +0200)]
Add `no_default_libraries` target linker option
If set to false, `-nodefaultlibs` is not passed to the linker. This
was the default behavior on Windows, but it should be configurable
per target.
This is a [breaking-change] for target specifications that have
the `is_like_windows` option set to true. Such targets need to
set `no_default_libraries` to false in order to restore the old
behavior.
Auto merge of #28562 - llogiq:shootout, r=alexcrichton
Since 1.3.0 the BufWriter has seen tremendous speedups. So when I use it in the shootout benchmarks, I see some nice speedup (which up to 1.2.0 was nixed by the pessimizations during initialization).
Auto merge of #28531 - whitequark:patch-1, r=Gankro
With -O2, LLVM's inliner can remove this code, but this does not happen
with -O1 and lower. As a result, dropping Vec<u8> was linear with length,
resulting in abysmal performance for large buffers.
Auto merge of #28539 - rkruppe:shuffle-num-internals, r=alexcrichton
Move private bignum module to core::num, because it is not only used in flt2dec.
Extract private 80-bit soft-float into new core::num module for the same reason.
Auto merge of #28429 - wesleywiser:split_up_lints, r=alexcrichton
This breaks out some of the lints defined in `librustc_lint/builtin.rs` into two new modules: `unused` for the `UNUSED_*` lints and `bad_style` for the various style related lints as suggested in #22206. `builtin.rs` could probably get broken up more but this is a start.
Auto merge of #28501 - semarie:stdcpp-path, r=alexcrichton
By default, the linker in use under OpenBSD is the linker of base, which
don't include /usr/local/lib where libstdc++ of gcc-4.9 lives. We need
to add this directory to linker-path-search (using -L).
Search the path of libstdc++.a, which is a known name (libstdc++.so has
SO_VERSION) in the same directory.
r? @alexcrichton
this commit needs #28495 to be commited first. It should be the last piece for building rustc under OpenBSD from scratch.
Sébastien Marie [Fri, 18 Sep 2015 21:02:05 +0000 (23:02 +0200)]
Pass libstdc++.so path to linker under OpenBSD
By default, the linker in use under OpenBSD is the linker of base, which
don't include /usr/local/lib where libstdc++ of gcc-4.9 lives. We need
to add this directory to linker-path-search (using -L).
Search the path of libstdc++.a, which is a known name (libstdc++.so has
SO_VERSION) in the same directory.
Robin Kruppe [Sun, 20 Sep 2015 16:34:33 +0000 (18:34 +0200)]
Reorganize core::num internals
Move private bignum module to core::num, because it is not only used in flt2dec.
Extract private 80-bit soft-float into new core::num module for the same reason.
Do not drop_in_place elements of Vec<T> if T doesn't need dropping
With -O2, LLVM's inliner can remove this code, but this does not happen
with -O1 and lower. As a result, dropping Vec<u8> was linear with length,
resulting in abysmal performance for large buffers.
Auto merge of #28519 - wthrowe:fixup-28321, r=alexcrichton
I assume the expected error changed during the development of pull
request #28321 and that wasn't noticed because the test was
accidentally not running.
William Throwe [Sat, 19 Sep 2015 16:49:56 +0000 (12:49 -0400)]
Move test to the right directory and make it pass
I assume the expected error changed during the development of pull
request #28321 and that wasn't noticed because the test was
accidentally not running.
Auto merge of #28497 - apasel422:issue-28493, r=Gankro
When both the key and value types were zero-sized, `BTreeMap` previously
called `heap::allocate` with `size == 0` for leaf nodes, which is
undefined behavior, and jemalloc would attempt to read invalid memory,
crashing the process.
This avoids undefined behavior by allocating enough space to store one
edge in leaf nodes that would otherwise have `size == 0`. Although this
uses extra memory, maps with zero-sized key types that have sensible
implementations of the ordering traits can only contain a single
key-value pair (and therefore only a single leaf node), and maps with
key and value types that are both zero-sized have few uses, if any.
Furthermore, this is a temporary fix that will likely be unnecessary
once the `BTreeMap` implementation is rewritten to use parent pointers.
Steve Klabnik [Sat, 19 Sep 2015 15:15:48 +0000 (11:15 -0400)]
Rollup merge of #28485 - Wallacoloo:clarify-let-lhs, r=alexcrichton
In code like `let x = 5`, I am initially confused as to the meaning of "let doesn't take a name on the left hand side, it actually accepts a pattern." - I interpret that as the pattern being located as: `<pattern> let [...]`.
I think what is meant is that the name/pattern is on the left hand side *of the assignment*, rather than to the left of the *let* statement. This change clarifies that.
Steve Klabnik [Sat, 19 Sep 2015 15:15:47 +0000 (11:15 -0400)]
Rollup merge of #28400 - badboy:disable-browser-history-on-file, r=steveklabnik
history.pushState is defined, but not working whenever document.origin is "null"
(literally that string, not just the null object).
This is due to some security considerations and is unlikely to be ever working.
For now just disable the usage of the history API when the documentation
is accessed through a file:/// URL.
See https://code.google.com/p/chromium/issues/detail?id=301210 for a
Chrome-specific issue on the history API on file:/// URLs
Auto merge of #28495 - semarie:stdcpp-name, r=alexcrichton
it makes rustc compatible with gcc installation that are using
`--program-transform-name' configure flag (on OpenBSD for example).
- detects at configure the name of stdc++ library on the system
- use the detected name in llvm makefile (with enable-static-stdcpp),
and pass it to mklldeps.py
- generate mklldeps.rs using this detected name
note that CFG_STDCPP_NAME is about stdc++ name, not about libc++. If
using libc++, the default name will be `stdc++', but it won't be used
when linking.
r? @alexcrichton
I added this support globally instead of just for OpenBSD as it isn't specially related to OpenBSD (except OpenBSD use it for gcc-4.9). And as I would had to change `llvm.mk', having just a default value in `configure' for others platforms won't be very useful.
Auto merge of #28491 - dotdash:noadjust, r=nikomatsakis
That allows us to keep using trans_into() in case of adjustments that
may actually be ignored in trans because they are a plain deref/ref pair
with no overloaded deref or unsizing.
Unoptimized(!) benchmarks from servo/servo#7638
Before
```
test goser::bench_clone ... bench: 17,701 ns/iter (+/- 58) = 30 MB/s
test goser::bincode::bench_decoder ... bench: 33,715 ns/iter (+/- 300) = 11 MB/s
test goser::bincode::bench_deserialize ... bench: 36,804 ns/iter (+/- 329) = 9 MB/s
test goser::bincode::bench_encoder ... bench: 34,695 ns/iter (+/- 149) = 11 MB/s
test goser::bincode::bench_populate ... bench: 18,879 ns/iter (+/- 88)
test goser::bincode::bench_serialize ... bench: 31,668 ns/iter (+/- 156) = 11 MB/s
test goser::capnp::bench_deserialize ... bench: 2,049 ns/iter (+/- 87) = 218 MB/s
test goser::capnp::bench_deserialize_packed ... bench: 10,707 ns/iter (+/- 258) = 31 MB/s
test goser::capnp::bench_populate ... bench: 635 ns/iter (+/- 5)
test goser::capnp::bench_serialize ... bench: 35,657 ns/iter (+/- 155) = 12 MB/s
test goser::capnp::bench_serialize_packed ... bench: 37,881 ns/iter (+/- 146) = 8 MB/s
test goser::msgpack::bench_decoder ... bench: 50,634 ns/iter (+/- 307) = 5 MB/s
test goser::msgpack::bench_encoder ... bench: 25,738 ns/iter (+/- 90) = 11 MB/s
test goser::msgpack::bench_populate ... bench: 18,900 ns/iter (+/- 138)
test goser::protobuf::bench_decoder ... bench: 2,791 ns/iter (+/- 29) = 102 MB/s
test goser::protobuf::bench_encoder ... bench: 75,414 ns/iter (+/- 358) = 3 MB/s
test goser::protobuf::bench_populate ... bench: 19,248 ns/iter (+/- 92)
test goser::rustc_serialize_json::bench_decoder ... bench: 109,999 ns/iter (+/- 797) = 5 MB/s
test goser::rustc_serialize_json::bench_encoder ... bench: 58,777 ns/iter (+/- 418) = 10 MB/s
test goser::rustc_serialize_json::bench_populate ... bench: 18,887 ns/iter (+/- 76)
test goser::serde_json::bench_deserializer ... bench: 104,803 ns/iter (+/- 770) = 5 MB/s
test goser::serde_json::bench_populate ... bench: 18,890 ns/iter (+/- 69)
test goser::serde_json::bench_serializer ... bench: 75,046 ns/iter (+/- 435) = 8 MB/s
```
After
```
test goser::bench_clone ... bench: 16,052 ns/iter (+/- 188) = 34 MB/s
test goser::bincode::bench_decoder ... bench: 31,194 ns/iter (+/- 941) = 12 MB/s
test goser::bincode::bench_deserialize ... bench: 33,934 ns/iter (+/- 352) = 10 MB/s
test goser::bincode::bench_encoder ... bench: 30,737 ns/iter (+/- 1,969) = 13 MB/s
test goser::bincode::bench_populate ... bench: 17,234 ns/iter (+/- 176)
test goser::bincode::bench_serialize ... bench: 28,269 ns/iter (+/- 452) = 12 MB/s
test goser::capnp::bench_deserialize ... bench: 2,019 ns/iter (+/- 85) = 221 MB/s
test goser::capnp::bench_deserialize_packed ... bench: 10,662 ns/iter (+/- 527) = 31 MB/s
test goser::capnp::bench_populate ... bench: 607 ns/iter (+/- 2)
test goser::capnp::bench_serialize ... bench: 30,488 ns/iter (+/- 219) = 14 MB/s
test goser::capnp::bench_serialize_packed ... bench: 33,731 ns/iter (+/- 201) = 9 MB/s
test goser::msgpack::bench_decoder ... bench: 46,921 ns/iter (+/- 461) = 6 MB/s
test goser::msgpack::bench_encoder ... bench: 22,315 ns/iter (+/- 96) = 12 MB/s
test goser::msgpack::bench_populate ... bench: 17,268 ns/iter (+/- 73)
test goser::protobuf::bench_decoder ... bench: 2,658 ns/iter (+/- 44) = 107 MB/s
test goser::protobuf::bench_encoder ... bench: 71,024 ns/iter (+/- 359) = 4 MB/s
test goser::protobuf::bench_populate ... bench: 17,704 ns/iter (+/- 104)
test goser::rustc_serialize_json::bench_decoder ... bench: 107,867 ns/iter (+/- 759) = 5 MB/s
test goser::rustc_serialize_json::bench_encoder ... bench: 52,327 ns/iter (+/- 479) = 11 MB/s
test goser::rustc_serialize_json::bench_populate ... bench: 17,262 ns/iter (+/- 68)
test goser::serde_json::bench_deserializer ... bench: 99,156 ns/iter (+/- 657) = 6 MB/s
test goser::serde_json::bench_populate ... bench: 17,264 ns/iter (+/- 77)
test goser::serde_json::bench_serializer ... bench: 66,135 ns/iter (+/- 392) = 9 MB/s
projects / rust.git / log