When popping in CTFE, perform validation before jumping to next statement to have a better span for the error
Currently, when validating the return value fails, the span points at the next statement after the call. That does not make much sense.
r? @oli-obk
Add std::iter::unfold
This adds an **unstable** ~`std::iter::iterate`~ `std::iter::unfold` function and ~`std::iter::Iterate`~ `std::iter::Unfold` type that trivially wrap a ~`FnMut() -> Option<T>`~ `FnMut(&mut State) -> Option<T>` closure to create an iterator. ~Iterator state can be kept in the closure’s environment or captures.~
This is intended to help reduce amount of boilerplate needed when defining an iterator that is only created in one place. Compare the existing example of the `std::iter` module: (explanatory comments elided)
```rust
struct Counter {
count: usize,
}
impl Counter {
fn new() -> Counter {
Counter { count: 0 }
}
}
impl Iterator for Counter {
type Item = usize;
fn next(&mut self) -> Option<usize> {
self.count += 1;
if self.count < 6 {
Some(self.count)
} else {
None
}
}
}
```
… with the same algorithm rewritten to use this new API:
```rust
fn counter() -> impl Iterator<Item=usize> {
std::iter::unfold(0, |count| {
*count += 1;
if *count < 6 {
Some(*count)
} else {
None
}
})
}
```
-----
This also add unstable `std::iter::successors` which takes an (optional) initial item and a closure that takes an item and computes the next one (its successor).
```rust
let powers_of_10 = successors(Some(1_u16), |n| n.checked_mul(10));
assert_eq!(powers_of_10.collect::<Vec<_>>(), &[1, 10, 100, 1_000, 10_000]);
```
Disable some pretty-printers when gdb is rust-enabled
A rust-enabled gdb already knows how to display string slices,
structs, tuples, and enums (and after #54004, the pretty-printers
can't handle enums at all). This patch disables these pretty-printers
when gdb is rust-enabled.
The "gdb-pretty-struct-and-enums-pre-gdb-7-7.rs" test is renamed,
because it does not seem to depend on any behavior of that version of
gdb, and because gdb 7.7 is 4 years old now.
Suggest correct syntax when writing type arg instead of assoc type
- When confusing an associated type with a type argument, suggest the appropriate syntax. Given `Iterator<isize>`, suggest `Iterator<Item = isize>`.
- When encountering multiple missing associated types, emit only one diagnostic.
- Point at associated type def span for context.
- Point at each extra type argument.
Follow up to #48288, fix#20977.
rustc_target: separate out an individual alignment quantity type from Align.
Before this PR, `rustc_target::abi::Align` combined "power-of-two alignment quantity" semantics, with a distinction between ABI (required) and preferred alignment (by having two quantities).
After this PR, `Align` is only *one* such quantity, and a new `AbiAndPrefAlign` type is introduced to hold the pair of ABI and preferred `Align` quantities.
`Align` is used everywhere one quantity is necessary/sufficient, simplifying some of the code in codegen/miri, while `AbiAndPrefAlign` only in layout computation (to propagate preferred alignment).
r? @oli-obk cc @nagisa @RalfJung @nikomatsakis
Issue 56128 segment id ice nightly
Tentative fix for #56128
From what I can tell, the problem is that if you have `pub(super) use foo::{a, b}`, then when we explode the `a` and `b`, the segment ids from the `super` path were not getting cloned. However, once I fixed *that*, then I ran into a problem that the "visibility" node-ids were not present in the final HIR -- this is because the visibility of the "stem" that is returned in this case was getting reset to inherited. I don't *think* it is a problem to undo that, so that the visibility is returned unmodified.
Fixes#55475Fixes#56128
cc @nrc @petrochenkov
Move Cargo.{toml,lock} to the repository root directory.
This should give us back `src/` in errors, panics and debuginfo, for free.
r? @Mark-Simulacrum @alexcrichton cc @michaelwoerister
submodules: update clippy from f5d868c9 to 2f6881c6
Changes:
````
missed another one in the README
run "util/dev update_lints"
rust-lang-nursery/rust-clippy => rust-lang/rust-clippy
Address 'clippy::single-match' dogfood lint
Fix nit
Address travis CI lint failure
Update trivially_copy_pass_by_ref with Trait stderr output
issue#3318 run trivially_copy_pass_by_ref for traits
Update trivially_copy_pass_by_ref with Trait examples
Fix awkward wording
Document how to lint local Clippy changes with locally built Clippy
Enable rustup clippy to refer to the correct documentation
rustup https://github.com/rust-lang/rust/pull/52591
remove unused allow() attributes, NFC
Add regression test
Don't emit suggestion when inside of a macro
````
fixes clippy toolstate
````
missed another one in the README
run "util/dev update_lints"
rust-lang-nursery/rust-clippy => rust-lang/rust-clippy
Address 'clippy::single-match' dogfood lint
Fix nit
Address travis CI lint failure
Update trivially_copy_pass_by_ref with Trait stderr output
issue#3318 run trivially_copy_pass_by_ref for traits
Update trivially_copy_pass_by_ref with Trait examples
Fix awkward wording
Document how to lint local Clippy changes with locally built Clippy
Enable rustup clippy to refer to the correct documentation
rustup https://github.com/rust-lang/rust/pull/52591
remove unused allow() attributes, NFC
Add regression test
Don't emit suggestion when inside of a macro
````
Add SGX target to rustc
This adds the `x86_64-fortanix-unknown-sgx` target specification to the Rust compiler. See #56066 for more details about this target.
Clarifying documentation for collections::hash_map::Entry::or_insert
Previous version does not show that or_insert does not insert the passed value, as the passed value was the same value as what was already in the map.
Return &T / &mut T in ManuallyDrop Deref(Mut) impl
Without this change the generated documentation looks like this:
fn deref(&self) -> &<ManuallyDrop<T> as Deref>::Target
Returning the actual type directly makes the generated docs more clear:
fn deref(&self) -> &T
Basically, compare how the impl for `Box<T>` and `ManuallyDrop<T>` looks in this screenshot:
![rust docs for ManuallyDrop as Deref](https://user-images.githubusercontent.com/7042/47673083-fc9dc280-db89-11e8-89b0-c6bde663feef.png)
Doc total order requirement of sort(_unstable)_by
I took the definition of what a total order is from the Ord trait
docs. I specifically put "elements of the slice" because if you
have a slice of f64s, but know none are NaN, then sorting by
partial ord is total in this case. I'm not sure if I should give
such an example in the docs or not.
r? @GuillaumeGomez