Those changes were incompatible with incremental compilation since the
effect `check_mod_attrs` has with respect to marking the attributes as
used is neither persisted nor recomputed.
bors [Wed, 26 Feb 2020 16:01:21 +0000 (16:01 +0000)]
Auto merge of #69484 - Dylan-DPC:rollup-j6ripxy, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #68712 (Add methods to 'leak' RefCell borrows as references with the lifetime of the original reference)
- #69209 (Miscellaneous cleanup to formatting)
- #69381 (Allow getting `no_std` from the config file)
- #69434 (rustc_metadata: Use binary search from standard library)
- #69447 (Minor refactoring of statement parsing)
Dylan DPC [Wed, 26 Feb 2020 14:34:32 +0000 (15:34 +0100)]
Rollup merge of #69381 - QuiltOS:no-std-from-config, r=Mark-Simulacrum
Allow getting `no_std` from the config file
Currently, it is only set correctly in the sanity checking implicit
default fallback code. Having a config file at all will for force
`no_std = false`.
Dylan DPC [Wed, 26 Feb 2020 14:34:29 +0000 (15:34 +0100)]
Rollup merge of #68712 - HeroicKatora:finalize-ref-cell, r=dtolnay
Add methods to 'leak' RefCell borrows as references with the lifetime of the original reference
Usually, references to the interior are only created by the `Deref` and
`DerefMut` impl of the guards `Ref` and `RefMut`. Note that `RefCell`
already has to cope with leaks of such guards which, when it occurs,
effectively makes it impossible to ever acquire a mutable guard or any
guard for `Ref` and `RefMut` respectively. It is already safe to use
this to create a reference to the inner of the ref cell that lives as
long as the reference to the `RefCell` itself, e.g.
```rust
fn leak(r: &RefCell<usize>) -> Option<&usize> {
let guard = r.try_borrow().ok()?;
let leaked = Box::leak(Box::new(guard));
Some(&*leaked)
}
```
The newly added methods allow the same reference conversion without an
indirection over a leaked allocation. It's placed on the `Ref`/`RefMut` to
compose with both borrow and try_borrow directly.
bors [Wed, 26 Feb 2020 12:48:53 +0000 (12:48 +0000)]
Auto merge of #67290 - jonas-schievink:leak-audit, r=KodrAus
Audit liballoc for leaks in `Drop` impls when user destructor panics
Inspired by https://github.com/rust-lang/rust/pull/67243 and https://github.com/rust-lang/rust/pull/67235, this audits and hopefully fixes the remaining `Drop` impls in liballoc for resource leaks in the presence of panics in destructors called by the affected `Drop` impl.
This does not touch `Hash{Map,Set}` since they live in hashbrown. They have similar issues though.
bors [Wed, 26 Feb 2020 09:27:06 +0000 (09:27 +0000)]
Auto merge of #61812 - jonas-schievink:assoc-ty-defaults, r=nikomatsakis
Implement RFC 2532 – Associated Type Defaults
This is a partial implementation that is still missing the changes to object types, since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR.
Blockers before this can land:
* [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564
Dylan DPC [Wed, 26 Feb 2020 01:07:12 +0000 (02:07 +0100)]
Rollup merge of #69412 - tmiasko:checked-unused, r=petrochenkov
Mark attributes consumed by `check_mod_attrs` as normal
Take advantage of the fact that `check_mod_attrs` marks attributes as
used and change their type to normal, so that any remaining uses will be
warned about by the unused attribute lint.
Dylan DPC [Wed, 26 Feb 2020 01:07:11 +0000 (02:07 +0100)]
Rollup merge of #69387 - petrochenkov:idprint, r=Mark-Simulacrum
Deduplicate identifier printing a bit
https://github.com/rust-lang/rust/pull/67010 introduced a couple more subtly different ways to print an identifier.
This PR attempts to restore the order.
The most basic identifier printing interface is `Formatter`-based now, so `String`s are not allocated unless required.
bors [Tue, 25 Feb 2020 22:13:27 +0000 (22:13 +0000)]
Auto merge of #69450 - cuviper:llvm-scev-no-wrap, r=nikic
Cherry-pick the LLVM fix for #69225
An additional reproducer was provided in #69225 -- the new testcase here -- which still crashes even after #69241 reverted #67174. Now this pull request updates LLVM with the cherry-picked reversion of its own. This is also going to stable in #69444.
I have not tried to reapply #67174 yet -- cc @kraai @shahn
```
Fix false positive in `missing_const_for_fn`
Rustup to rust-lang/rust#69366
Add new lint [`wildcard imports`]. Add suggestion to [`enum_glob_use`]
Add new lint `lossy_float_literal` to detect lossy whole number float literals
```
bors [Tue, 25 Feb 2020 11:56:56 +0000 (11:56 +0000)]
Auto merge of #69440 - Dylan-DPC:rollup-hj4bo9l, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #69220 (Add documentation for the `-Zself-profile` flag)
- #69391 (Add rustdoc aliases to `ptr::copy` and `ptr::copy_nonoverlapping`)
- #69427 (Cleanup e0368 e0369)
- #69433 (don't explicitly compare against true or false)
- #69435 (Replace uses of Cell::get + Cell::set with Cell::replace.)
- #69437 (no more codegen for miri_start_panic)
John Ericson [Tue, 25 Feb 2020 02:59:36 +0000 (21:59 -0500)]
bootstrap: Further centralize target defaulting logic.
Background: targets can be specied with or without config files;
unneccessarily differences in the logic between those cases has caused
a) the bug I tried to fix in the previous commit, b) the bug I
introduced in the previous commit.
The solution is to make the code paths the same as much as possible.
1. Targets are now not created from the `default` method. (I would both
remove the impl if this was a public library, but just wrap it for
convience becaues it's not.) Instead, there is a `from_triple` method
which does the defaulting.
2. Besides the sanity checking, use the new method in the code reading
config files. Now `no_std` is overriden iff set explicitly just like the
other fields which are optional in the TOML AST type.
3. In sanity checking, just populate the map for all targets no matter
what. That way do don't duplicate logic trying to be clever and remember
which targets have "non standard" overrides. Sanity checking is back to
just sanity checking, and out of the game of trying to default too.
Dylan DPC [Mon, 24 Feb 2020 19:10:19 +0000 (20:10 +0100)]
Rollup merge of #69437 - RalfJung:miri-no-codegen, r=ecstatic-morse
no more codegen for miri_start_panic
With https://github.com/rust-lang/miri/pull/1136 landed, we don't generate code any more for crates that will be run by Miri. So the LLVM backend does not have to implement the `miri_start_panic` intrinsic any more.
Dylan DPC [Mon, 24 Feb 2020 19:10:13 +0000 (20:10 +0100)]
Rollup merge of #69391 - memoryruins:memalias, r=Mark-Simulacrum
Add rustdoc aliases to `ptr::copy` and `ptr::copy_nonoverlapping`
This PR adds a [rustdoc alias](https://doc.rust-lang.org/nightly/rustdoc/unstable-features.html#add-aliases-for-an-item-in-documentation-search) to `ptr::copy` and `ptr::copy_nonoverlapping` using the commonly used terms `memcpy` and `memmove`. The motivation for this PR is to improve discoverability for these functions, since I've noticed users overlook these functions on multiple occasions (and they have thus reached for [libc](https://crates.io/crates/libc) without need). Currently std docs state:
https://doc.rust-lang.org/nightly/std/ptr/fn.copy_nonoverlapping.html
> `copy_nonoverlapping` is semantically equivalent to C's `memcpy`, but with the argument order swapped.
https://doc.rust-lang.org/nightly/std/ptr/fn.copy.html
> `copy` is semantically equivalent to C's `memmove`, but with the argument order swapped.
#### search results before adding a rustdoc alias:
![screenshot 6517](https://user-images.githubusercontent.com/6868531/75102985-78fbb680-55c2-11ea-8e41-04979e6fa6f6.png)
![screenshot 6518](https://user-images.githubusercontent.com/6868531/75102984-78632000-55c2-11ea-9673-8822aae636d1.png)
#### after adding `#[doc(alias = "memcpy")]` and `#[doc(alias = "memmove")]`:
![screenshot 6516](https://user-images.githubusercontent.com/6868531/75102986-78fbb680-55c2-11ea-93b9-1929be940043.png)
![screenshot 6515](https://user-images.githubusercontent.com/6868531/75102987-78fbb680-55c2-11ea-9861-ce8a77a0c3b9.png)
Pietro Albini [Mon, 24 Feb 2020 10:15:36 +0000 (11:15 +0100)]
Rollup merge of #69405 - NieDzejkob:docs-readline-appends, r=joshtriplett
docs: Stdin::read_line: mention the appending
The fact that `stdin().read_line()` is an [unpleasant](https://twitter.com/Michcioperz/status/1231646797661167617?s=20) [footgun](https://rustbattle.net/battle/straight-finch-8-e4f4). Let's make it clearer in the documentation.
Pietro Albini [Mon, 24 Feb 2020 10:15:33 +0000 (11:15 +0100)]
Rollup merge of #69386 - danielhenrymantilla:maybe_uninit_docs_replace_chunk_with_windows, r=Dylan-DPC
Fix minor error in `MaybeUninit::get_mut()` doc example
In the `MaybeUninit::get_mut()` example I wanted to assert that the slice was sorted and mistakenly used `.chunks(2)` rather than `.windows(2)` to assert it, as @ametisf pointed out in https://github.com/rust-lang/rust/pull/65948#issuecomment-589988183 .
Pietro Albini [Mon, 24 Feb 2020 10:15:31 +0000 (11:15 +0100)]
Rollup merge of #69385 - ridiculousfish:relax_get_unchecked, r=nagisa
Relax str::get_unchecked precondition to permit empty slicing
Prior to this commit, `str` documented that `get_unchecked` had
the precondition that "`begin` must come before `end`". This would appear
to prohibit empty slices (i.e. begin == end).
In practice, get_unchecked is called often with empty slices. Let's relax
the precondition so as to allow them.
Pietro Albini [Mon, 24 Feb 2020 10:15:30 +0000 (11:15 +0100)]
Rollup merge of #69372 - yawpitch:master, r=varkor
Updates links in various Compiler Error Index entries
Currently many of the links in the online https://doc.rust-lang.org/error-index.html are not clickable, and many of them don't resolve correctly as they point to older versions of rustbyexample and the reference.
This PR fully unifies item parsing into a single `fn parse_item_common` method which produces `Option<Item>`. The `Item` is then mapped into `ForeignItem` and `AssocItem` as necessary by transforming the `*Kind` and converting contextually bad variants into `None`, thereby filtering them away.
The PR does not yet unmerge the definition of `ForeignItemKind` from `AssocItemKind`. I've left that as future work as it didn't feel like this parser-focused PR would be the best one to deal with it. Changes to the AST data structures are instead kept to a reasonable minimum.
Based on https://github.com/rust-lang/rust/pull/69361.
Fixes https://github.com/rust-lang/rust/issues/48137.
RELNOTES: Now, `item` macro fragments can be interpolated into `impl`, `trait`, and `extern` contexts. See `src/test/ui/parser/issue-48137-macros-cannot-interpolate-impl-items.rs` for the relevant test.
bors [Sun, 23 Feb 2020 16:09:41 +0000 (16:09 +0000)]
Auto merge of #69084 - yaahc:delayed-doc-lint, r=petrochenkov
Split non macro portion of unused_doc_comment from macro part into two passes/lints
## Motivation
This change is motivated by the needs of the [spandoc library](https://github.com/yaahc/spandoc). The specific use case is that my macro is removing doc comments when an attribute is applied to a fn with doc comments, but I would like the lint to still appear when I forget to add the `#[spandoc]` attribute to a fn, so I don't want to have to silence the lint globally.
## Approach
This change splits the `unused _doc_comment` lint into two lints, `unused_macro_doc_comment` and `unused_doc_comment`. The non macro portion is moved into an `early_lint_pass` rather than a pre_expansion_pass. This allows proc macros to silence `unused_doc_comment` warnings by either adding an attribute to silence it or by removing the doc comment before the early_pass runs.
The `unused_macro_doc_comment` lint however will still be impossible for proc-macros to silence, but the only alternative that I can see is to remove this lint entirely, which I don't think is acceptable / is a decision I'm not comfortable making personally, so instead I opted to split the macro portion of the check into a separate lint so that it can be silenced globally with an attribute if necessary without needing to globally silence the `unused_doc_comment` lint as well, which is still desireable.
bors [Sun, 23 Feb 2020 09:40:18 +0000 (09:40 +0000)]
Auto merge of #69336 - Mark-Simulacrum:no-infra-toolstate, r=Dylan-DPC
Do not ping the infrastructure team on toolstate changes
To my knowledge, there is essentially never any particular action that the infra team needs to take on these pings, and they are currently relatively annoying.
cc rust-lang/infra -- does anyone *want* these notifications?
Dylan DPC [Sun, 23 Feb 2020 08:57:38 +0000 (09:57 +0100)]
Rollup merge of #69336 - Mark-Simulacrum:no-infra-toolstate, r=Dylan-DPC
Do not ping the infrastructure team on toolstate changes
To my knowledge, there is essentially never any particular action that the infra team needs to take on these pings, and they are currently relatively annoying.
cc rust-lang/infra -- does anyone *want* these notifications?
Tomasz Miąsko [Sun, 23 Feb 2020 00:00:00 +0000 (00:00 +0000)]
Mark attributes consumed by `check_mod_attrs` as normal
Take advantage of the fact that `check_mod_attrs` marks attributes as
used and change their type to normal, so that any remaining uses will be
warned about by the unused attribute lint.
ridiculousfish [Sat, 22 Feb 2020 21:28:53 +0000 (13:28 -0800)]
Relax str::get_unchecked precondition to permit empty slicing
Prior to this commit, `str` documented that `get_unchecked` had
the precondition that "`begin` must come before `end`". This would appear
to prohibit empty slices (i.e. begin == end).
In practice, get_unchecked is called often with empty slices. Let's relax
the precondition so as to allow them.
John Ericson [Sat, 22 Feb 2020 19:38:38 +0000 (14:38 -0500)]
Allow getting `no_std` from the config file
Currently, it is only set correctly in the sanity checking implicit
default fallback code. Having a config file at all will for force
`no_std = false`.