Commit Graph

59232 Commits

Author SHA1 Message Date
Corey Farwell
8916accc10 Rollup merge of #37919 - nikomatsakis:incremental-36168, r=mw
add regression test for #36168

Fixes #36168

r? @michaelwoerister
2016-12-03 15:39:51 -05:00
Corey Farwell
bf99183f87 Rollup merge of #37859 - GuillaumeGomez:net_examples, r=nagisa
Add missing examples for Ipv6Addr

r? @steveklabnik

cc @frewsxcv
2016-12-03 15:39:51 -05:00
Niko Matsakis
f8097066f8 move test for #37290 into run-pass-fulldeps 2016-12-03 14:42:34 -05:00
Mikhail Modin
b8d8ab87c0 fix stack overflow by enum and cont issue #36163, some paths were skipped while checking for recursion. 2016-12-03 21:26:30 +03:00
Sébastien Marie
53ebf5a0a7 update src/liblibc to include i686-unknown-openbsd libc definition 2016-12-03 18:57:58 +01:00
bors
2cdbd5eb42 Auto merge of #38079 - BurntSushi:attrtarget, r=alexcrichton
Add new #[target_feature = "..."] attribute.

This commit adds a new attribute that instructs the compiler to emit
target specific code for a single function. For example, the following
function is permitted to use instructions that are part of SSE 4.2:

    #[target_feature = "+sse4.2"]
    fn foo() { ... }

In particular, use of this attribute does not require setting the
-C target-feature or -C target-cpu options on rustc.

This attribute does not have any protections built into it. For example,
nothing stops one from calling the above `foo` function on hosts without
SSE 4.2 support. Doing so may result in a SIGILL.

I've also expanded the x86 target feature whitelist.
2016-12-03 17:41:14 +00:00
bors
890085450a Auto merge of #38061 - cardoe:target-spec, r=alexcrichton
print option to dump target spec as JSON

This lets the user dump out the target spec that the compiler is using. This is useful to people defining their own target.json to compare it against existing targets or understand how different targets change internal settings. It is also potentially useful for Cargo to determine if something has changed with a target and it needs to rebuild things.
2016-12-03 14:21:51 +00:00
bors
9a101d8987 Auto merge of #38059 - arielb1:no-mere-overflow, r=nikomatsakis
evaluate obligations in LIFO order during closure projection

This is an annoying gotcha with the projection cache's handling of
nested obligations.

Nested projection obligations enter the issue in this case:
```
DEBUG:rustc::traits::project: AssociatedTypeNormalizer: depth=3
normalized
<std::iter::Map<std::ops::Range<i32>,
[closure@not-a-recursion-error.rs:5:30: 5:53]> as
std::iter::IntoIterator>::Item to _#7t with 12 add'l obligations
```

Here the normalization result is the result of the nested impl
`<[closure@not-a-recursion-error.rs:5:30: 5:53] as FnMut(i32)>::Output`,
which is an additional obligation that is a part of "add'l obligations".

By itself, this is proper behaviour - the additional obligation is
returned, and the RFC 447 rules ensure that it is processed before the
output `#_7t` is used in any way.

However, the projection cache breaks this - it caches the
`<std::iter::Map<std::ops::Range<i32>,[closure@not-a-recursion-error.rs:5:30:
5:53]> as std::iter::IntoIterator>::Item = #_7t` resolution. Now
everybody else that attempts to look up the projection will just get
`#_7t` *without* any additional obligations. This obviously causes all
sorts of trouble (here a spurious `EvaluatedToAmbig` results in
specializations not being discarded
[here](9ca50bd4d5/src/librustc/traits/select.rs (L1705))).

The compiler works even with this projection cache gotcha because in most
cases during "one-pass evaluation". we tend to process obligations in LIFO
order - after an obligation is added to the cache, we process its nested
obligations before we do anything else (and if we have a cycle, we handle
it specifically) - which makes sure the inference variables are resolved
before they are used.

That "LIFO" order That was not done when projecting out of a closure, so
let's just fix that for the time being.

Fixes #38033.

Beta-nominating because regression.

r? @nikomatsakis
2016-12-03 11:04:01 +00:00
bors
24175e8c9f Auto merge of #38056 - clarcharr:master, r=alexcrichton
Add String::split_off.

This seems to match up with the latest version of the collection reform, and seems useful enough to add. First pull request!
2016-12-03 07:52:21 +00:00
Guillaume Gomez
60d1660748 Add Component examples 2016-12-02 20:16:12 -08:00
bors
08faff49c3 Auto merge of #38055 - rkruppe:rm-unused-llvm-ffi, r=alexcrichton
Remove unused functions from rustc_llvm
2016-12-03 03:57:57 +00:00
Jake Goulding
757a9cea3f [LLVM 4.0] Support new DIFlags enum 2016-12-02 21:14:06 -05:00
Jake Goulding
dbdd60e6d7 [LLVM] Introduce a stable representation of DIFlags
In LLVM 4.0, this enum becomes an actual type-safe enum, which breaks
all of the interfaces. Introduce our own copy of the bitflags that we
can then safely convert to the LLVM one.
2016-12-02 21:13:31 -05:00
Vadim Chugunov
923034ffd2 Rename _all_ library instances. 2016-12-02 17:51:54 -08:00
Niko Matsakis
0adb1b1b02 pacify the mercilous tidy 2016-12-02 14:18:09 -05:00
Doug Goldstein
f83eb4009e
configure: quote variables
These should probably be quoted.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
2016-12-02 11:25:43 -06:00
Doug Goldstein
e39c8d6dc8
configure: only req CMake if we're building LLVM
CMake is only necessary if LLVM is going to be built and not in any
other case.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
2016-12-02 11:22:57 -06:00
jethrogb
ecf6f1b96a Update items section in reference
Make clear that items must be definitions, and add missing extern block
2016-12-02 09:19:38 -08:00
Doug Goldstein
7151b5ad78
rustc: add basic test for --print target-spec
This is a very basic test of the --print target-spec feature.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
2016-12-02 10:07:39 -06:00
Doug Goldstein
ff112644de
rustc: add --print target-spec option
This option provides the user the ability to dump the configuration that
is in use by rustc for the target they are building for.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
2016-12-02 10:07:38 -06:00
bors
c80c31a502 Auto merge of #38053 - eddyb:lazy-9, r=nikomatsakis
[9/n] rustc: move type information out of AdtDef and TraitDef.

_This is part of a series ([prev](https://github.com/rust-lang/rust/pull/37688) | [next]()) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. [MIR-based](https://github.com/solson/miri) early constant evaluation) and incremental execution of compiler passes (e.g. type-checking), with beneficial consequences to IDE support as well.
If any motivation is unclear, please ask for additional PR description clarifications or code comments._

<hr>

Both `AdtDef` and `TraitDef` contained type information (field types, generics and predicates) which was required to create them, preventing their use before that type information exists, or in the case of field types, *mutation* was required, leading to a variance-magicking implementation of `ivar`s.

This PR takes that information out and the resulting cleaner setup could even eventually end up merged with HIR, because, just like `AssociatedItem` before it, there's no dependency on types anymore.
(With one exception, variant discriminants should probably be moved into their own map later.)
2016-12-02 15:06:36 +00:00
bors
2f8fd533ac Auto merge of #38050 - alexcrichton:fix-llvm-deps, r=japaric
rustbuild: Cross-compiled LLVM depens on host

We use the host's tblgen so we need to be sure to always build the host first.

Closes #38037
2016-12-02 11:35:57 +00:00
bors
af0a0719ea Auto merge of #37936 - tedsta:fuchsia_std_process, r=alexcrichton
Fuchsia support for std::process via liblaunchpad.

Now we can launch processes on Fuchsia via the Rust standard library! ... Mostly.

Right now, ~5% of the time, reading the stdout/stderr off the pipes will fail. Some Magenta kernel people think it's probably a bug in Magenta's pipes. I wrote a unit test that demonstrates the issue in C, which I was told will expedite a fix. https://fuchsia-review.googlesource.com/#/c/15628/

Hopefully this can get merged once the issue is fixed :)

@raphlinus
2016-12-02 07:35:06 +00:00
Vadim Chugunov
a23c470433 Tighten up error checking of library renames. 2016-12-01 16:56:49 -08:00
Vadim Chugunov
a9a6f8c8ed Remove the "linked_from" feature. 2016-12-01 16:56:49 -08:00
Jonathan Turner
c735d7f2a5 Point arg num mismatch errors back to their definition 2016-12-01 16:33:48 -08:00
Vadim Chugunov
13477c77bf Implement native library kind and name overrides from the command line. 2016-12-01 16:22:04 -08:00
Vadim Chugunov
4508e8a847 Fix rust_test_helpers linkage. 2016-12-01 16:22:04 -08:00
Vadim Chugunov
bc019dfb39 Emit 'dllimport' attribute for dylib foreign items on Windows. 2016-12-01 16:22:04 -08:00
bors
1077149827 Auto merge of #37789 - arielb1:length-limit, r=nikomatsakis
limit the length of types in monomorphization

This adds the new insta-stable `#![type_size_limit]` crate attribute to control
the limit, and is obviously a [breaking-change] fixable by that.

Fixes #37311.

r? @nikomatsakis
2016-12-02 00:20:11 +00:00
Doug Goldstein
8285ab5c99
convert --print options to a vector
To allow manipulation of the options that appear in --print, convert it
to a vector.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
2016-12-01 16:59:09 -06:00
Ariel Ben-Yehuda
242cd7ebe2 limit the length of types in monomorphization
This adds the new insta-stable `#![type_size_limit]` crate attribute to control
the limit, and is obviously a [breaking-change] fixable by that.
2016-12-02 00:54:22 +02:00
Theodore DeRego
e1b752b2a1 std::process fuchsia support cleanup 2016-12-01 12:01:07 -08:00
Niko Matsakis
6fe4bffb40 test for #37290 using lint 2016-12-01 13:59:07 -05:00
Niko Matsakis
fa22fc387a in region, treat current (and future) item-likes alike
The `visit_fn` code mutates its surrounding context.  Between *items*,
this was saved/restored, but between impl items it was not. This meant
that we wound up with `CallSiteScope` entries with two parents (or
more!).  As far as I can tell, this is harmless in actual type-checking,
since the regions you interact with are always from at most one of those
branches. But it can slow things down.

Before, the effect was limited, since it only applied to impl items
within an impl. After #37660, impl items are visisted all together at
the end, and hence this could create a very messed up
hierarchy. Isolating impl item properly solves both issues.

I cannot come up with a way to unit-test this; for posterity, however,
you can observe the messed up hierarchies with a test as simple as the
following, which would create a callsite scope with two parents both
before and after

```
struct Foo {
}

impl Foo {
    fn bar(&self) -> usize {
        22
    }

    fn baz(&self) -> usize {
        22
    }
}

fn main() { }
```

Fixes #37864.
2016-12-01 13:59:04 -05:00
Jorge Aparicio
acad8cceb7 don't rebuild alloc_jemalloc if jemalloc's .git directory has changed
the .git directory is modified by `bootstrap` when it updates this git
submodule; this triggered rebuilds every time `bootstrap` was called.

likely fixes #38094
2016-12-01 13:17:01 -05:00
Niko Matsakis
57ffda6158 add a -Z incremental-dump-hash flag
This causes us to dump a bunch of has information to stdout that can be
useful in tracking down incremental compilation invalidations,
particularly across crates.
2016-12-01 12:29:28 -05:00
Steve Smith
d950ca175a Minor fix to testing concurrency section 2016-12-01 16:30:34 +00:00
bors
908dba0c94 Auto merge of #38048 - rkruppe:llvm-stringref-fixes, r=alexcrichton
[LLVM 4.0] Don't assume llvm::StringRef is null terminated

StringRefs have a length and their contents are not usually null-terminated. The solution is to either copy the string data (in `rustc_llvm::diagnostic`) or take the size into account (in LLVMRustPrintPasses).

I couldn't trigger a bug caused by this (apparently all the strings returned in practice are actually null-terminated) but this is more correct and more future-proof.

cc #37609
2016-12-01 15:21:11 +00:00
Josh Driver
bfdd2d4177 Allow --test to be used on proc-macro crates 2016-12-02 00:12:20 +10:30
bors
149e76f12c Auto merge of #38018 - sourcefrog:doc, r=alexcrichton
Document that Process::command will search the PATH
2016-12-01 11:35:19 +00:00
Anthony Ramine
ee83f365ee Update llvm fork to 3ec14daffb4b8c0604df50b7fb0ab552f456e381 2016-12-01 11:18:40 +01:00
bors
827eba4e70 Auto merge of #37911 - liigo:rustdoc-playground, r=alexcrichton
rustdoc: get back missing crate-name when --playground-url is used

follow up PR #37763
r? @alexcrichton (since you r+ed to #37763 )

----

Edit: When `#![doc(html_playground_url="")]` is used, the current crate name is saved to `PLAYGROUND`, so rustdoc may generate `extern crate NAME;` into code snips automatically. But when `--playground-url` was introduced in PR #37763, I forgot saving crate name to `PLAYGROUND`. This PR fix that.

----

Update:
- add test
- unstable `--playground-url`
2016-12-01 07:07:32 +00:00
Clar Charr
cbf734f9ab Add String::split_off. 2016-11-30 23:24:57 -05:00
bors
070fad1701 Auto merge of #37573 - ruuda:faster-cursor, r=alexcrichton
Add small-copy optimization for copy_from_slice

## Summary

During benchmarking, I found that one of my programs spent between 5 and 10 percent of the time doing memmoves. Ultimately I tracked these down to single-byte slices being copied with a memcopy. Doing a manual copy if the slice contains only one element can speed things up significantly. For my program, this reduced the running time by 20%.

## Background

I am optimizing a program that relies heavily on reading a single byte at a time. To avoid IO overhead, I read all data into a vector once, and then I use a `Cursor` around that vector to read from. During profiling, I noticed that `__memmove_avx_unaligned_erms` was hot, taking up 7.3% of the running time. It turns out that these were caused by calls to `Cursor::read()`, which calls `<&[u8] as Read>::read()`, which calls `&[T]::copy_from_slice()`, which calls `ptr::copy_nonoverlapping()`. This one is implemented as a memcopy. Copying a single byte with a memcopy is very wasteful, because (at least on my platform) it involves calling `memcpy` in libc. This is an indirect call when libc is linked dynamically, and furthermore `memcpy` is optimized for copying large amounts of data at the cost of a bit of overhead for small copies.

## Benchmarks

Before I made this change, `perf` reported the following for my program. I only included the relevant functions, and how they rank. (This is on a different machine than where I ran the original benchmarks. It has an older CPU, so `__memmove_sse2_unaligned_erms` is called instead of `__memmove_avx_unaligned_erms`.)

```
#3   5.47%  bench_decode  libc-2.24.so      [.] __memmove_sse2_unaligned_erms
#5   1.67%  bench_decode  libc-2.24.so      [.] memcpy@GLIBC_2.2.5
#6   1.51%  bench_decode  bench_decode      [.] memcpy@plt
```

`memcpy` is eating up 8.65% of the total running time, and the overhead of dispatching to a specialized fast copy function (`memcpy@GLIBC` showing up) is clearly visible. The price of dynamic linking (`memcpy@plt` showing up) is visible too.

After this change, this is what `perf` reports:

```
#5   0.33%  bench_decode  libc-2.24.so      [.] __memmove_sse2_unaligned_erms
#14  0.01%  bench_decode  libc-2.24.so      [.] memcpy@GLIBC_2.2.5
```

Now only 0.34% of the running time is spent on memcopies. The dynamic linking overhead is not significant at all any more.

To add some more data, my program generates timing results for the operation in its main loop. These are the timings before and after the change:

| Time before   | Time after    | After/Before |
|---------------|---------------|--------------|
| 29.8 ± 0.8 ns | 23.6 ± 0.5 ns |  0.79 ± 0.03 |

The time is basically the total running time divided by a constant; the actual numbers are not important. This change reduced the total running time by 21% (much more than the original 9% spent on memmoves, likely because the CPU is stalling a lot less because data dependencies are more transparent). Of course YMMV and for most programs this will not matter at all. But when it does, the gains can be significant!

## Alternatives

* At first I implemented this in `io::Cursor`. I moved it to `&[T]::copy_from_slice()` instead, but this might be too intrusive, especially because it applies to all `T`, not just `u8`. To restrict this to `io::Read`, `<&[u8] as Read>::read()` is probably the best place.
* I tried copying bytes in a loop up to 64 or 8 bytes before calling `Read::read`, but both resulted in about a 20% slowdown instead of speedup.
2016-12-01 02:52:09 +00:00
Ted Mielczarek
e6975e9748 just add one method named creation_flags, fix the tidy error 2016-11-30 21:31:47 -05:00
Martin Pool
db93677360 Document that Process::command will search the PATH 2016-11-30 17:10:32 -08:00
Ted Mielczarek
8b1c4cbbaf Add std::os::windows::process::CommandExt, with set_creation_flags and add_creation_flags methods. Fixes #37827
This adds a CommandExt trait for Windows along with an implementation of it
for std::process::Command with methods to set the process creation flags that
are passed to CreateProcess.
2016-11-30 19:44:07 -05:00
bors
dc81742b18 Auto merge of #38047 - canndrew:fmt-void-non-empty, r=bluss
Make core::fmt::Void a non-empty type.

Adding back this change that was removed from PR #36449 because it's a fix and because I immediately hit a problem with it again when I started implementing my fix for #12609.
2016-11-30 23:40:10 +00:00
Jeffrey Seyfried
ff621ec70e Add tests. 2016-11-30 23:17:56 +00:00