bors [Thu, 10 Aug 2017 15:10:17 +0000 (15:10 +0000)]
Auto merge of #43720 - pornel:staticconst, r=petrochenkov
Hint correct extern constant syntax
Error message for `extern "C" { const …}` is terse, and the right syntax is hard to guess given unfortunate difference between meaning of `static` in C and Rust.
bors [Thu, 10 Aug 2017 11:20:15 +0000 (11:20 +0000)]
Auto merge of #43522 - alexcrichton:rewrite-lints, r=michaelwoerister
rustc: Rearchitect lints to be emitted more eagerly
In preparation for incremental compilation this commit refactors the lint
handling infrastructure in the compiler to be more "eager" and overall more
incremental-friendly. Many passes of the compiler can emit lints at various
points but before this commit all lints were buffered in a table to be emitted
at the very end of compilation. This commit changes these lints to be emitted
immediately during compilation using pre-calculated lint level-related data
structures.
Linting today is split into two phases, one set of "early" lints run on the
`syntax::ast` and a "late" set of lints run on the HIR. This commit moves the
"early" lints to running as late as possible in compilation, just before HIR
lowering. This notably means that we're catching resolve-related lints just
before HIR lowering. The early linting remains a pass very similar to how it was
before, maintaining context of the current lint level as it walks the tree.
Post-HIR, however, linting is structured as a method on the `TyCtxt` which
transitively executes a query to calculate lint levels. Each request to lint on
a `TyCtxt` will query the entire crate's 'lint level data structure' and then go
from there about whether the lint should be emitted or not.
The query depends on the entire HIR crate but should be very quick to calculate
(just a quick walk of the HIR) and the red-green system should notice that the
lint level data structure rarely changes, and should hopefully preserve
incrementality.
Overall this resulted in a pretty big change to the test suite now that lints
are emitted much earlier in compilation (on-demand vs only at the end). This in
turn necessitated the addition of many `#![allow(warnings)]` directives
throughout the compile-fail test suite and a number of updates to the UI test
suite.
bors [Thu, 10 Aug 2017 08:53:22 +0000 (08:53 +0000)]
Auto merge of #43582 - ivanbakel:unused_mut_ref, r=arielb1
Fixed mutable vars being marked used when they weren't
#### NB : bootstrapping is slow on my machine, even with `keep-stage` - fixes for occurances in the current codebase are <s>in the pipeline</s> done. This PR is being put up for review of the fix of the issue.
Fixes #43526, Fixes #30280, Fixes #25049
### Issue
Whenever the compiler detected a mutable deref being used mutably, it marked an associated value as being used mutably as well. In the case of derefencing local variables which were mutable references, this incorrectly marked the reference itself being used mutably, instead of its contents - with the consequence of making the following code emit no warnings
```
fn do_thing<T>(mut arg : &mut T) {
... // don't touch arg - just deref it to access the T
}
```
### Fix
Make dereferences not be counted as a mutable use, but only when they're on borrows on local variables.
#### Why not on things other than local variables?
* Whenever you capture a variable in a closure, it gets turned into a hidden reference - when you use it in the closure, it gets dereferenced. If the closure uses the variable mutably, that is actually a mutable use of the thing being dereffed to, so it has to be counted.
* If you deref a mutable `Box` to access the contents mutably, you are using the `Box` mutably - so it has to be counted.
bors [Thu, 10 Aug 2017 04:01:21 +0000 (04:01 +0000)]
Auto merge of #43735 - est31:master, r=alexcrichton
Avoid calling the column!() macro in panic
Closes #43057
This "fix" adds a new macro called `__rust_unstable_column` and to use it instead of the `column` macro inside panic. The new macro can be shadowed as well as `column` can, but its very likely that there is no code that does this in practice.
There is no real way to make "unstable" macros that are usable by stable macros, so we do the next best thing and prefix the macro with `__rust_unstable` to make sure people recognize it is unstable.
bors [Wed, 9 Aug 2017 19:50:03 +0000 (19:50 +0000)]
Auto merge of #43484 - estebank:point-to-return, r=arielb1
Point at return type always when type mismatch against it
Before this, the diagnostic errors would only point at the return type
when changing it would be a possible solution to a type error. Add a
label to the return type without a suggestion to change in order to make
the source of the expected type obvious.
Alex Crichton [Thu, 27 Jul 2017 04:51:09 +0000 (21:51 -0700)]
rustc: Rearchitect lints to be emitted more eagerly
In preparation for incremental compilation this commit refactors the lint
handling infrastructure in the compiler to be more "eager" and overall more
incremental-friendly. Many passes of the compiler can emit lints at various
points but before this commit all lints were buffered in a table to be emitted
at the very end of compilation. This commit changes these lints to be emitted
immediately during compilation using pre-calculated lint level-related data
structures.
Linting today is split into two phases, one set of "early" lints run on the
`syntax::ast` and a "late" set of lints run on the HIR. This commit moves the
"early" lints to running as late as possible in compilation, just before HIR
lowering. This notably means that we're catching resolve-related lints just
before HIR lowering. The early linting remains a pass very similar to how it was
before, maintaining context of the current lint level as it walks the tree.
Post-HIR, however, linting is structured as a method on the `TyCtxt` which
transitively executes a query to calculate lint levels. Each request to lint on
a `TyCtxt` will query the entire crate's 'lint level data structure' and then go
from there about whether the lint should be emitted or not.
The query depends on the entire HIR crate but should be very quick to calculate
(just a quick walk of the HIR) and the red-green system should notice that the
lint level data structure rarely changes, and should hopefully preserve
incrementality.
Overall this resulted in a pretty big change to the test suite now that lints
are emitted much earlier in compilation (on-demand vs only at the end). This in
turn necessitated the addition of many `#![allow(warnings)]` directives
throughout the compile-fail test suite and a number of updates to the UI test
suite.
Zack M. Davis [Mon, 7 Aug 2017 17:57:08 +0000 (10:57 -0700)]
extended information for E0554 feature attributes only work on nightlies
It's more pleasing to use the inner-attribute syntax (`#!` rather than
`#`) in the error message, as that is how `feature` attributes in
particular will be declared (as they apply to the entire crate).
bors [Wed, 9 Aug 2017 04:03:49 +0000 (04:03 +0000)]
Auto merge of #43728 - zackmdavis:fnused, r=eddyb
#[must_use] for functions
This implements [RFC 1940](https://github.com/rust-lang/rfcs/pull/1940).
The RFC and discussion thereof seem to suggest that tagging `PartialEq::eq` and friends as `#[must_use]` would automatically lint for unused comparisons, but it doesn't work out that way (at least the way I've implemented it): unused `.eq` method calls get linted, but not `==` expressions. (The lint operates on the HIR, which sees binary operations as their own thing, even if they ultimately just call `.eq` _&c._.)
bors [Wed, 9 Aug 2017 01:30:02 +0000 (01:30 +0000)]
Auto merge of #43595 - oyvindln:master, r=aturon
Add an overflow check in the Iter::next() impl for Range<_> to help with vectorization.
This helps with vectorization in some cases, such as (0..u16::MAX).collect::<Vec<u16>>(),
as LLVM is able to change the loop condition to use equality instead of less than and should help with #43124. (See also my [last comment](https://github.com/rust-lang/rust/issues/43124#issuecomment-319098625) there.) This PR makes collect on ranges of u16, i16, i8, and u8 **significantly** faster (at least on x86-64 and i686), and pretty close, though not quite equivalent to a [manual unsafe implementation](https://is.gd/nkoecB). 32 ( and 64-bit values on x86-64) bit values were already vectorized without this change, and they still are. This PR doesn't seem to help with 64-bit values on i686, as they still don't vectorize well compared to doing a manual loop.
I'm a bit unsure if this was the best way of implementing this, I tried to do it with as little changes as possible and avoided changing the step trait and the behavior in RangeFrom (I'll leave that for others like #43127 to discuss wider changes to the trait). I tried simply changing the comparison to `self.start != self.end` though that made the compiler segfault when compiling stage0, so I went with this method instead for now.
As for `next_back()`, reverse ranges seem to optimise properly already.
bors [Tue, 8 Aug 2017 12:14:51 +0000 (12:14 +0000)]
Auto merge of #43723 - arielb1:nonincremental-fast-reject, r=eddyb
make `for_all_relevant_impls` O(1) again
A change in #41911 had made `for_all_relevant_impls` do a linear scan over
all impls, instead of using an HashMap. Use an HashMap again to avoid
quadratic blowup when there is a large number of structs with impls.
I think this fixes #43141 completely, but I want better measurements in
order to be sure. As a perf patch, please don't roll this up.
A change in #41911 had made `for_all_relevant_impls` do a linear scan over
all impls, instead of using an HashMap. Use an HashMap again to avoid
quadratic blowup when there is a large number of structs with impls.
I think this fixes #43141 completely, but I want better measurements in
order to be sure. As a perf patch, please don't roll this up.
bors [Tue, 8 Aug 2017 06:48:45 +0000 (06:48 +0000)]
Auto merge of #42998 - behnam:uni-ver-type, r=sfackler
[libstd_unicode] Change UNICODE_VERSION to use u32
Looks like there's no strong reason to keep these values at `u64`.
With the current plans for the Unicode Standard, `u8` should be enough for the next 200 years. To stay on the safe side, I'm using `u16` here. I don't see a reason to go with anything machine-dependent/more-efficient.
bors [Tue, 8 Aug 2017 04:24:48 +0000 (04:24 +0000)]
Auto merge of #43725 - dhduvall:libc-update, r=alexcrichton
Update libc to 0.2.29
Cargo pulls in libc from crates.io for a number of dependencies, but 0.2.27 is too old to work properly with Solaris. In particular, it needs the change to make Solaris' `PTHREAD_PROCESS_PRIVATE` a 16-bit integer.
Danek Duvall [Mon, 7 Aug 2017 22:42:30 +0000 (15:42 -0700)]
Update libc to 0.2.29
Cargo pulls in libc from crates.io for a number of dependencies, but
0.2.27 is too old to work properly with Solaris. In particular, it
needs the change to make Solaris' PTHREAD_PROCESS_PRIVATE a 16-bit
integer.
bors [Mon, 7 Aug 2017 15:42:35 +0000 (15:42 +0000)]
Auto merge of #43713 - arielb1:legacy-dataflow, r=eddyb
rustc::middle::dataflow - visit the CFG in RPO
We used to propagate bits in node-id order, which sometimes caused an
excessive number of iterations, especially when macros were present. As
everyone knows, visiting the CFG in RPO bounds the number of iterators
by 1 plus the depth of the most deeply nested loop (times the height of
the lattice, which is 1).
I have no idea how this affects borrowck perf in the non-worst-case, so it's probably a good idea to not roll this up so we can see the effects.
We used to propagate bits in node-id order, which sometimes caused an
excessive number of iterations, especially when macros were present. As
everyone knows, visiting the CFG in RPO bounds the number of iterators
by 1 plus the depth of the most deeply nested loop (times the height of
the lattice, which is 1).
bors [Mon, 7 Aug 2017 10:01:06 +0000 (10:01 +0000)]
Auto merge of #43709 - zackmdavis:de-orphan_extended_information, r=GuillaumeGomez
de-orphan extended information
Bizarrely, librustc_passes, librustc_plugin, librustc_mir, and libsyntax [weren't getting their error explanations registered](https://github.com/rust-lang/rust/issues/35284) (leaving _several_ error codes absent from [the index](https://doc.rust-lang.org/nightly/error-index.html) and `--explain`). This surfaced a few latent doctest failures that were fixed where readily possible and ignored (with a recorded excuse) if not.
Zack M. Davis [Mon, 7 Aug 2017 04:50:41 +0000 (21:50 -0700)]
comment out record of now-unused error code E0563
The sole appearance of this code was deleted in 6383de15; the existing practice
in these cases seems to be to comment out its mention in
`register_diagnostics!`.
Zack M. Davis [Mon, 7 Aug 2017 04:36:06 +0000 (21:36 -0700)]
fixing doctest failures in resurfaced extended information
After repatriating error explanations to the global registry, some lurking
doctest failures surfaced and needed to be chased down. Sadly, a few doctests
needed to be ignored due to a not-yet-understood regression in the doctest
`compile_fail` functionality (filed #43707).
bors [Sun, 6 Aug 2017 08:09:59 +0000 (08:09 +0000)]
Auto merge of #43488 - Florob:repeat-opt, r=arielb1
Optimize initialization of arrays using repeat expressions
This PR was inspired by [this thread](https://www.reddit.com/r/rust/comments/6o8ok9/understanding_rust_performances_a_newbie_question/) on Reddit.
It tries to bring array initialization in the same ballpark as `Vec::from_elem()` for unoptimized builds.
For optimized builds this should relieve LLVM of having to figure out the construct we generate is in fact a `memset()`.
To that end this emits `llvm.memset()` when:
* the array is of integer type and all elements are zero (`Vec::from_elem()` also explicitly optimizes for this case)
* the array elements are byte sized
If the array is zero-sized initialization is omitted entirely.
bors [Sat, 5 Aug 2017 13:12:56 +0000 (13:12 +0000)]
Auto merge of #43554 - eddyb:apfloat, r=nikomatsakis
APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.
As part of the CTFE initiative, we're forced to find a solution for floating-point operations.
By design, IEEE-754 does not explicitly define everything in a deterministic manner, and there is some variability between platforms, at the very least (e.g. NaN payloads).
If types are to evaluate constant expressions involving type (or in the future, const) generics, that evaluation needs to be *fully deterministic*, even across `rustc` host platforms.
That is, if `[T; T::X]` was used in a cross-compiled library, and the evaluation of `T::X` executed a floating-point operation, that operation has to be reproducible on *any other host*, only knowing `T` and the definition of the `X` associated const (as either AST or HIR).
Failure to uphold those rules allows an associated type (e.g. `<Foo as Iterator>::Item`) to be seen as two (or more) different types, depending on the current host, and such type safety violations typically allow writing of a `transmute` in safe code, given enough generics.
The options considered by @rust-lang/compiler were:
1. Ban floating-point operations in generic const-evaluation contexts
2. Emulate floating-point operations in an uniformly deterministic fashion
The former option may seem appealing at first, but floating-point operations *are allowed today*, so they can't be banned wholesale, a distinction has to be made between the code that already works, and future generic contexts. *Moreover*, every computation that succeeded *has to be cached*, otherwise the generic case can be reproduced without any generics. IMO there are too many ways it can go wrong, and a single violation can be enough for an unsoundness hole.
Not to mention we may end up really wanting floating-point operations *anyway*, in CTFE.
I went with the latter option, and seeing how LLVM *already* has a library for this exact purpose (as it needs to perform optimizations independently of host floating-point capabilities), i.e. `APFloat`, that was what I ended up basing this PR on.
But having been burned by the low reusability of bindings that link to LLVM, and because I would *rather* the floating-point operations to be wrong than not deterministic or not memory-safe (`APFloat` does far more pointer juggling than I'm comfortable with), I decided to RIIR.
This way, we have a guarantee of *no* `unsafe` code, a bit more control over the where native floating-point might accidentally be involved, and non-LLVM backends can share it.
I've also ported all the testcases over, *before* any functionality, to catch any mistakes.
Currently the PR replaces all CTFE operations to go through `apfloat::ieee::{Single,Double}`, keeping only the bits of the `f32` / `f64` memory representation in between operations.
Converting from a string also double-checks that `core::num` and `apfloat` agree on the interpretation of a floating-point number literal, in case either of them has any bugs left around.
r? @nikomatsakis
f? @nagisa @est31
<hr/>
Huge thanks to @edef1c for first demoing usable `APFloat` bindings and to @chandlerc for fielding my questions on IRC about `APFloat` peculiarities (also upstreaming some bugfixes).
bors [Sat, 5 Aug 2017 05:08:12 +0000 (05:08 +0000)]
Auto merge of #43642 - mmatyas:unskip_aarch64_tests, r=sanxiyn
Unskip some tests on AArch64
I've been running the test suite remotely on an Acer Chromebook R13 and natively on an ARM Juno developer board, both AArch64 devices. Most of the tests that are skipped on AArch64 are due to testing stdcall/fastcall/x86-specific code or the debugger, but I've found a few tests that could be enabled there.
These have been skipped previously due to failing on the `aarch64-linux-android` and `mac-android` buildbots, more than 2 years ago (#23471, #23695). It seems we don't test those platforms any more, but as they do work on AArch64 Linux, I'd like to propose re-enabling them. All of them pass on my devices.
bors [Sat, 5 Aug 2017 01:58:24 +0000 (01:58 +0000)]
Auto merge of #43639 - TobiasSchaffner:master, r=alexcrichton
Add L4Re Support in librustc_back
Add experimental support for x86_64-unknown-l4re-uclibc target, which covers the L4 Runtime Environment.
This pull request contains the changes that have to be made to librustc_back. It follows the changes humenda made in pull request https://github.com/rust-lang/libc/pull/591 to libc.
Next steps will be the modifications to the needed libraries. (libstd, liballoc_system, libpanic_abort, libunwind)
projects / rust.git / log