bors [Mon, 29 Jun 2020 00:43:19 +0000 (00:43 +0000)]
Auto merge of #73032 - yoshuawuyts:stabilize-leading_trailing_ones, r=Amanieu
stabilize leading_trailing_ones
This PR stabilizes the `leading_trailing_ones` feature. It's been available on nightly since the start of the year, and hasn't had any issues since. It seems unlikely we'll want to change this, so following up on @djc's suggestion in https://github.com/rust-lang/rust/issues/57969#issuecomment-638405264 I'd like to put forward this PR to stabilize the feature and make it part of `1.46.0`. Thanks!
bors [Sun, 28 Jun 2020 20:47:52 +0000 (20:47 +0000)]
Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match, r=oli-obk
Stabilize `#![feature(const_if_match)]`
Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045):
> `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following:
>
> - The initializer of a `const`, `static`, `static mut` or enum discriminant.
> - The body of a `const fn`.
> - The value of a const generic (nightly only).
> - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`).
>
> Furthermore, the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result, `let` bindings can be used alongside short-circuiting logic in those initializers.
Resolves #49146.
Ideally, we would resolve :whale: #66753 before this lands on stable, so it might be worth pushing this back a release. Also, this means we should get the process started for #52000, otherwise people will have no recourse except recursion for iterative `const fn`.
bors [Sun, 28 Jun 2020 16:44:29 +0000 (16:44 +0000)]
Auto merge of #73838 - Manishearth:rollup-jj57e84, r=Manishearth
Rollup of 9 pull requests
Successful merges:
- #73577 (Add partition_point)
- #73757 (Const prop: erase all block-only locals at the end of every block)
- #73774 (Make liveness more precise for assignments to fields)
- #73795 (Add some `const_compare_raw_pointers`-related regression tests)
- #73800 (Forward Hash::write_iN to Hash::write_uN)
- #73813 (Rename two `Resolver` traits)
- #73817 (Rename clashing_extern_decl to clashing_extern_declarations.)
- #73826 (Fix docstring typo)
- #73833 (Remove GlobalCtxt::enter_local)
Rollup merge of #73813 - petrochenkov:restrait, r=davidtwco
Rename two `Resolver` traits
`trait Resolver` -> `trait ResolverExpand` for the resolver interface available from expansion.
`trait Resolver` -> `trait ResolverAstLowering` for the resolver interface available from AST lowering.
The `Hasher::write_iN()` methods should forward to `Hasher::write_uN()`, because some Hasher implementations implement only the `write_uN()` variants, with the expectation that `write_iN()` will use the same implementation. Most notably, this is the case for the [FxHasher](https://github.com/rust-lang/rustc-hash/blob/5e09ea0a1c7ab7e4f9e27771f5a0e5a36c58d1bb/src/lib.rs#L111) used by rustc itself.
This used to be the case previously, but was broken in #59982. As the PR description makes no mention of this particular change, I assume it was unintentional.
In a local test, this mitigates the regression from #73526 on at least one test-case (cc @cuviper), because we're no longer at the mercy of `FxHasher::write()` getting inlined to get reasonable performance.
Rollup merge of #73774 - ecstatic-morse:liveness-of-projections, r=oli-obk
Make liveness more precise for assignments to fields
Previously, we were too conservative and `x.field = 4` was treated as a "use" of `x`. Now it neither kills `x` (since other fields of `x` may still be live) nor marks it as live.
Rollup merge of #73757 - oli-obk:const_prop_hardening, r=wesleywiser
Const prop: erase all block-only locals at the end of every block
I messed up this erasure in https://github.com/rust-lang/rust/pull/73656#discussion_r446040140. I think it is too fragile to have the previous scheme. Let's benchmark the new scheme and see what happens.
Rollup merge of #73577 - VillSnow:master, r=Amanieu
Add partition_point
Add partition_point in C++.
Although existing binary_search in rust does not suitable when the slice has multiple hits,
this function returns exact point of partition.
The definition of this function is very clear and able to accept general matter, therefore you can easily get index which you want like lower/upper_bound.
bors [Sun, 28 Jun 2020 08:26:22 +0000 (08:26 +0000)]
Auto merge of #73830 - Manishearth:rollup-8k68ysm, r=Manishearth
Rollup of 10 pull requests
Successful merges:
- #72796 (MIR sanity check: validate types on assignment)
- #73243 (Add documentation to point to `File::open` or `OpenOptions::open` instead of `is_file` to check read/write possibility)
- #73525 (Prepare for LLVM 11)
- #73672 (Adds a clearer message for when the async keyword is missing from a f…)
- #73708 (Explain move errors that occur due to method calls involving `self` (take two))
- #73758 (improper_ctypes: fix remaining `Reveal:All`)
- #73763 (errors: use `-Z terminal-width` in JSON emitter)
- #73796 (replace more `DefId`s with `LocalDefId`)
- #73797 (fix typo in self-profile.md)
- #73809 (Add links to fs::DirEntry::metadata)
Rollup merge of #73809 - robyoung:docs/add-links-to-DirEntry-metadata, r=hanna-kruppe
Add links to fs::DirEntry::metadata
`fs::DirEntry::metadata` doesn't traverse symlinks. It is not immediately clear what to do if you do want to traverse symlinks. This change adds links to the two other `metadata` functions that will follow symlinks.
Rollup merge of #73758 - davidtwco:issue-60855-remaining-reveal-all, r=matthewjasper
improper_ctypes: fix remaining `Reveal:All`
Fixes #60855.
This PR replaces the remaining uses of `ParamEnv::reveal_all` with `LateContext`'s `param_env` (normally `Reveal::UserFacing`) in the improper ctypes lint.
Rollup merge of #73708 - Aaron1011:feature/reland-move-fn-self-msg, r=davidtwco
Explain move errors that occur due to method calls involving `self` (take two)
This is a re-attempt of #72389 (which was reverted in #73594)
Instead of using `ExpnKind::Desugaring` to represent operators, this PR
checks the lang item directly.
Rollup merge of #73672 - nellshamrell:async-fix, r=estebank
Adds a clearer message for when the async keyword is missing from a f…
…unction
This is a somewhat simple fix for #66731.
Under the current version of Rust, if a user has a rust file that looks like this:
```rust
fn boo (){}
async fn foo() {
boo().await;
}
fn main() {
}
```
And they attempt to run it, they will receive an error message that looks like this:
```bash
error: incorrect use of `await` --> test.rs:4:14 | 4 | boo.await(); | ^^ help: `await` is not a method call, remove the parentheses error[E0277]: the trait bound `fn() {boo}: std::future::Future` is not satisfied --> test.rs:4:5 | 4 | boo.await(); | ^^^^^^^^^ the trait `std::future::Future` is not implemented for `fn() {boo}` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`.
```
This is not very clear.
With the changes made in this PR, when a user compiles and runs that same rust code, they will receive an error message that looks like this:
```bash
error[E0277]: `()` is not a future.
--> test.rs:4:5
|
4 | boo().await;
| ^^^^^^^^^^^ `()` is not a future
|
= help: the trait `std::future::Future` is not implemented for `()`
= note: required by `std::future::Future::poll`
```
In the future, I think we should make this error message even clearer, perhaps through a solution like the one described in [this comment](https://github.com/rust-lang/rust/issues/66731#issuecomment-644394287). However, as that potentially involves a major change proposal, I would rather get this change in now and make the error message a little clearer while an MCP is drafted and discussed.
Rollup merge of #72796 - RalfJung:mir-assign-sanity, r=matthewjasper
MIR sanity check: validate types on assignment
This expands the MIR validation added by @jonas-schievink in https://github.com/rust-lang/rust/pull/72093 to also check that on an assignment, the types of both sides match.
bors [Sun, 28 Jun 2020 04:16:52 +0000 (04:16 +0000)]
Auto merge of #72705 - Lucretiel:stdio-forwarding, r=Amanieu
Added io forwarding methods to the stdio structs
Added methods to forward the `io::Read` and `io::Write` methods of the myriad wrapper structs in `stdio.rs` to their underlying readers / writers. This is especially important for the structs on the outside of a locking boundary, to ensure that the lock isn't being dropped and re-acquired in a loop.
bors [Sat, 27 Jun 2020 20:14:34 +0000 (20:14 +0000)]
Auto merge of #73671 - ehuss:update-mdbook, r=Mark-Simulacrum
Update mdbook
This updates mdbook to 0.4. The list of changes can be found at https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-040. I think the most important one is the change to include fonts with the book instead of using the Google Fonts CDN. This adds a few megabytes of fonts to the docs component. It may be possible to share the fonts across the books, but would take a fair bit of work to make that happen, so I'm not sure if it is necessary.
This also removes mdbook-linkcheck. It is currently not being used, and I don't foresee it going back into use anytime soon. I would prefer not to maintain something that isn't being used, and it removes a very large number of dependencies.
Rob Young [Sat, 27 Jun 2020 18:32:19 +0000 (19:32 +0100)]
Add links to fs::DirEntry::metadata
`fs::DirEntry::metadata` doesn't traverse symlinks. It is not immediately
clear what to do if you do want to traverse symlinks. This change adds
links to the two other `metadata` functions that will follow symlinks.
Treat any line starting with `!#` as a shebang candidate, not only lines with something non-whitespace.
This way we no longer need to define what `is_whitespace` means ([Linux shebang whitespace](https://github.com/torvalds/linux/blob/master/fs/binfmt_script.c), ASCII whitespace, Rust lexer whitespace, etc), which is nice.
This change makes some invalid Rust code valid (see the regression above), but still never interprets a fragment of valid Rust code as a shebang.
Rollup merge of #73627 - ssomers:btree_iter_min_max, r=Mark-Simulacrum
Shortcuts for min/max on double-ended BTreeMap/BTreeSet iterators
Closes #59947: a performance tweak that might benefit some. Optimizes `min` and `max ` on all btree double-ended iterators that do not drop, i.e. the iterators created by:
- `BTreeMap::iter`
- `BTreeMap::iter_mut`
- `BTreeMap::keys` and `BTreeSet::iter`
- `BTreeMap::range` and `BTreeSet::range`
- `BTreeMap::range_mut`
Also in these (currently) single-ended iterators, but obviously for `min` only:
- `BTreeSet::difference`
- `BTreeSet::intersection`
- `BTreeSet::symmetric_difference`
- `BTreeSet::union`
Did not do this in iterators created by `into_iter` to preserve drop order, as outlined in #62316.
Did not do this in iterators created by `drain_filter`, possibly to preserve drop order, possibly to preserve predicate invocation, mostly to not have to think about it too hard (I guess maybe it wouldn't be a change for `min`, which is the only shortcut possible in this single-ended iterator).
Aaron Hill [Thu, 11 Jun 2020 17:48:46 +0000 (13:48 -0400)]
Explain move errors that occur due to method calls involving `self`
This is a re-attempt of #72389 (which was reverted in #73594)
Instead of using `ExpnKind::Desugaring` to represent operators, this PR
checks the lang item directly.
bors [Fri, 26 Jun 2020 14:08:46 +0000 (14:08 +0000)]
Auto merge of #73513 - oli-obk:const_binop_overflow, r=estebank
Show the values and computation that would overflow a const evaluation or propagation
Fixes #71134
In contrast to the example in the issue it doesn't use individual spans for each operand. The effort required to implement that is quite high compared to the little (if at all) benefit it would bring to diagnostics.
cc @shepmaster
The way this is implemented it is also fairly easy to do the same for overflow panics at runtime, but that should be done in a separate PR since it may have runtime performance implications.
Joshua Nelson [Sat, 30 May 2020 15:35:35 +0000 (11:35 -0400)]
Generate docs for links to private items when passed --document-private
- Pass around document_private a lot more
- Add tests
+ Add tests for intra-doc links to private items
+ Add ignored tests for warnings in reference links
bors [Fri, 26 Jun 2020 10:11:43 +0000 (10:11 +0000)]
Auto merge of #73756 - Manishearth:rollup-aehswb2, r=Manishearth
Rollup of 13 pull requests
Successful merges:
- #72620 (Omit DW_AT_linkage_name when it is the same as DW_AT_name)
- #72967 (Don't move cursor in search box when using arrows to navigate results)
- #73102 (proc_macro: Stop flattening groups with dummy spans)
- #73297 (Support configurable deny-warnings for all in-tree crates.)
- #73507 (Cleanup MinGW LLVM linkage workaround)
- #73588 (Fix handling of reserved registers for ARM inline asm)
- #73597 (Record span of `const` kw in GenericParamKind)
- #73629 (Make AssocOp Copy)
- #73681 (Update Chalk to 0.14)
- #73707 (Fix links in `SliceIndex` documentation)
- #73719 (emitter: column width defaults to 140)
- #73729 (disable collectionbenches for android)
- #73748 (Add code block to code in documentation of `List::rebase_onto`)
Rollup merge of #73719 - davidtwco:issue-72509-emitter-column-width, r=estebank
emitter: column width defaults to 140
Fixes #72509.
This PR modifies the column width computation in the emitter when `termize::dimensions` returns `None` so that it uses the default value of 140 (which is used in UI testing currently) instead of `usize::MAX` which just ends up causing overflows in later computations.
I also tried changing the computations which used `column_width` with their saturating equivalent, but the output appeared the same - so I decided to go with this approach because I feel like it's less likely to accidentally re-introduce an ICE like this in future (e.g. adding a non-saturating operation on `column_width` in future).
I haven't added a test because I couldn't come up with a MCVE. I stumbled upon this running rustc-perf with the `piston-image` benchmark (running in tmux; it only happened with stage two builds only; and only when running through Cargo, not rustc directly with the same flags). In addition, given the nature of the issue, I don't know that we *could* write a UI test for this. Open to suggestions here though.
Rollup merge of #73707 - LeSeulArtichaut:patch-3, r=kennytm
Fix links in `SliceIndex` documentation
See [this doc](https://doc.rust-lang.org/nightly/std/slice/trait.SliceIndex.html#tymethod.get_unchecked) whose links aren't active because of this missing newline.
Rollup merge of #73681 - jackh726:chalk-0.14, r=nikomatsakis
Update Chalk to 0.14
Not a ton here. Notable changes:
- Update to `0.14.0`
- New dependency on `tracing`, in `librustc_traits` only
- `FnAbi` from Chalk is `rustc_target::spec::abi::Abi`
- `Dynamic` actually lowers region
- Actually lower closures, with some tests. This doesn't 100% work, but can't confirm that's *only* because of closure lowering.
- Use `FxIndexSet` instead of `FxHashSet` in `chalk_fulfill`, which seems to have fixed the non-deterministic test error ordering. Guess we'll see on CI
- Actually implement `opaque_ty_data`, though I don't think this is sufficient for tests for them (I haven't added any)
- Uncomment some of the chalk tests that now work
projects / rust.git / log