Rollup merge of #69539 - Centril:fix-69401, r=petrochenkov
late resolve, visit_fn: bail early if there's no body.
Fixes https://github.com/rust-lang/rust/issues/69401 which was injected by https://github.com/rust-lang/rust/commit/b2c6eeb713d4cf9b35b7dda6ff2b0274e7f24684 in https://github.com/rust-lang/rust/pull/68788.
So, after https://github.com/rust-lang/rust/pull/69006, its follow-ups and an attempt to remove `Parser::prev_span` I came to the conclusion that the unnormalized token and its span is what you want in most cases, so it should be default.
Normalization only makes difference in few cases where we are checking against `token::Ident` or `token::Lifetime` specifically.
This PR uses `normalized_token` for those cases.
Using normalization explicitly means that people writing code should remember about `NtIdent` and `NtLifetime` in general. (That is alleviated by the fact that `token.ident()` and `fn parse_ident_*` are already written.)
Remembering about `NtIdent`, was, however, already the case, kind of, because the implicit normalization was performed only for the current/previous token, but not for things like `look_ahead`.
As a result, most of token classification methods in `token.rs` already take `NtIdent` into account (this PR fixes a few pre-existing minor mistakes though).
The next step is removing `normalized(_prev)_token` entirely and replacing it with `token.ident()` (mostly) and `token.normalize()` (occasionally).
I want to make it a separate PR for that and run it though perf.
`normalized_token` filled on every bump has both a potential to avoid repeated normalization, and to do unnecessary work in advance (it probably doesn't matter anyway, the normalization is very cheap).
On `Self(...)` (that is, a `Res::SelfCtor`), do not use `self.impl_self_ty(...)`. The problem with that method is that it creates unconstrained inference variables for type parameters in the `impl` (e.g. `impl<T> S0<T>`). These variables then eventually get substituted for something else when they come in contact with the expected type (e.g. `S0<u8>`) or merely the arguments passed to the tuple constructor (e.g. the `0` in `Self(0)`).
Instead of using `self.impl_self_ty(...)`, we instead merely use `let ty = self.normalize_ty(span, tcx.at(span).type_of(impl_def_id));` to get the rewritten `res`.
bors [Fri, 28 Feb 2020 09:32:34 +0000 (09:32 +0000)]
Auto merge of #68827 - ssomers:btree_navigation_revisited, r=Mark-Simulacrum
BTreeMap navigation done safer & faster
It turns out that there was a faster way to do the tree navigation code bundled in #67073, by moving from edge to KV and from KV to next edge separately. It extracts most of the code as safe functions, and contains the duplication of handles within the short wrapper functions.
This somehow hits a sweet spot in the compiler because it reports boosts all over the board:
```
>cargo benchcmp pre3.txt posz4.txt --threshold 5
name pre3.txt ns/iter posz4.txt ns/iter diff ns/iter diff % speedup
btree::map::first_and_last_0 40 37 -3 -7.50% x 1.08
btree::map::first_and_last_100 58 44 -14 -24.14% x 1.32
btree::map::iter_1000 8,920 3,419 -5,501 -61.67% x 2.61
btree::map::iter_100000 1,069,290 411,615 -657,675 -61.51% x 2.60
btree::map::iter_20 169 58 -111 -65.68% x 2.91
btree::map::iter_mut_1000 8,701 3,303 -5,398 -62.04% x 2.63
btree::map::iter_mut_100000 1,034,560 405,975 -628,585 -60.76% x 2.55
btree::map::iter_mut_20 165 58 -107 -64.85% x 2.84
btree::set::clone_100 1,831 1,562 -269 -14.69% x 1.17
btree::set::clone_100_and_clear 1,831 1,565 -266 -14.53% x 1.17
btree::set::clone_100_and_into_iter 1,917 1,541 -376 -19.61% x 1.24
btree::set::clone_100_and_pop_all 2,609 2,441 -168 -6.44% x 1.07
btree::set::clone_100_and_remove_all 4,598 3,927 -671 -14.59% x 1.17
btree::set::clone_100_and_remove_half 2,765 2,551 -214 -7.74% x 1.08
btree::set::clone_10k 191,610 164,616 -26,994 -14.09% x 1.16
btree::set::clone_10k_and_clear 192,003 164,616 -27,387 -14.26% x 1.17
btree::set::clone_10k_and_into_iter 200,037 163,010 -37,027 -18.51% x 1.23
btree::set::clone_10k_and_pop_all 267,023 250,913 -16,110 -6.03% x 1.06
btree::set::clone_10k_and_remove_all 536,230 464,100 -72,130 -13.45% x 1.16
btree::set::clone_10k_and_remove_half 453,350 430,545 -22,805 -5.03% x 1.05
btree::set::difference_random_100_vs_100 1,787 801 -986 -55.18% x 2.23
btree::set::difference_random_100_vs_10k 2,978 2,696 -282 -9.47% x 1.10
btree::set::difference_random_10k_vs_100 111,075 54,734 -56,341 -50.72% x 2.03
btree::set::difference_random_10k_vs_10k 246,380 175,980 -70,400 -28.57% x 1.40
btree::set::difference_staggered_100_vs_100 1,789 951 -838 -46.84% x 1.88
btree::set::difference_staggered_100_vs_10k 2,798 2,606 -192 -6.86% x 1.07
btree::set::difference_staggered_10k_vs_10k 176,452 97,401 -79,051 -44.80% x 1.81
btree::set::intersection_100_neg_vs_10k_pos 34 32 -2 -5.88% x 1.06
btree::set::intersection_100_pos_vs_100_neg 30 27 -3 -10.00% x 1.11
btree::set::intersection_random_100_vs_100 1,537 613 -924 -60.12% x 2.51
btree::set::intersection_random_100_vs_10k 2,793 2,649 -144 -5.16% x 1.05
btree::set::intersection_random_10k_vs_10k 222,127 147,166 -74,961 -33.75% x 1.51
btree::set::intersection_staggered_100_vs_100 1,447 622 -825 -57.01% x 2.33
btree::set::intersection_staggered_100_vs_10k 2,606 2,382 -224 -8.60% x 1.09
btree::set::intersection_staggered_10k_vs_10k 143,620 58,790 -84,830 -59.07% x 2.44
btree::set::is_subset_100_vs_100 1,349 488 -861 -63.83% x 2.76
btree::set::is_subset_100_vs_10k 1,720 1,428 -292 -16.98% x 1.20
btree::set::is_subset_10k_vs_10k 135,984 48,527 -87,457 -64.31% x 2.80
```
The `first_and_last` ones are noise (they don't do iteration), the others seem genuine.
As always, approved by Miri.
Also, a separate commit with some more benchmarks of mutable behaviour (which also benefit).
bors [Fri, 28 Feb 2020 06:14:52 +0000 (06:14 +0000)]
Auto merge of #68505 - skinny121:canonicalize-const-eval-inputs, r=nikomatsakis
Canonicalize inputs to const eval where needed
Canonicalize inputs to const eval, so that they can contain inference variables. Which enables invoking const eval queries even if the current param env has inference variable within it, which can occur during trait selection.
This is a reattempt of #67717, in a far less invasive way.
bors [Fri, 28 Feb 2020 02:19:31 +0000 (02:19 +0000)]
Auto merge of #69534 - Dylan-DPC:rollup-fwa2lip, r=Dylan-DPC
Rollup of 9 pull requests
Successful merges:
- #69379 (Fail on multiple declarations of `main`.)
- #69430 (librustc_typeck: remove loop that never actually loops)
- #69449 (Do not ping PR reviewers in toolstate breakage)
- #69491 (rustc_span: Add `Symbol::to_ident_string` for use in diagnostic messages)
- #69495 (don't take redundant references to operands)
- #69496 (use find(x) instead of filter(x).next())
- #69501 (note that find(f) is equivalent to filter(f).next() in the docs.)
- #69527 (Ignore untracked paths when running `rustfmt` on repository.)
- #69529 (don't use .into() to convert types into identical types.)
Dylan DPC [Fri, 28 Feb 2020 00:55:42 +0000 (01:55 +0100)]
Rollup merge of #69491 - petrochenkov:symprint, r=Mark-Simulacrum
rustc_span: Add `Symbol::to_ident_string` for use in diagnostic messages
Covers the same error reporting use case (https://github.com/rust-lang/rust/pull/69387#discussion_r382999205) as the `Display` impl for `Ident`.
cc https://github.com/rust-lang/rust/issues/69053
Follow-up to https://github.com/rust-lang/rust/pull/69387.
r? @Mark-Simulacrum
Dylan DPC [Fri, 28 Feb 2020 00:55:35 +0000 (01:55 +0100)]
Rollup merge of #69379 - jumbatm:llvm-sigsegv, r=pnkfelix
Fail on multiple declarations of `main`.
Closes #67946.
Previously, when inserting the entry function, we only checked for
duplicate _definitions_ of `main`. However, it's possible to cause
problems even only having a duplicate _declaration_. For example,
shadowing `main` using an extern block isn't caught by the current
check, and causes an assertion failure down the line in in LLVM code.
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 [Thu, 27 Feb 2020 15:17:47 +0000 (15:17 +0000)]
Auto merge of #68528 - ecstatic-morse:maybe-init-variants, r=oli-obk
Mark other variants as uninitialized after switch on discriminant
During drop elaboration, which builds the drop ladder that handles destruction during stack unwinding, we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM, which should improve performance. In #66753, a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap`, which move out of an `enum`. While discussing possible remedies for that issue, @eddyb suggested moving const-checking after drop elaboration. This would allow the former, which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out, leverage the work done by the latter.
However, it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example, let's look at the code for `unwrap_or`.
`opt` never needs to be dropped, since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`), and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen.
@eddyb also suggested the solution to this problem. When we switch on an enum discriminant, we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`.
In concert with #68943, this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.
Yuki Okushi [Thu, 27 Feb 2020 05:38:02 +0000 (14:38 +0900)]
Rollup merge of #69324 - estebank:ice-break-backport-bad-placeholder-type, r=Centril
Backport only: avoid ICE on bad placeholder type
#69148 has a proper fix, but it is too big to backport.
This change avoids the ICE by actually emitting an appropriate error. The
output will be duplicated in some cases, but that's better than the
avoidable ICE.
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)