kennytm [Sat, 24 Mar 2018 17:26:32 +0000 (01:26 +0800)]
Rollup merge of #49162 - tmandry:stabilize-termination-trait, r=nikomatsakis
Stabilize termination_trait, split out termination_trait_test
For #48453.
First time contribution, so I'd really appreciate any feedback on how this PR can be better.
Not sure exactly what kind of documentation update is needed. If there is no PR to update the reference, I can try doing that this week as I have time.
kennytm [Sat, 24 Mar 2018 17:26:30 +0000 (01:26 +0800)]
Rollup merge of #49122 - scottmcm:z-align-attr, r=cramertj
Add a -Z flag for LLVM align attributes on arguments
LLVM seems to still put the assume calls in when inlining, so this probably isn't in a place where it can be turned on by default, but it's interesting to experiment with.
For example, this makes `mem::swap::<u64x8>` be 8x `vmovaps ymm` instead of 16x `vmovups xmm`, on my cpu.
kennytm [Sat, 24 Mar 2018 17:26:27 +0000 (01:26 +0800)]
Rollup merge of #49089 - alexcrichton:fix-timings, r=Mark-Simulacrum
rustbuild: Tweak where timing information goes
This commit tweaks where timing and step information is printed out as part of
the build, ensuring that we do it as close to the location where work happens as
possible. In rustbuild various functions may perform long blocking work as
dependencies are assembled, so if we print out timing information early on we
may accidentally time more than just the step we were intending to time!
kennytm [Sat, 24 Mar 2018 17:26:25 +0000 (01:26 +0800)]
Rollup merge of #49076 - bobdavelisafrank:filetype-metadata-docfix, r=bluss
Fix Issue #48345, is_file, is_dir, and is_symlink note mutual exclusion
The methods on the structures `fs::FileType` and `fs::Metadata` of (respectively) `is_file`, `is_dir`, and `is_symlink` had some ambiguity in documentation, where it was not noted whether files will pass those tests exclusively or not. It is now written that the tests are mutually exclusive.
bors [Sat, 24 Mar 2018 13:23:17 +0000 (13:23 +0000)]
Auto merge of #49251 - nikomatsakis:issue-15872-elision-impl-header, r=cramertj
support elision in impl headers
You can now do things like:
```
impl MyTrait<'_> for &u32 { ... }
```
Each `'_` or elided lifetime is a fresh parameter. `'_` and elision are still not permitted in associated type values. (Plausibly we could support that if there is a single input lifetime.) The original lifetime elision RFC was a bit unclear on this point: [as documented here, I think this is the correct interpretation, both because it fits existing impls and it's most analogous to the behavior in fns](https://github.com/rust-lang/rust/issues/15872#issuecomment-338700138).
We do not support elision with deprecated forms:
```
impl MyTrait for std::cell::Ref<u32> { } // ERROR
```
bors [Sat, 24 Mar 2018 04:43:24 +0000 (04:43 +0000)]
Auto merge of #48552 - kennytm:lower-unstable-priority, r=nikomatsakis
Lower the priority of unstable methods when picking a candidate.
Previously, when searching for the impl of a method, we do not consider the stability of the impl. This leads to lots of insta-inference-regressions due to method ambiguity when a popular name is chosen. This has happened multiple times in Rust's history e.g.
* `f64::from_bits` #40470
* `Ord::{min, max}` #42496
* `Ord::clamp` #44095 (eventually got reverted due to these breakages)
* `Iterator::flatten` #48115 (recently added)
This PR changes the probing order so that unstable items are considered last. If a stable item is found, the unstable items will not be considered (but a future-incompatible warning will still be emitted), thus allowing stable code continue to function without using qualified names.
Once the unstable feature is stabilized, the ambiguity error will still be emitted, but the user can also use newly stable std methods, while the current situation is that downstream user is forced to update the code without any immediate benefit.
(I hope that we could bring back `Ord::clamp` if this PR is merged.)
Alex Crichton [Fri, 23 Mar 2018 14:27:27 +0000 (09:27 -0500)]
Rollup merge of #49272 - semarie:cat-and-grep-gnu, r=alexcrichton
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).
Alex Crichton [Fri, 23 Mar 2018 14:27:18 +0000 (09:27 -0500)]
Rollup merge of #49028 - QuietMisdreavus:the-dark-forbidden-corners-of-rustdoc, r=frewsxcv
add an "unstable features" chapter to the rustdoc book
There are several rustdoc features that currently are undocumented, but also don't fit with the rest of the Rustdoc Book since they're also unstable. Some of these have corresponding feature gates and chapters in the Unstable Book, but many don't, and i wanted a place to talk about them officially.
Goal: talk about everything rustdoc can do that needs nightly
- [x] Feature gates (extensions to the doc attribute that can be caught by the compiler)
- [x] doc(cfg)
- [x] doc(masked)
- [x] doc(spotlight)
- [x] doc(include)
- [x] Command-line flags (features that require a CLI flag to use, where the flag itself is a `-Z` command or otherwise requires `-Z unstable-options` before rustdoc will accept it)
- [x] markdown-before-content/markdown-after-content
- [x] playground-url
- [x] display-warnings
- [x] crate-version
- [x] linker
- [x] sort-modules-by-appearance
- [x] themes/theme-checker
- [x] resource-suffix
- [x] `-Z force-unstable-if-unmarked`
- [x] Nightly-gated functionality (features that are gated by requiring a nightly build without needing a CLI flag or a feature gate to unlock)
- [x] intra-links
- [x] error numbers for `compile_fail` doctests
Alex Crichton [Fri, 23 Mar 2018 14:27:16 +0000 (09:27 -0500)]
Rollup merge of #48909 - RalfJung:type_alias_bounds, r=petrochenkov
Improve lint for type alias bounds
First of all, I learned just today that I was wrong assuming that the bounds in type aliases are entirely ignored: It turns out they are used to resolve associated types in type aliases. So:
```rust
type T1<U: Bound> = U::Assoc; // compiles
type T2<U> = U::Assoc; // fails
type T3<U> = <U as Bound>::Assoc; // "correct" way to write this, maybe?
```
I am sorry for creating this mess.
This PR changes the wording of the lint accordingly. Moreover, since just removing the bound is no longer always a possible fix, I tried to detect cases like `T1` above and show a helpful message to the user:
```
warning: bounds on generic parameters are not enforced in type aliases
--> $DIR/type-alias-bounds.rs:57:12
|
LL | type T1<U: Bound> = U::Assoc; //~ WARN not enforced in type aliases
| ^^^^^
|
= help: the bound will not be checked when the type alias is used, and should be removed
help: use absolute paths (i.e., <T as Trait>::Assoc) to refer to associated types in type aliases
--> $DIR/type-alias-bounds.rs:57:21
|
LL | type T1<U: Bound> = U::Assoc; //~ WARN not enforced in type aliases
| ^^^^^^^^
```
I am not sure if I got this entirely right. Ideally, we could provide a suggestion involving the correct trait and type name -- however, while I have access to the HIR in the lint, I do not know how to get access to the resolved name information, like which trait `Assoc` belongs to above. The lint does not even run if that resolution fails, so I assume that information is available *somewhere*...
This is a follow-up for (parts of) https://github.com/rust-lang/rust/pull/48326. Also see https://github.com/rust-lang/rust/issues/21903.
This changes the name of a lint, but that lint was just merged to master yesterday and has never even been on beta.
Alex Crichton [Fri, 23 Mar 2018 14:27:14 +0000 (09:27 -0500)]
Rollup merge of #48883 - alexcrichton:wasm-custom-sections, r=nikomatsakis
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).
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).