Commit Graph

74794 Commits

Author SHA1 Message Date
Артём Павлов [Artyom Pavlov]
7c6adb475a
fixed errors 2018-02-11 03:27:04 +03:00
Matthias Krüger
161e8ffda7 typo: correct endianess to endianness (this also changes function names!) 2018-02-11 00:56:24 +01:00
bors
d0f1f42816 Auto merge of #47286 - Aaronepower:master, r=Mark-Simulacrum
Update RELEASES.md for 1.24.0

[rendered](https://github.com/Aaronepower/rust/blob/master/RELEASES.md)
2018-02-10 23:50:18 +00:00
Артём Павлов [Artyom Pavlov]
c97aa09117
iterator instead loop 2018-02-11 02:36:22 +03:00
Артём Павлов [Artyom Pavlov]
8be306840f
added conversion from Rust feature to LLVM feature 2018-02-11 02:27:21 +03:00
Aaron Power
28b39f5d7a Update release notes for 1.24.0 2018-02-10 15:12:39 -07:00
Oliver Middleton
45d5a420ad Correct a few stability attributes 2018-02-10 21:20:42 +00:00
roblabla
3c01dea03e Add comment about the problem, and use provided path if available 2018-02-10 21:29:10 +01:00
bors
45fba43b3d Auto merge of #48113 - kennytm:rollup, r=kennytm
Rollup of 20 pull requests

- Successful merges: #47790, #47835, #47854, #48015, #48047, #48051, #48058, #48059, #48064, #48078, #48080, #48086, #48098, #48101, #48107, #48100, #48085, #48120, #48124, #47547
- Failed merges:
2018-02-10 19:48:20 +00:00
kennytm
4a827188cc
Rollup merge of #47547 - varkor:infinite-iterators-warning-doc, r=frewsxcv
Document the behaviour of infinite iterators on potentially-computable methods

It’s not entirely clear from the current documentation what behaviour
calling a method such as `min` on an infinite iterator like `RangeFrom`
is. One might expect this to terminate, but in fact, for infinite
iterators, `min` is always nonterminating (at least in the standard
library). This adds a quick note about this behaviour for clarification.
2018-02-11 03:39:53 +08:00
Artyom Pavlov
877272ba06
typo fix 2018-02-10 20:07:37 +03:00
kennytm
b37c60276a
Rollup merge of #48124 - alexcrichton:clean-up-debugging, r=kennytm
Explain unusual debugging code in librustc

Introduced in #47828 to help track down some bugs, it landed a bit hastily so
this is intended on cleaning it up a bit.
2018-02-11 00:53:47 +08:00
kennytm
18d7be3381
Rollup merge of #48120 - matthiaskrgr:typos_src_1, r=alexcrichton
fix typos in src/{bootstrap,ci,etc,lib{backtrace,core,fmt_macros}}

via codespell
2018-02-11 00:53:05 +08:00
kennytm
c888f72304
Rollup merge of #48085 - alexcrichton:update-dlmalloc, r=Mark-Simulacrum
Update the dlmalloc submodule

A bug was recently fixed in dlmalloc which meant that released memory to the
system accidentally wasn't getting reused, causing programs to be far slower
than they should be!
2018-02-11 00:51:56 +08:00
Artyom Pavlov
14f488ee7d
Whitelist pclmul x86 feature flag
Relevant `stdsimd` [issue](https://github.com/rust-lang-nursery/stdsimd/issues/318).
2018-02-10 19:22:04 +03:00
Alex Crichton
3a967676f8 Explain unusual debugging code in librustc
Introduced in #47828 to help track down some bugs, it landed a bit hastily so
this is intended on cleaning it up a bit.
2018-02-10 07:03:35 -08:00
Alex Crichton
49f7ccd35f Update the dlmalloc submodule
A bug was recently fixed in dlmalloc which meant that released memory to the
system accidentally wasn't getting reused, causing programs to be far slower
than they should be!
2018-02-10 07:01:27 -08:00
Guillaume Gomez
0cccd9aca5 Show better warning for trying to cast non-u8 scalar to char 2018-02-10 15:35:56 +01:00
Matthias Krüger
7ee3e39f64 fix typos in src/{bootstrap,ci,etc,lib{backtrace,core,fmt_macros}} 2018-02-10 12:22:57 +01:00
kennytm
8550ac8015
Rollup merge of #48100 - Mark-Simulacrum:fetch-nand, r=alexcrichton
Add fetch_nand to atomics

I think this is all fine but I have little familiarity with the atomic code (or libcore in general) so I may have accidentally done something wrong here...

cc #13226 (the tracking issue)
2018-02-10 14:26:57 +08:00
kennytm
6605d03549
Rollup merge of #48107 - matthiaskrgr:typo__substract_to_subtract, r=kennytm
fix typo: substract -> subtract
2018-02-10 14:24:10 +08:00
kennytm
a37a329522
Rollup merge of #48101 - Mark-Simulacrum:new-books, r=steveklabnik
Update books for next release

r? @steveklabnik
2018-02-10 14:24:08 +08:00
kennytm
22c5067ae1
Rollup merge of #48098 - alexcrichton:fix-i686-dist-bootstrap, r=Mark-Simulacrum
ci: Actually bootstrap on i686 dist

Right now the `--build` option was accidentally omitted, so we're bootstraping
from `x86_64` to `i686`. In addition to being slower (more compiles) that's not
actually bootstrapping!
2018-02-10 14:24:07 +08:00
kennytm
3554c3ab6f
Rollup merge of #48086 - Zoxc:gen-fix, r=nikomatsakis
Fix visitation order of calls so that it matches execution order. Fixes #48048

r? @nikomatsakis
2018-02-10 14:24:06 +08:00
kennytm
a580eefe5f
Rollup merge of #48080 - GuillaumeGomez:mobile-docs-fixes, r=QuietMisdreavus
Hide theme button under menu in mobile mode and fix top margin issue …

Fixes #48060.

r? @QuietMisdreavus
2018-02-10 14:24:05 +08:00
kennytm
1e10ca0b03
Rollup merge of #48078 - alexcrichton:fix-required-const-and-proc-macro, r=eddyb
Disallow function pointers to #[rustc_args_required_const]

This commit disallows acquiring a function pointer to functions tagged as
`#[rustc_args_required_const]`. This is intended to be used as future-proofing
for the stdsimd crate to avoid taking a function pointer to any intrinsic which
has a hard requirement that one of the arguments is a constant value.

Note that the first commit here isn't related specifically to this feature, but was necessary to get this working in stdsimd!
2018-02-10 14:24:04 +08:00
kennytm
d6394e51a0
Rollup merge of #48064 - Manishearth:intra-doc-bail, r=QuietMisdreavus
intra-doc-links: bail early for linky things

r? @QuietMisdreavus
2018-02-10 14:24:03 +08:00
kennytm
73d276779e
Rollup merge of #48059 - alexcrichton:sccachebs, r=Mark-Simulacrum
rustbuild: Pass `ccache` to build scripts

Right now the ccache setting is only used for LLVM, but this tweaks it to also
be used for build scripts so C++ builds like `librustc_llvm` can be a bit
speedier.
2018-02-10 14:24:02 +08:00
kennytm
2259e0dd1e
Rollup merge of #48058 - cuviper:binaryen-gcc8, r=alexcrichton
Update binaryen to fix -Werror with GCC 8

r? @alexcrichton
2018-02-10 14:24:00 +08:00
kennytm
4139c0ac74
Rollup merge of #48051 - ollie27:rustdoc_fn_unit_return, r=QuietMisdreavus
rustdoc: Hide `-> ()` in cross crate inlined Fn* bounds
2018-02-10 14:23:59 +08:00
kennytm
c04ec2c3f9
Rollup merge of #48047 - etaoins:fix-ice-for-mismatched-args-on-target-without-span, r=estebank
Fix ICE for mismatched args on target without span

Commit 7ed00caacc improved our error reporting by including the target function in our error messages when there is an argument count mismatch. A simple example from the UI tests is:

```
error[E0593]: function is expected to take a single 2-tuple as argument, but it takes 0 arguments
  --> $DIR/closure-arg-count.rs:32:53
   |
32 |     let _it = vec![1, 2, 3].into_iter().enumerate().map(foo);
   |                                                     ^^^ expected function that takes a single 2-tuple as argument
...
44 | fn foo() {}
   | -------- takes 0 arguments
```

However, this assumed the target span was always available. This does not hold true if the target function is in `std` or another crate. A simple example from #48046 is assigning `str::split` to a function type with a different number of arguments.

Fix by omitting all of the labels and suggestions related to the target span when it's not found.

Fixes #48046

r? @estebank
2018-02-10 14:23:58 +08:00
kennytm
077979f4a2
Rollup merge of #48015 - o01eg:disableable-installation, r=alexcrichton
Customizable extended tools

This PR adds `build.tools` option to manage installation of extended rust tools.

By default it doesn't change installation. All tools are built and `rls` and `rustfmt` allowed to fail installation.

If some set of tools chosen only those tools are built and installed without any fails allowed.

It solves some slotting issues with extended build enabled: https://bugs.gentoo.org/show_bug.cgi?id=645498
2018-02-10 14:23:57 +08:00
kennytm
262703cbbe
Rollup merge of #47854 - varkor:create-out-dir, r=pnkfelix
Create a directory for --out-dir if it does not already exist

Currently if `--out-dir` is set to a non-existent directory, the compiler will throw unfriendly messages like `error: could not write output to subdir/example.crate.allocator.rcgu.o: No such file or
directory`, which, while not completely unreadable, isn’t very user-friendly either. This change creates the directory automatically if it does not yet exist.
2018-02-10 14:23:56 +08:00
kennytm
4f8ea49d50
Rollup merge of #47835 - Mark-Simulacrum:remove-data-structs, r=nikomatsakis
Remove unused data structures

Cleanup; as far as I can tell the compiler no longer uses these.
2018-02-10 14:23:54 +08:00
kennytm
6bbee8de86
Rollup merge of #47790 - tinaun:patch-1, r=sfackler
derive PartialEq and Eq for `ParseCharError`

unlike the other Parse*Error types, ParseCharError didn't have these implemented for whatever reason
2018-02-10 14:23:53 +08:00
bors
39abcc0413 Auto merge of #47828 - alexcrichton:llvm-6, r=nikomatsakis
rustc: Upgrade to LLVM 6

The following submodules have been updated for a new version of LLVM:

- `src/llvm`
- `src/libcompiler_builtins` - transitively contains compiler-rt
- `src/dlmalloc`

This also updates the docker container for dist-i686-freebsd as the old 16.04
container is no longer capable of building LLVM. The
compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without
much interesting happening, but the LLVM update here is of particular note.
Unlike previous updates I haven't cherry-picked all existing patches we had on
top of our LLVM branch as we have a [huge amount][patches4] and have at this
point forgotten what most of them are for. Instead I started from the current
`release_60` branch in LLVM and only applied patches that were necessary to get
our tests working and building.

The [current set of custom rustc-specific patches](f1286127b7...rust-llvm-release-6-0-0) included in this LLVM update are:

* rust-lang/llvm@1187443 - this is how we actually implement
  `cfg(target_feature)` for now and continues to not be upstreamed. While a
  hazard for SIMD stabilization this commit is otherwise keeping the status
  quo of a small rustc-specific feature.
* rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't
  upstreamed, notably teaching LLVM about our allocation-related routines (which
  aren't malloc/free). Once we stabilize the global allocator routines we will
  likely want to upstream this patch, but for now it seems reasonable to keep it
  on our fork.
* rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in
  our 32-bit linux container. I'm not really sure why it's necessary but my
  guess is that it's because of the absolutely ancient glibc that we're using.
  In any case it's only updating pieces we're not actually using in LLVM so I'm
  hoping it'll turn out alright. This doesn't seem like something we'll want to
  upstream.c
* rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our
  i686-freebsd container, I'm not really sure what's going on but we for sure
  probably don't want to upstream this and otherwise it seems not too bad for
  now at least.
* rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug]
  which although diagnosed to a particular revision isn't currently fixed
  upstream (and the bug itself doesn't seem too active). This commit is a
  partial revert of the suspected cause of this regression (found via a
  bisection). I'm sort of hoping that this eventually gets fixed upstream with a
  similar fix (which we can replace in our branch), but for now I'm also hoping
  it's a relatively harmless change to have.

After applying these patches (plus one [backport] which should be [backported
upstream][llvm-back]) I believe we should have all tests working on all
platforms in our current test suite. I'm like 99% sure that we'll need some more
backports as issues are reported for LLVM 6 when this propagates through
nightlies, but that's sort of just par for the course nowadays!

In any case though some extra scrutiny of the patches here would definitely be
welcome, along with scrutiny of the "missing patches" like a [change to pass
manager order](rust-lang/llvm@2717444), [another change to pass manager
order](rust-lang/llvm@c782feb), some [compile fixes for
sparc](rust-lang/llvm@1a83de6), and some [fixes for
solaris](rust-lang/llvm@c2bfe0a).

[patches4]: rust-lang/llvm@5401fdf...rust-llvm-release-4-0-1
[backport]: rust-lang/llvm@5c54c25
[llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114
[upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096

---

The update to LLVM 6 is desirable for a number of reasons, notably:

* This'll allow us to keep up with the upstream wasm backend, picking up new
  features as they start landing.
* Upstream LLVM has fixed a number of SIMD-related compilation errors,
  especially around AVX-512 and such.
* There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed
  in the LLVM 4 branch we're using.
* Overall it's not a great idea to stagnate with our codegen backend!

This update is mostly powered by #47730 which is allowing us to update LLVM
*independent* of the version of LLVM that Emscripten is locked to. This means
that when compiling code for Emscripten we'll still be using the old LLVM 4
backend, but when compiling code for any other target we'll be using the new
LLVM 6 target. Once Emscripten updates we may no longer need this distinction,
but we're not sure when that will happen!

Closes #43370
Closes #43418
Closes #47015
Closes #47683
Closes rust-lang-nursery/stdsimd#157
Closes rust-lang-nursery/rust-wasm#3
2018-02-10 02:52:12 +00:00
John Kåre Alsaker
e236994c5e Add a fatal_cycle attribute for queries which indicates that they will cause a fatal error on query cycles 2018-02-10 03:38:07 +01:00
John Kåre Alsaker
46a3f2fa18 Change error message for E0391 to "cyclic dependency detected" 2018-02-10 03:28:15 +01:00
Martin Algesten
9a6afa8f67 Emit data::Impl in save-analysis 2018-02-10 03:04:44 +01:00
Scott McMurray
6f70a11a83 range_is_empty tracking issue is #48111 2018-02-09 18:01:12 -08:00
Scott McMurray
b5cb393cf5 Use is_empty in range iteration exhaustion tests 2018-02-09 17:54:27 -08:00
Alex Crichton
6b7b6b63a9 rustc: Upgrade to LLVM 6
The following submodules have been updated for a new version of LLVM:

- `src/llvm`
- `src/libcompiler_builtins` - transitively contains compiler-rt
- `src/dlmalloc`

This also updates the docker container for dist-i686-freebsd as the old 16.04
container is no longer capable of building LLVM. The
compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without
much interesting happening, but the LLVM update here is of particular note.
Unlike previous updates I haven't cherry-picked all existing patches we had on
top of our LLVM branch as we have a [huge amount][patches4] and have at this
point forgotten what most of them are for. Instead I started from the current
`release_60` branch in LLVM and only applied patches that were necessary to get
our tests working and building.

The current set of custom rustc-specific patches included in this LLVM update are:

* rust-lang/llvm@1187443 - this is how we actually implement
  `cfg(target_feature)` for now and continues to not be upstreamed. While a
  hazard for SIMD stabilization this commit is otherwise keeping the status
  quo of a small rustc-specific feature.
* rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't
  upstreamed, notably teaching LLVM about our allocation-related routines (which
  aren't malloc/free). Once we stabilize the global allocator routines we will
  likely want to upstream this patch, but for now it seems reasonable to keep it
  on our fork.
* rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in
  our 32-bit linux container. I'm not really sure why it's necessary but my
  guess is that it's because of the absolutely ancient glibc that we're using.
  In any case it's only updating pieces we're not actually using in LLVM so I'm
  hoping it'll turn out alright. This doesn't seem like something we'll want to
  upstream.c
* rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our
  i686-freebsd container, I'm not really sure what's going on but we for sure
  probably don't want to upstream this and otherwise it seems not too bad for
  now at least.
* rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug]
  which although diagnosed to a particular revision isn't currently fixed
  upstream (and the bug itself doesn't seem too active). This commit is a
  partial revert of the suspected cause of this regression (found via a
  bisection). I'm sort of hoping that this eventually gets fixed upstream with a
  similar fix (which we can replace in our branch), but for now I'm also hoping
  it's a relatively harmless change to have.

After applying these patches (plus one [backport] which should be [backported
upstream][llvm-back]) I believe we should have all tests working on all
platforms in our current test suite. I'm like 99% sure that we'll need some more
backports as issues are reported for LLVM 6 when this propagates through
nightlies, but that's sort of just par for the course nowadays!

In any case though some extra scrutiny of the patches here would definitely be
welcome, along with scrutiny of the "missing patches" like a [change to pass
manager order](rust-lang/llvm@2717444753), [another change to pass manager
order](rust-lang/llvm@c782febb7b), some [compile fixes for
sparc](rust-lang/llvm@1a83de63c4), and some [fixes for
solaris](rust-lang/llvm@c2bfe0abb).

[patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1
[backport]: https://github.com/rust-lang/llvm/commit/5c54c252db
[llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114
[upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096

---

The update to LLVM 6 is desirable for a number of reasons, notably:

* This'll allow us to keep up with the upstream wasm backend, picking up new
  features as they start landing.
* Upstream LLVM has fixed a number of SIMD-related compilation errors,
  especially around AVX-512 and such.
* There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed
  in the LLVM 4 branch we're using.
* Overall it's not a great idea to stagnate with our codegen backend!

This update is mostly powered by #47730 which is allowing us to update LLVM
*independent* of the version of LLVM that Emscripten is locked to. This means
that when compiling code for Emscripten we'll still be using the old LLVM 4
backend, but when compiling code for any other target we'll be using the new
LLVM 6 target. Once Emscripten updates we may no longer need this distinction,
but we're not sure when that will happen!

Closes #43370
Closes #43418
Closes #47015
Closes #47683
Closes rust-lang-nursery/stdsimd#157
Closes rust-lang-nursery/rust-wasm#3
2018-02-09 17:13:14 -08:00
Mazdak Farrokhzad
486160335c stabilize Box::leak: remove #![feature(box_leak)] in docs 2018-02-10 01:39:22 +01:00
Mazdak Farrokhzad
467b5cfcb7 stabilize (version: 1.26.0) Box::leak, cc #46179 2018-02-10 01:26:19 +01:00
Matthias Krüger
e6f910e31e fix typo: substract -> subtract. 2018-02-10 00:56:33 +01:00
John Kåre Alsaker
ae46434b79 Remove "static item recursion checking" in favor of relying on cycle checks in the query engine 2018-02-10 00:29:11 +01:00
Mark Simulacrum
1335b3da5a Add fetch_nand.
cc #13226 (the tracking issue)
2018-02-09 16:04:41 -07:00
Gianni Ciccarelli
2f22a929c6 add Self: Trait<..> inside the param_env of a default impl 2018-02-09 21:40:54 +00:00
Eduard-Mihai Burtescu
8af134e031 rustc_mir: insert a dummy access to places being matched on, when building MIR. 2018-02-09 23:25:10 +02:00
QuietMisdreavus
72779936ec fix playground test for newly-trimmed doctests 2018-02-09 13:48:59 -06:00