Mark Simulacrum [Sun, 30 Jul 2017 04:12:53 +0000 (22:12 -0600)]
Unify flags into config.
This introduces a slight change in behavior, where we unilaterally
respect the --host and --target parameters passed for all sanity
checking and runtime configuration.
bors [Sat, 12 Aug 2017 19:40:49 +0000 (19:40 +0000)]
Auto merge of #43724 - lukaramu:std-ops-docs, r=QuietMisdreavus
Improve std::ops docs
Fixes #29365. (This fixes all but one point from @steveklabnik's list, but that point was referring to examples of implementing range traits, but there are no range traits in std::ops.)
The main changes are quite a bit of copyediting, adding more "real" examples for some of the traits, incorporating some guidance from the API docs, more linking (cross-docs and to the book & reference), cleaning up examples, moving things around, and so on. Refer to the commit messages for more details.
Note: I decided to link to the second edition of the book since I think it's more appropriate now for the sections I linked, if this is not okay, please say so!
lukaramu [Tue, 8 Aug 2017 12:34:37 +0000 (14:34 +0200)]
std::ops docs: incorporated changes suggested in review
* fixed link typos and copy-paster errors
* rewrote Fn* explanations
* `RHS = Self` -> `RHS` is `Self` (added that to all applicable places as
well)
* fixed up some links
* s/MutDeref/DerefMut
* removed remaining superfluous `fn main()`s
* fixed some minor phrasings and factual errors and inaccuracies
std::ops docs: Fix phrasing and factual errors/inaccuracies
bors [Sat, 12 Aug 2017 14:24:40 +0000 (14:24 +0000)]
Auto merge of #43823 - tchajed:fix-pr-link, r=frewsxcv
Update GitHub pull request documentation link
It looks like the GitHub documentation has been re-organized so that the "fork and pull" model isn't explained alongside the PR process in one convenient link any more.
bors [Sat, 12 Aug 2017 11:57:10 +0000 (11:57 +0000)]
Auto merge of #43746 - eddyb:sound-thread-local, r=alexcrichton
Check #[thread_local] statics correctly in the compiler.
Fixes #43733 by introducing `#[allow_internal_unsafe]` analogous to `#[allow_internal_unstable]`, for letting a macro expand to `unsafe` blocks and functions even in `#![forbid(unsafe_code)]` crates.
Fixes #17954 by not letting references to `#[thread_local]` statics escape the function they're taken in - we can't just use a magical lifetime because Rust has *lifetime parametrism*, so if we added the often-proposed `'thread` lifetime, we'd have no way to check it in generic code.
To avoid potential edge cases in the compiler, the lifetime is actually that of a temporary at the same position, i.e. `&TLS_STATIC` has the same lifetime `&non_const_fn()` would.
Referring to `#[thread_local]` `static`s at compile-time is banned now (as per PR discussion).
Additionally, to remove `unsafe impl Sync` from `std::thread::local::fast::Key`, `#[thread_local]` statics are now not required to implement `Sync`, as they are not shared between threads.
bors [Sat, 12 Aug 2017 00:54:38 +0000 (00:54 +0000)]
Auto merge of #43772 - arielb1:nonfree-block, r=nagisa
For box expressions, use NZ drop instead of a free block
This falls naturally out of making drop elaboration work with `box`
expressions, which is probably required for sane MIR borrow-checking.
This is a pure refactoring with no intentional functional effects.
bors [Fri, 11 Aug 2017 22:23:10 +0000 (22:23 +0000)]
Auto merge of #43766 - michaelwoerister:trans-scheduler-touch-up, r=alexcrichton
Improve LLVM/trans scheduling a bit
Currently it's possible that the main thread is waiting on LLVM threads to finish work while its implicit token is going to waste. This PR let's the main thread take over, so one of the running LLVM threads can free its token earlier.
bors [Fri, 11 Aug 2017 19:43:44 +0000 (19:43 +0000)]
Auto merge of #43750 - tbu-:pr_fn_unreachable, r=sfackler
Put `intrinsics::unreachable` on a possible path to stabilization
Mark it with the `unreachable` feature and put it into the `mem` module.
This is a pretty straight-forward API that can already be simulated in
stable Rust by using `transmute` to create an uninhabited enum that can
be matched.
bors [Fri, 11 Aug 2017 13:04:59 +0000 (13:04 +0000)]
Auto merge of #43748 - RalfJung:mir-validate2, r=arielb1
AddValidation: handle Call terminators into blocks that have multiple incoming edges
The old code was just wrong: It would add validation on paths that don't even come from the call, and it would add multiple validations if multiple calls end return to the same block.
Guillaume Gomez [Fri, 11 Aug 2017 08:20:27 +0000 (10:20 +0200)]
Rollup merge of #43760 - ollie27:rustdoc_search_css, r=GuillaumeGomez
rustdoc: Fix broken CSS in search results
The layout is currently broken for struct/union fields and enum variants
in the search results when searching from a struct, union or enum page.
Some examples:
https://doc.rust-lang.org/nightly/std/ops/struct.RangeInclusive.html?search=start
https://doc.rust-lang.org/nightly/std/option/enum.Option.html?search=some
Guillaume Gomez [Fri, 11 Aug 2017 08:20:22 +0000 (10:20 +0200)]
Rollup merge of #43739 - ibabushkin:master, r=eddyb
Encode proper module spans in crate metadata.
The spans previously encoded only span the first token after the opening
brace, up to the closing brace of inline `mod` declarations. Thus, when
examining exports from an external crate, the spans don't include the
header of inline `mod` declarations.
Guillaume Gomez [Fri, 11 Aug 2017 08:20:21 +0000 (10:20 +0200)]
Rollup merge of #43721 - natboehm:patch-1, r=steveklabnik
Provide more explanation for Deref in String docs
While working on a different project I encountered a point of confusion where using `&String` to dereference a `String` into `&str` did not compile. I found the explanation of [String Deref](https://doc.rust-lang.org/std/string/struct.String.html#deref), thought that it matched what I was trying to do, and was confused as to why my program did not compile when the docs stated that it would work with 'any function which takes a `&str`'. At the bottom it is mentioned that this will 'generally' work, unless `String` is needed, but I found this statement confusing based on the previous claim of 'any'. Looking further into the docs I was able to find the function `as_str()` that works instead.
I thought it might be helpful to mention here deref coercion, an instance in which using `&String` does not work, to explain why it does not work, then direct users to a different option that should work in this instance. A user casually skimming the page will likely come to this explanation first, then find `as_str()` later, but be no the wiser as to what potentially went wrong.
Guillaume Gomez [Fri, 11 Aug 2017 08:20:17 +0000 (10:20 +0200)]
Rollup merge of #43632 - ruuda:allow-long-relative-urls, r=Mark-Simulacrum
Detect relative urls in tidy check
This came up in #43631: there can be long relative urls in Markdown comments, that do not start with `http://` or `https://`, so the tidy check will not detect them as urls and complain about the line length. This PR adds detection of relative urls starting with `../`.
Guillaume Gomez [Fri, 11 Aug 2017 08:20:16 +0000 (10:20 +0200)]
Rollup merge of #43176 - RalfJung:explain, r=eddyb
E0122: clarify wording
I *assume* the reason these constraints are not hard errors is backwards compatibility. If yes, I think the error explanation (at least the long form) should be clearer about that, which is what this PR does.
If not, the explanation should give some other suitable explanation.
bors [Fri, 11 Aug 2017 02:23:16 +0000 (02:23 +0000)]
Auto merge of #43743 - michaelwoerister:gcx-tcx-switcheroo, r=eddyb
Some assorted region hashing fixes.
This PR contains three changes.
1. It changes what we implement `HashStable` for. Previously, the trait was implemented for things in the local `TyCtxt`. That was OK, since we only invoked hashing with a `TyCtxt<'_, 'tcx, 'tcx>` where there is no difference. With query result hashing this becomes a problem though. So we now implement `HashStable` for things in `'gcx`.
2. The PR makes the regular `HashStable` implementation *not* anonymize late-bound regions anymore. It's a waste of computing resources and it's not clear that it would always be correct to do so.
3. The PR adds an option for stable hashing to treat all regions as erased and uses this new option when computing the `TypeId`. This should help with https://github.com/rust-lang/rust/issues/41875.
I did not add a test case for (3) since that's not possible yet. But it looks like @zackmdavis has something in the pipeline there `:)`.
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.
For box expressions, use NZ drop instead of a free block
This falls naturally out of making drop elaboration work with `box`
expressions, which is probably required for sane MIR borrow-checking.
This is a pure refactoring with no intentional functional effects.
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.