```rust
fn main() {
let foo: Option<()> = None;
foo.unwrap(); // this should produce a useful panic message!
}
```
> Prior to Rust 1.42, panics like this `unwrap()` printed a location in libcore:
```
$ rustc +1.41.0 example.rs; example.exe
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value',...core\macros\mod.rs:15:40
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
```
> As of 1.42, we get a much more helpful message:
```
$ rustc +1.42.0 example.rs; example.exe
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', example.rs:3:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
> These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information.
The attribute adds an implicit caller location argument to the ABI of annotated functions, but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator.
## Bottom Line
This PR stabilizes the use of `#[track_caller]` everywhere, including traits and extern blocks. It also stabilizes `core::panic::Location::caller`, although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`.
The implementation for the feature already changed the output of panic messages for a number of std functions, as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44.
## Tests
All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo.
Noteworthy cases:
* [use of attr in std]
* validates user-facing benefit of the feature
* [trait attribute inheritance]
* covers subtle behavior designed during implementation and not RFC'd
* [const/codegen equivalence]
* this was the result of a suspected edge case and investigation
* [diverging function support]
* covers an unresolved question from the RFC
* [fn pointers and shims]
* covers important potential sources of unsoundness
## Documentation
The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide].
I have an [open PR to the reference][attr-reference-pr] documenting the attribute.
The intrinsic's [wrapper] includes some examples as well.
## Implementation History
* 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037)
* Picked up the patch that @ayosec had started on the feature gate.
* 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182)
* 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~
* Abandoned approach to send location as a MIR argument.
* 2019-10-28: [`std::panic::Location` is a lang_item, add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664)
* 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881)
* 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137)
* 2020-01-08: [`Option::{expect,unwrap}` and `Result::{expect, expect_err, unwrap, unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887)
* 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178)
* 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251)
* 2020-03-24: [#[track_caller] on core::ops::{Index, IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234)
* 2020-04-08 [Support `#[track_caller]` on functions in `extern "Rust" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916)
## Unresolveds
### From the RFC
> Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing
> measure.
**Resolved.** See the dev-guide documentation and the tests section above.
> Diverging functions should be supported.
**Resolved.** See the tests section above.
> The closure foo::{{closure}} should inherit most attributes applied to the function foo, ...
**Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation.
### Binary Size
I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support.
There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the "right" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction.
### Specialization
There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable, but I also think it should be an easy question to resolve.
### Location only points to the start of a call span
https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182, and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554).
### Regression of std's panic messages
#70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686.
Rollup merge of #72369 - Lucretiel:socketaddr-parse, r=dtolnay
Bring net/parser.rs up to modern up to date with modern rust patterns
The current implementation of IP address parsing is very unidiomatic; it's full of `if` / `return` / `is_some` / `is_none` instead of `?`, `loop` with manual index tracking; etc. Went through and did and cleanup to try to bring it in line with modern sensibilities.
The obvious concern with making changes like this is "make sure you understand why it's written that way before changing it". Looking through the commit history for this file, there are several much smaller commits that make similar changes (For instance, https://github.com/rust-lang/rust/commit/3024c1434a667425d30e4b0785857381323712aa, https://github.com/rust-lang/rust/commit/4f3ab4986ec96d9c93f34dc53d0a4a1279288451, https://github.com/rust-lang/rust/commit/79f876495b2853d1b78ba953ceb3114b8019100f), and there don't seem to be any commits in the history that indicate that this lack of idiomaticity is related to specific performance needs (ie, there aren't any commits that replace a `for` loop with a `loop` and a manual index count). In fact, the basic shape of the file is essentially unchanged from its initial commit back in 2015.
Made the following changes throughout the IP address parser:
- Replaced all uses of `is_some()` / `is_none()` with `?`.
- "Upgraded" loops wherever possible; ie, replace `while` with `for`, etc.
- Removed all cases of manual index tracking / incrementing.
- Renamed several single-character variables with more expressive names.
- Replaced several manual control flow segments with equivalent adapters (such as `Option::filter`).
- Removed `read_seq_3`; replaced with simple sequences of `?`.
- Parser now reslices its state when consuming, rather than carrying a separate state and index variable.
- `read_digit` now uses `char::to_digit`.
- Added comments throughout, especially in the complex IPv6 parsing logic.
- Added comprehensive local unit tests for the parser to validate these changes.
Auto merge of #73706 - Aaron1011:fix/proc-macro-foreign-span, r=petrochenkov
Serialize all foreign `SourceFile`s into proc-macro crate metadata
Normally, we encode a `Span` that references a foreign `SourceFile` by
encoding information about the foreign crate. When we decode this
`Span`, we lookup the foreign crate in order to decode the `SourceFile`.
However, this approach does not work for proc-macro crates. When we load
a proc-macro crate, we do not deserialzie any of its dependencies (since
a proc-macro crate can only export proc-macros). This means that we
cannot serialize a reference to an upstream crate, since the associated
metadata will not be available when we try to deserialize it.
This commit modifies foreign span handling so that we treat all foreign
`SourceFile`s as local `SourceFile`s when serializing a proc-macro.
All `SourceFile`s will be stored into the metadata of a proc-macro
crate, allowing us to cotinue to deserialize a proc-macro crate without
needing to load any of its dependencies.
Since the number of foreign `SourceFile`s that we load during a
compilation session may be very large, we only serialize a `SourceFile`
if we have also serialized a `Span` which requires it.
Nathan West [Wed, 20 May 2020 03:26:49 +0000 (23:26 -0400)]
Bring net/parser.rs up to modern up to date with modern rust patterns
Made the following changes throughout the IP address parser:
- Replaced all uses of `is_some()` / `is_none()` with `?`.
- "Upgraded" loops wherever possible; ie, replace `while` with `for`, etc.
- Removed all cases of manual index tracking / incrementing.
- Renamed several single-character variables with more expressive names.
- Replaced several manual control flow segments with equivalent adapters (such as `Option::filter`).
- Removed `read_seq_3`; replaced with simple sequences of `?`.
- Parser now reslices its state when consuming, rather than carrying a separate state and index variable.
- `read_digit` now uses `char::to_digit`.
- Removed unnecessary casts back and forth between u8 and u32
- Added comments throughout, especially in the complex IPv6 parsing logic.
- Added comprehensive local unit tests for the parser to validate these changes.
bors [Tue, 30 Jun 2020 06:12:21 +0000 (06:12 +0000)]
Auto merge of #73658 - dylanmckay:avr-update-llvm-submodule-with-picks, r=cuviper
[AVR] Update the rust-lang/llvm-project submodule to include AVR fixes recently merged
This PR updates rustc's LLVM submodule to include new AVR-specific
fixes recently merged on the Rust LLVM 'rustc/10.0-2020-05-05' branch.
All of these cherry-picked commits exist in upstream LLVM and were
cherry-picked into Rust's LLVM fork in commit 6c040dd86ed.
Relates to https://github.com/rust-lang/llvm-project/pull/66
```
|- 6c040dd86ed Merge pull request #66 from dylanmckay/avr-pick-upstream-llvm-fixes
|- 12dfdd3aed7 [AVR] Rewrite the function calling convention.
|- 118ac53f12b [AVR] Don't adjust for instruction size
|- bc27c282e13 [AVR] Fix miscompilation of zext + add
|- cfbe205a7e8 [AVR] Remove faulty stack pushing behavior
|- 143e1469e96 [AVR] Fix stack size in functions with a frame pointer
|- 6b2445d841e [LLVM][AVR] Support for R_AVR_6 fixup
|- 93ee4da19cf [AVR] Fix I/O instructions on XMEGA
|- 962c2415ffb [AVR] Do not place functions in .progmem.data
|- 65b8b170aef [AVR] Do not use divmod calls for bigger integers
|- 93a3b595d1c [AVR] Generalize the previous interrupt bugfix to signal
|- handlers too
|- cc4286349b4 [AVR] Respect the 'interrupt' function attribute
|- 954d0a92205 [AVR] Fix reads of uninitialized variables from constructor of AVRSubtarget
|- 1c0ddae73c9 [AVR] Fix read of uninitialized variable AVRSubtarget:::ELFArch
|- 0ed0823fe60 [AVR] Fix incorrect register state for LDRdPtr
|- 96075fc433d [AVR] Don't adjust addresses by 2 for absolute values
|- 6dfc55ba53b [AVR] Use correct register class for mul instructions
```
These changes include both correctness fixes and LLVM assertion error
fixes. Once all of these commits have been cherry-picked, all of the
LLVM plumbing for rust-lang/master to compile the AVR blink program will
be in place. Once this commit is merged, only PR rust-lang/rust#73270 will
be blocking successful compilation and emission of the AVR LED blink program.
Aaron Hill [Tue, 30 Jun 2020 02:02:57 +0000 (22:02 -0400)]
Normalize symbol ids to 0 in test stdout
The number of symbols we allocate (even early on) seems to be platform
dependent. We only care about hygiene for the purposes of this test,
so just set all of the symbol ids to zero
Aaron Hill [Wed, 24 Jun 2020 17:16:36 +0000 (13:16 -0400)]
Serialize all foreign `SourceFile`s into proc-macro crate metadata
Normally, we encode a `Span` that references a foreign `SourceFile` by
encoding information about the foreign crate. When we decode this
`Span`, we lookup the foreign crate in order to decode the `SourceFile`.
However, this approach does not work for proc-macro crates. When we load
a proc-macro crate, we do not deserialzie any of its dependencies (since
a proc-macro crate can only export proc-macros). This means that we
cannot serialize a reference to an upstream crate, since the associated
metadata will not be available when we try to deserialize it.
This commit modifies foreign span handling so that we treat all foreign
`SourceFile`s as local `SourceFile`s when serializing a proc-macro.
All `SourceFile`s will be stored into the metadata of a proc-macro
crate, allowing us to cotinue to deserialize a proc-macro crate without
needing to load any of its dependencies.
Since the number of foreign `SourceFile`s that we load during a
compilation session may be very large, we only serialize a `SourceFile`
if we have also serialized a `Span` which requires it.
bors [Mon, 29 Jun 2020 21:42:43 +0000 (21:42 +0000)]
Auto merge of #73374 - alexcrichton:compiler-bulitins-debug-assertions, r=Mark-Simulacrum
rustbuild: Move compiler-builtins build logic to manifest
This commit moves the compiler-builtins-specific build logic from
`src/bootstrap/bin/rustc.rs` into the workspace `Cargo.toml`'s
`[profile]` configuration. Now that rust-lang/cargo#7253 is fixed we can
ensure that Cargo knows about debug assertions settings, and it can also
be configured to specifically disable debug assertions unconditionally
for compiler-builtins. This should improve rebuild logic when
debug-assertions settings change and also improve build-std integration
where Cargo externally now has an avenue to learn how to build
compiler-builtins as well.
Alex Crichton [Mon, 15 Jun 2020 14:54:20 +0000 (07:54 -0700)]
rustbuild: Move compiler-builtins build logic to manifest
This commit moves the compiler-builtins-specific build logic from
`src/bootstrap/bin/rustc.rs` into the workspace `Cargo.toml`'s
`[profile]` configuration. Now that rust-lang/cargo#7253 is fixed we can
ensure that Cargo knows about debug assertions settings, and it can also
be configured to specifically disable debug assertions unconditionally
for compiler-builtins. This should improve rebuild logic when
debug-assertions settings change and also improve build-std integration
where Cargo externally now has an avenue to learn how to build
compiler-builtins as well.
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.