This shouldn't be possible any more, but if it does happen, emit an
error rather than maybe panicking later when NLL finds a the ReScope.
Impl trait in bindings is sufficiently broken that I don't think this
breaks anything that works for it.
Document the order of {Vec,VecDeque,String}::retain
It's natural for `retain` to work in order from beginning to end, but
this wasn't actually documented to be the case. If we actually promise
this, then the caller can do useful things like track the index of each
element being tested, as [discussed in the forum][1]. This is now
documented for `Vec`, `VecDeque`, and `String`.
[1]: https://users.rust-lang.org/t/vec-retain-by-index/27697
`HashMap` and `HashSet` also have `retain`, and the `hashbrown`
implementation does happen to use a plain `iter()` order too, but it's
not certain that this should always be the case for these types.
r? @scottmcm
Remove redundant "let mut" in write_graph_label
Removed the redundant "let mut" in the write_graph_label function (it caused "let mut let mut" for non-user-defined local variables).
impl From<Infallible> for TryFromSliceError
I believe this was missed when TryFrom was stabilized. I think `TryFromSliceError` and `TryFromIntError` are the only two `TryFrom` error types that appear in `std`. I think trait implementations have to be insta-stable, but I'm not sure.
Rollup of 6 pull requests
Successful merges:
- #60529 (RFC 2008: Uninhabitedness fixes for enum variants and tests)
- #60620 (Fix a couple of FIXMEs in ext::tt::transcribe)
- #60659 (Tweak `Symbol` and `InternedString`)
- #60692 (Extend #60676 test for nested mut patterns.)
- #60697 (add regression test for #60629)
- #60701 (Update mailmap for mati865)
Failed merges:
r? @ghost
add regression test for #60629
This bug was fixed, but I don't know which one. (I think it even doesn't matter at all).
Added a regression test.
```
op@OP ~/m/r/s/t/incremental> rustc --version
rustc 1.35.0-nightly (acd8dd6a5 2019-04-05)
op@OP ~/m/r/s/t/incremental> rustc -C incremental= --cfg rpass1 issue-60629.rs
warning: struct is never constructed: `A`
--> issue-60629.rs:3:1
|
3 | struct A;
| ^^^^^^^^^
|
= note: #[warn(dead_code)] on by default
op@OP ~/m/r/s/t/incremental> rustc -C incremental= --cfg rpass2 issue-60629.rs
error: internal compiler error: src/librustc/ty/query/plumbing.rs:1195: Cannot force dep node: coherent_trait(core[c27c]::ops[0]::drop[0]::Drop[0])
thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:635:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
error: aborting due to previous error
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.35.0-nightly (acd8dd6a5 2019-04-05) running on x86_64-unknown-linux-gnu
note: compiler flags: -C incremental
```
with latest nightly it does not crash anymore, so nothing more to do.
Fixes#60629
(accidentally removed the remote branch on github, therefore GH closed the other PR.)
r? @nikomatsakis
Extend #60676 test for nested mut patterns.
At request of @centril, this commit extends the existing test added by #60676 to include nested `mut` patterns.
cc @Centril
Fix a couple of FIXMEs in ext::tt::transcribe
_Blocked on #60618_
A crater run would be nice to make sure my understanding is correct. A quick google search seems to indicate these are extremely rare errors if they are possible (which I don't believe they are).
r? @petrochenkov
cc #2887 (there is only one FIXME left and it is hygiene-related)
RFC 2008: Uninhabitedness fixes for enum variants and tests
Part of #44109.
At the request of @Centril, this PR adds tests asserting that uninhabited non-exhaustive types are considered inhabited in extern crates. In adding these tests, I fixed an oversight in the implementation of RFC 2008 on enum variants that resulted in non-exhaustive enum variants being considered uninhabited in extern crates.
Before this PR, these lines would error:
```rust
// extern crate
pub enum UninhabitedVariants {
#[non_exhaustive] Tuple(!),
#[non_exhaustive] Struct { x: ! }
}
pub enum PartiallyInhabitedVariants {
Tuple(u8),
#[non_exhaustive] Struct { x: ! }
}
// current crate
match uninhabited_variant() /* fn() -> Option<UninhabitedVariants> */ {
Some(_x) => (), //~ ERROR unreachable pattern
None => (),
}
while let PartiallyInhabitedVariants::Struct { x, .. } = partially_inhabited_variant() /* fn() -> PartiallyInhabitedVariants */ {
//~^ ERROR unreachable pattern
}
```
cc @Centril
r? @petrochenkov
Revert "Disable big-endian simd in swap_nonoverlapping_bytes"
This reverts commit 77bd4dc654 (#43159).
Issue #42778 was formerly easy to reproduce on two big-endian targets,
`powerpc64` and `s390x`, so we disabled SIMD on this function for all
big-endian targets as a workaround.
I have re-tested this code on `powerpc64` and `s390x`, each with the
bundled LLVM 8 and with external LLVM 7 and LLVM 6, and the problems no
longer appear. So it seems safe to remove this workaround, although I'm
still a little uncomfortable that we never found a root-cause...
Closes#42778.
r? @arielb1
