Auto merge of #52751 - QuietMisdreavus:you-shall-not-pass, r=GuillaumeGomez
rustdoc: rework how default passes are chosen
This is a refactor that changes how we select default passes, and changes the set of passes used for `--document-private-items`. It's groundwork for a bigger refactor i want to do.
The major changes:
* There are now two sets of "default passes": one set for "no flags given" and one for "document private items".
* These sets can be selected by a new `DefaultPassOption` enum, which is selected from based on the presence of `--no-defaults` or `--document-private-items` CLI flags, or their associated crate attributes.
* When printing the list of passes, we also print the list of passes for `--document-private-items` in addition to the "default defaults".
* I added `propagate-doc-cfg` and `strip-priv-imports` to the "document private items" set. The former is to ensure items are properly tagged with the full set of cfg flags even when "document private items" is active. The latter is based on feedback and personal experience navigating the `rustc` docs, which use that flag. `strip-priv-imports` only removes non-pub `use` statements, so it should be harmless from a documentation standpoint to remove those items from "private items" documentation.
Auto merge of #52355 - pietroalbini:zfeature, r=eddyb
Add the -Zcrate-attr=foo unstable rustc option
This PR adds a new unstable option to `rustc`: `-Zcrate-attr=foo`. The option can be used to inject crate-level attributes from the CLI, and it's meant to be used by tools like Crater that needs to add their own attributes to a crate without changing the source code.
The exact reason I need this is to implement "edition runs" in Crater: we need to add the preview feature flag to every crate, and editing the crates' source code on the fly might produce unexpected results, while a compiler flag is more reliable.
cc https://github.com/rust-lang-nursery/crater/issues/282 @Mark-Simulacrum
Auto merge of #52546 - nikomatsakis:issue-52050, r=pnkfelix
do not overwrite child def-id in place but rather remove/insert
When inserting a node N into the tree of impls, we sometimes find than an existing node C should be replaced with N. We used to overwrite C in place with the new def-id N -- but since the lists of def-ids are separated by simplified type, that could lead to N being inserted in the wrong place. This meant we might miss conflicts. We are now not trying to be so smart -- we remove C and then add N later.
Fixes #52050
r? @aturon -- do you still remember this code at all? :)
Auto merge of #52711 - eddyb:unsized-manuallydrop, r=nikomatsakis
Change ManuallyDrop<T> to a lang item.
This PR implements the approach @RalfJung proposes in https://internals.rust-lang.org/t/pre-rfc-unions-drop-types-and-manuallydrop/8025 (lang item `struct` instead of `union`).
A followup PR can easily solve #47034 as well, by just adding a few `?Sized` to `libcore/mem.rs`.
- #52702 (Suggest fix when encountering different mutability from impl to trait)
- #52703 (Improve a few vectors - calculate capacity or build from iterators)
- #52740 (Suggest underscore when using dashes in crate namet push fork)
- #52759 (Impl Send & Sync for JoinHandle)
- #52760 (rustc_metadata: test loading atoi instead of cos)
- #52763 (Omit the vendor component in Fuchsia triple)
- #52765 (Remove unused "-Zenable_nonzeroing_move_hints" flag)
- #52769 (Incorporate a stray test)
- #52777 (Fix doc comment for 'ptr::copy_to' method)
- #52779 (revert accidental atty downgrade)
- #52781 (Use a slice where a vector is not necessary)
Rollup merge of #52769 - sinkuu:stray_test, r=alexcrichton
Incorporate a stray test
`liballoc/repeat-generic-slice.rs` doesn't seem to be tested (I think it was intended to be placed in `run-pass`). This PR incorporates the test into `liballoc/tests`.
Rollup merge of #52763 - petrhosek:fuchsia-triple, r=alexcrichton
Omit the vendor component in Fuchsia triple
Previously, using unknown as the vendor value would lead to the same
result, but with the multiarch runtimes support in Clang, the target is
now used to locate the runtime libraries and so the format is important.
The denormalized format with omitted vendor component is the format we
use with Clang and should be using for Rust as well.
Rollup merge of #52760 - cuviper:test_loading_atoi, r=alexcrichton
rustc_metadata: test loading atoi instead of cos
Some platforms don't actually have `libm` already linked in the test
infrastructure, and then `dynamic_lib::tests::test_loading_cosine` would
fail to find the "cos" symbol. Every platform running this test should
have `libc` and "atoi" though, so try to use that symbol instead.
Rollup merge of #52759 - stjepang:impl-send-sync-for-joinhandle, r=TimNN
Impl Send & Sync for JoinHandle
This is just a cosmetic change - it slightly relaxes and clarifies the public API without effectively promising any new guarantees.
Currently we have [these auto trait implementations](https://doc.rust-lang.org/nightly/std/thread/struct.JoinHandle.html#synthetic-implementations):
```rust
impl<T: Send> Send for JoinHandle<T> {}
impl<T: Sync> Sync for JoinHandle<T> {}
```
Bound `T: Send` doesn't make much sense because `JoinHandle<T>` can be created only when `T: Send`. Note that [`JoinHandle::<T>::join`](https://doc.rust-lang.org/nightly/std/thread/struct.JoinHandle.html#method.join) doesn't require `T: Send` so why should the `Send` impl?
And the `Sync` impl doesn't need `T: Sync` because `JoinHandle<T>` cannot even share `T` - it can only send it to the thread that calls `join`.
Auto merge of #52678 - matthewjasper:better-spans, r=nikomatsakis
[NLL] Use better spans in some errors
* Use the span of the discriminant and patterns for "fake" statements created to properly check matches. I plan to special case these soon, but this felt like a good first step
* Use the span of the statement, rather than the initialization, when reporting move errors for `let x = ...`, which avoids giving an unhelpful suggestion to use `&{ }`.
Auto merge of #52770 - pietroalbini:bump-bootstrap, r=Mark-Simulacrum
Bump bootstrap compiler
This PR bumps the bootstrap compiler to the latest beta, `beta-2017-07-27`. That should be the latest beta with relevant changes (the only nominated PR at the moment is a docs change).
Auto merge of #52733 - pnkfelix:issue-51348-make-temp-for-each-candidate-in-arm, r=nikomatsakis
[NLL] make temp for each candidate in `match` arm
In NLL, `ref mut` patterns leverage the two-phase borrow infrastructure to allow the shared borrows within a guard before the "activation" of the mutable borrow when we begin execution of the match arm's body. (There is further discussion of this on PR #50783.)
To accommodate the restrictions we impose on two-phase borrows (namely that there is a one-to-one mapping between each activation and the original initialization), this PR is making separate temps for each candidate pattern. So in an arm like this:
```rust
PatA(_, ref mut ident) |
PatB(ref mut ident) |
PatC(_, _, ref mut ident) |
PatD(ref mut ident) if guard_stuff(ident) => ...
```
instead of 3 temps (two for the guard and one for the arm body), we now have 4 + 2 temps associated with `ident`: one for each candidate plus the actual temp that the guard uses directly, and then the sixth is the temp used in the arm body.
Auto merge of #52681 - pnkfelix:z-borrowck-migrate, r=nikomatsakis
Add `-Z borrowck=migrate`
This adds `-Z borrowck=migrate`, which represents the way we want to migrate to NLL under Rust versions to come. It also hooks this new mode into `--edition 2018`, which means we're officially turning NLL on in the 2018 edition.
The basic idea of `-Z borrowck=migrate` that there are cases where NLL is fixing old soundness bugs in the borrow-checker, but in order to avoid just breaking code by immediately rejecting the programs that hit those soundness bugs, we instead use the following strategy:
If your code is accepted by NLL, then we accept it.
If your code is rejected by both NLL and the old AST-borrowck, then we reject it.
If your code is rejected by NLL but accepted by the old AST-borrowck, then we emit the new NLL errors as **warnings**.
These warnings will be turned into hard errors in the future, and they say so in these diagnostics.
Petr Hosek [Fri, 27 Jul 2018 00:57:20 +0000 (17:57 -0700)]
Omit the vendor component in Fuchsia triple
Previously, using unknown as the vendor value would lead to the same
result, but with the multiarch runtimes support in Clang, the target is
now used to locate the runtime libraries and so the format is important.
The denormalized format with omitted vendor component is the format we
use with Clang and should be using for Rust as well.
Josh Stone [Fri, 27 Jul 2018 00:20:02 +0000 (17:20 -0700)]
rustc_metadata: test loading atoi instead of cos
Some platforms don't actually have `libm` already linked in the test
infrastructure, and then `dynamic_lib::tests::test_loading_cosine` would
fail to find the "cos" symbol. Every platform running this test should
have `libc` and "atoi" though, so try to use that symbol instead.
Auto merge of #52735 - Mark-Simulacrum:rollup, r=Mark-Simulacrum
Rollup of 16 pull requests
Successful merges:
- #52558 (Add tests for ICEs which no longer repro)
- #52610 (Clarify what a task is)
- #52617 (Don't match on region kinds when reporting NLL errors)
- #52635 (Fix #[linkage] propagation though generic functions)
- #52647 (Suggest to take and ignore args while closure args count mismatching)
- #52649 (Point spans to inner elements of format strings)
- #52654 (Format linker args in a way that works for gcc and ld)
- #52667 (update the stdsimd submodule)
- #52674 (Impl Executor for Box<E: Executor>)
- #52690 (ARM: expose `rclass` and `dsp` target features)
- #52692 (Improve readability in a few sorts)
- #52695 (Hide some lints which are not quite right the way they are reported to the user)
- #52718 (State default capacity for BufReader/BufWriter)
- #52721 (std::ops::Try impl for std::task::Poll)
- #52723 (rustc: Register crates under their real names)
- #52734 (sparc ABI issue - structure returning from function is returned in 64bit registers (with tests))
Auto merge of #52488 - nikomatsakis:nll-issue-48071-universe-and-sub, r=pnkfelix
introduce universes to NLL type check
This branch aims to fix #48071 and also advance chalk integration a bit at the same time. It re-implements the subtyping/type-equating check so that NLL doesn't "piggy back" on the subtyping code of the old type checker.
This new code uses the "universe-based" approach to handling higher-ranked lifetimes, which sidesteps some of the limitations of the current "leak-based" scheme. This avoids the ICE in #48071.
At the same time, I aim for this to potentially be a kind of optimization. This NLL code is (currently) not cached, but it also generates constraints without doing as much instantiation, substitution, and folding. Right now, though, it still piggy backs on the `relate_tys` trait, which is a bit unfortunate -- it means we are doing more hashing and things than we have to. I want to measure the see the perf. Refactoring that trait is something I'd prefer to leave for follow-up work.
r? @pnkfelix -- but I want to measure perf etc first
Mark Rousskov [Thu, 26 Jul 2018 15:18:41 +0000 (09:18 -0600)]
Rollup merge of #52723 - alexcrichton:fix-extern-rename-ice, r=estebank
rustc: Register crates under their real names
Whenever we register a crate into the crate store, make sure to use the real
name mentioned in the metadata instead of the name mentioned in the `extern
crate` statement, as the statement can be wrong!
Mark Rousskov [Thu, 26 Jul 2018 15:18:40 +0000 (09:18 -0600)]
Rollup merge of #52721 - cramertj:try-poll, r=aturon
std::ops::Try impl for std::task::Poll
I originally left out the `Try` impl for `Poll` because I was curious if we needed it, and @MajorBreakfast and I had discussed the potential for it to introduce confusion about exactly what control-flow was happening at different points. However, after porting a pretty significant chunk of Fuchsia over to futures 0.3, I discovered that I was *constantly* having to do repetitive matching on `Poll<Result<...>>` or `Poll<Option<Result<...>>>` in order to propagate errors correctly. `try_poll` (propagate `Poll::Ready(Err(..))`s) helped in some places, but it was far more common to need some form of conversion between `Result`, `Poll<Result<...>>`, and `Poll<Option<Result<...>>>`. The `Try` trait conveniently provides all of these conversions in addition to a more concise syntax (`?`), so I'd like to experiment with using these instead.
cc @seanmonstar
r? @aturon
Note: this change means that far more futures 0.1 code can work without significant changes since it papers over the fact that `Result` is no longer at the top-level when using `Stream` and `Future` (since it's now `Poll<Result<...>>` or `Poll<Option<Result<...>>>` instead of `Result<Poll<..>>` and `Result<Poll<Option<...>>>`).
Mark Rousskov [Thu, 26 Jul 2018 15:18:31 +0000 (09:18 -0600)]
Rollup merge of #52654 - alecmocatta:master, r=alexcrichton
Format linker args in a way that works for gcc and ld
Pass multiple linker arguments rather than concatenate with commas (fixes #52634).
`-l library` -> `-llibrary` to work with apple's ld.
To build with apple's ld I'm currently also passing `-C link-args="-arch x86_64 -macosx_version_min 10.13.0"`. I'll try and understand the latter flag better before PRing that.
This PR currently works for me. Hopefully CI will pick up any grievous ramifications in other toolchains?
Thanks to @alexcrichton for the pointer to the relevant code!
Mark Rousskov [Thu, 26 Jul 2018 15:18:30 +0000 (09:18 -0600)]
Rollup merge of #52649 - estebank:fmt-span, r=oli-obk
Point spans to inner elements of format strings
- Point at missing positional specifiers in string literal
```
error: invalid reference to positional arguments 3, 4 and 5 (there are 3 arguments)
--> $DIR/ifmt-bad-arg.rs:34:38
|
LL | format!("{name} {value} {} {} {} {} {} {}", 0, name=1, value=2);
| ^^ ^^ ^^
|
= note: positional arguments are zero-based
```
- Point at named formatting specifier in string literal
```
error: there is no argument named `foo`
--> $DIR/ifmt-bad-arg.rs:37:17
|
LL | format!("{} {foo} {} {bar} {}", 1, 2, 3);
| ^^^^^
```
- Update label for formatting string in "multiple unused formatting arguments" to be more correct
```
error: multiple unused formatting arguments
--> $DIR/ifmt-bad-arg.rs:42:17
|
LL | format!("", 1, 2); //~ ERROR: multiple unused formatting arguments
| -- ^ ^
| |
| multiple missing formatting specifiers
```
- When using `printf` string formatting, provide a structured suggestion instead of a note
```
error: multiple unused formatting arguments
--> $DIR/format-foreign.rs:12:30
|
LL | println!("%.*3$s %s!/n", "Hello,", "World", 4); //~ ERROR multiple unused formatting arguments
| -------------- ^^^^^^^^ ^^^^^^^ ^
| |
| multiple missing formatting specifiers
|
= note: printf formatting not supported; see the documentation for `std::fmt`
help: format specifiers in Rust are written using `{}`
|
LL | println!("{:.2$} {}!/n", "Hello,", "World", 4); //~ ERROR multiple unused formatting arguments
| ^^^^^^ ^^
```
Mark Rousskov [Thu, 26 Jul 2018 15:18:25 +0000 (09:18 -0600)]
Rollup merge of #52610 - MajorBreakfast:task-terminology, r=cramertj
Clarify what a task is
Currently we call two distinct concepts "task":
1. The top-level future that is polled until completion
2. The lightweight "thread" that is responsible for polling the top-level future. What additional data beside the future is stored in this type varies between different `Executor` implementations.
I'd prefer to return to the old formulation by @alexcrichton:
```rust
/// A handle to a "task", which represents a single lightweight "thread" of
/// execution driving a future to completion.
pub struct Task {
```
Source: [`task_impl/mod.rs` in futures-rs 0.1](https://github.com/rust-lang-nursery/futures-rs/blob/1328fc9e8af5737183df477c7501e6ea24ff2053/src/task_impl/mod.rs#L49-L50)
I think that this change will make it much easier to explain everything.
projects / rust.git / log