Scott McMurray [Fri, 23 Mar 2018 08:30:23 +0000 (01:30 -0700)]
Introduce unsafe offset_from on pointers
Adds intrinsics::exact_div to take advantage of the unsafe, which reduces the implementation from
```asm
sub rcx, rdx
mov rax, rcx
sar rax, 63
shr rax, 62
lea rax, [rax + rcx]
sar rax, 2
ret
```
down to
```asm
sub rcx, rdx
sar rcx, 2
mov rax, rcx
ret
```
(for `*const i32`)
Alex Crichton [Thu, 22 Mar 2018 20:39:52 +0000 (13:39 -0700)]
ci: Don't use Travis caches for docker images
This commit moves away from caching on Travis to our own caching on S3 for
caching docker layers between builds. Unfortunately the Travis caches have over
time had a few critical pain points:
* Caches are only updated for successful builds, meaning that if a build times
out or fails in a different location the sucessfully-created docker images
isn't always cached. While this makes sense as a general rule of caches it
hurts our use cases.
* Caches are per-branch and builder which means that we don't have a separate
cache on each release channel. All our merges go through the `auto` branch
which means that they're all sharing the same cache, even those for merging to
master/beta. This means that PRs which switch between master/beta will keep
rebuilting and having cache misses.
* Caches have historically been invaliated somewhat regularly a little more
aggressively than we'd want (I think).
* We don't always need to update the contents of the cache if the Docker image
didn't change at all, and saving off the docker layers can sometimes be quite
expensive.
For all these reasons this commit drops the usage of Travis's built-in caching
support. Instead our own caching is used by storing blobs to S3. Normally this
would be a very risky endeavour but we're basically priming a cache for a cache
(docker) so if we get this wrong the failure mode is longer builds, not stale
caches. We'll notice that pretty quickly and hopefully fix it!
The logic here is inserted directly into the `src/ci/docker/run.sh` script to
download an image based on a shasum of the `Dockerfile` and other assorted files.
This blob, if found, is loaded into docker and we record what layers were
inserted. After docker finishes the build (hopefully quickly with lots of cache
hits) we then see the sha of the final image. If it's one of the layers we
loaded then there's no need to update the cache. Otherwise we upload our layers
to the global cache, possibly overwriting what we previously just downloaded.
This is hopefully a step towards mitigating #49278 although it doesn't
completely fix it as it means we'll still probably have to retry builds that
bust the cache.
Josh Stone [Fri, 23 Mar 2018 01:31:32 +0000 (18:31 -0700)]
Allow installing rustfmt without config.extended
This assertion was preventing `./x.py install rustfmt` if attempted
without an "extended" build configuration, but it actually builds and
installs just fine.
David Wood [Thu, 15 Mar 2018 18:49:10 +0000 (18:49 +0000)]
UserAssertTy can handle inference variables.
This commit modifies the UserAssertTy statement to take a canonicalized
type rather than a regular type so that we can handle the case where the
user provided type contains a inference variable.
Alex Crichton [Sat, 10 Feb 2018 22:28:17 +0000 (14:28 -0800)]
rustc: Add a `#[wasm_import_module]` attribute
This commit adds a new attribute to the Rust compiler specific to the wasm
target (and no other targets). The `#[wasm_import_module]` attribute is used to
specify the module that a name is imported from, and is used like so:
Here the import of the symbol `some_js_function` is tagged with the `./foo.js`
module in the wasm output file. Wasm-the-format includes two fields on all
imports, a module and a field. The field is the symbol name (`some_js_function`
above) and the module has historically unconditionally been `"env"`. I'm not
sure if this `"env"` convention has asm.js or LLVM roots, but regardless we'd
like the ability to configure it!
The proposed ES module integration with wasm (aka a wasm module is "just another
ES module") requires that the import module of wasm imports is interpreted as an
ES module import, meaning that you'll need to encode paths, NPM packages, etc.
As a result, we'll need this to be something other than `"env"`!
Unfortunately neither our version of LLVM nor LLD supports custom import modules
(aka anything not `"env"`). My hope is that by the time LLVM 7 is released both
will have support, but in the meantime this commit adds some primitive
encoding/decoding of wasm files to the compiler. This way rustc postprocesses
the wasm module that LLVM emits to ensure it's got all the imports we'd like to
have in it.
Eventually I'd ideally like to unconditionally require this attribute to be
placed on all `extern { ... }` blocks. For now though it seemed prudent to add
it as an unstable attribute, so for now it's not required (as that'd force usage
of a feature gate). Hopefully it doesn't take too long to "stabilize" this!
Alex Crichton [Fri, 9 Mar 2018 17:26:15 +0000 (09:26 -0800)]
rustc: Add a `#[wasm_custom_section]` attribute
This commit is an implementation of adding custom sections to wasm artifacts in
rustc. The intention here is to expose the ability of the wasm binary format to
contain custom sections with arbitrary user-defined data. Currently neither our
version of LLVM nor LLD supports this so the implementation is currently custom
to rustc itself.
The implementation here is to attach a `#[wasm_custom_section = "foo"]`
attribute to any `const` which has a type like `[u8; N]`. Other types of
constants aren't supported yet but may be added one day! This should hopefully
be enough to get off the ground with *some* custom section support.
The current semantics are that any constant tagged with `#[wasm_custom_section]`
section will be *appended* to the corresponding section in the final output wasm
artifact (and this affects dependencies linked in as well, not just the final
crate). This means that whatever is interpreting the contents must be able to
interpret binary-concatenated sections (or each constant needs to be in its own
custom section).
To test this change the existing `run-make` test suite was moved to a
`run-make-fulldeps` folder and a new `run-make` test suite was added which
applies to all targets by default. This test suite currently only has one test
which only runs for the wasm target (using a node.js script to use `WebAssembly`
in JS to parse the wasm output).
kennytm [Thu, 22 Mar 2018 09:51:38 +0000 (17:51 +0800)]
Rollup merge of #49234 - kennytm:revert-fix-dpl-788, r=alexcrichton
dpl 1.9.5 has been released, revert #49217.
dpl 1.9.5 has been released which includes travis-ci/dpl#789, so we could move back to the standard Travis settings before that `s3-eager-autoload` branch is removed.
kennytm [Thu, 22 Mar 2018 09:51:37 +0000 (17:51 +0800)]
Rollup merge of #49231 - gnzlbg:fix_vec_fminmax, r=rkruppe
fix vector fmin/fmax non-fast/fast intrinsics NaN handling
This bugs shows up in release mode tests of `stdsimd`: https://github.com/rust-lang-nursery/stdsimd/pull/391 . The intrinsics are thoroughly tested there for roundoff errors, NaN, and overflow behavior.
The problem was that the non-fast intrinsics where specifying `NoNaNs == true`, which meant that they don't support NaNs. This is incorrect, the non-fast intrinsics should handle NaNs properly.
Also, the "fast" intrinsics where specifying `NoNaNs == false` which meant that they support NaNs and then fast-math, which probably disables this support. This was not intended either.
I've added a comment specifying what the boolean flags do.
kennytm [Thu, 22 Mar 2018 09:51:36 +0000 (17:51 +0800)]
Rollup merge of #49225 - QuietMisdreavus:all-the-features-all-the-time, r=alexcrichton
whitelist every target feature for rustdoc
When https://github.com/rust-lang-nursery/stdsimd/pull/367 was attempted to be upstreamed, it failed to document on non-x86 targets because it made every intrinsic visible, even the ones on foreign arches. This change makes it so that whenever rustdoc asks for the target feature whitelist, it gets a list of every feature known to every arch in `rustc_trans/llvm_util.rs`.
Before pushing, i temporarily updated the `stdsimd` submodule to include the `doc(cfg)` change, generated documentation for `aarch64-unknown-linux-gnu`, and it completed without a problem. The generated `core::arch` docs contained complete submodules for all main arches.
kennytm [Thu, 22 Mar 2018 09:51:35 +0000 (17:51 +0800)]
Rollup merge of #49216 - bjorn3:patch-1, r=estebank
Don't check interpret_interner when accessing a static to fix miri mutable statics
Mutable statics don't work in my PR to fix the standalone [miri](https://github.com/solson/miri), as init_static didn't get called when the interpret_interner already contained a entry for the static, which is always immutable.
kennytm [Thu, 22 Mar 2018 09:51:27 +0000 (17:51 +0800)]
Rollup merge of #49158 - varkor:compiletest-triples, r=rkruppe
Make compiletest do exact matching on triples
This avoids the issues of the previous substring matching, ensuring `ARCH_TABLE` and `OS_TABLE` will no longer contain redundant entries. Fixes #48893.
kennytm [Thu, 22 Mar 2018 09:51:21 +0000 (17:51 +0800)]
Rollup merge of #49069 - wesleywiser:incr_soa, r=michaelwoerister
Convert SerializedDepGraph to be a struct-of-arrays
Fixes #47326
I did not try the "`mem::swap()` to avoid copying the arrays" idea because that would leave the DepGraph in an incorrect state and that doesn't seem like a good idea for me.
Sébastien Marie [Thu, 22 Mar 2018 10:27:59 +0000 (11:27 +0100)]
Use GNU version of fgrep/egrep tool if available
It is mostly for BSD system. Some tests (run-make/issue-35164 and
run-make/cat-and-grep-sanity-check) are failing with BSD
fgrep, whereas they pass with gnu version (gfgrep).
kennytm [Thu, 22 Mar 2018 09:51:16 +0000 (17:51 +0800)]
Rollup merge of #48759 - QuietMisdreavus:simd-feature-docs, r=GuillaumeGomez
rustdoc: expose #[target_feature] attributes as doc(cfg) flags
This change exposes `#[target_feature(enable = "feat")]` attributes on an item as if they were also `#[doc(cfg(target_feature = "feat"))]` attributes. This gives them a banner on their documentation listing which feature is required to use the item. It also modifies the rendering code for doc(cfg) tags to handle `target_feature` tags. I made it print just the feature name on "short" printings (as in the function listing on a module page), and use "target feature `feat`" in the full banner on the item page itself.
This way, the function listing in `std::arch` shows which feature is required for each function:
bors [Thu, 22 Mar 2018 09:46:06 +0000 (09:46 +0000)]
Auto merge of #49094 - alexcrichton:print-step-duration, r=kennytm
ci: Print out how long each step takes on CI
This commit updates CI configuration to inform rustbuild that it should print
out how long each step takes on CI. This'll hopefully allow us to track the
duration of steps over time and follow regressions a bit more closesly (as well
as have closer analysis of differences between two builds).
bors [Thu, 22 Mar 2018 06:56:16 +0000 (06:56 +0000)]
Auto merge of #49041 - nikomatsakis:issue-46541-impl-trait-hidden-lifetimes, r=cramertj
Detect illegal hidden lifetimes in `impl Trait`
This branch fixes #46541 -- however, it presently doesn't build because it also *breaks* a number of existing usages of impl Trait. I'm opening it as a WIP for now, just because we want to move on impl Trait, but I'll try to fix the problem in a bit.
~~(The problem is due to the fact that we apparently infer stricter lifetimes in closures that we need to; for example, if you capture a variable of type `&'a &'b u32`, we will put *precisely* those lifetimes into the closure, even if the closure would be happy with `&'a &'a u32`. This causes the present chance to affect things that are not invariant.)~~ fixed
bors [Thu, 22 Mar 2018 01:54:51 +0000 (01:54 +0000)]
Auto merge of #49246 - kennytm:download-gcc-stuff-from-https, r=alexcrichton
Download the GCC artifacts from the HTTP server instead of FTP server.
Try to bring back the `dist-i686-linux` and `dist-x86_64-linux alt` builders which has mysteriously lost their cache 14 hours ago and stuck forever unable to download `mpfr-2.4.2.tar.bz2` since it keeps getting
```
==> PASV ... couldn't connect to 209.132.180.131 port 10058: Connection timed out
```
kennytm [Thu, 22 Mar 2018 01:02:51 +0000 (09:02 +0800)]
Temporarily disable dist-ing RLS, Rustfmt and Clippy.
Unfortunately we don't have sufficient time to rebuild the cache *and*
distribute everything in `dist-x86_64-linux alt`, the debug assertions are
really slow.
We will re-enable them after the PR has been successfully merged, thus
successfully updating the cache (freeing up 40 minutes), giving us enough
time to build these tools.