Make ".e0" not parse as 0.0
This forces floats to have either a digit before the separating point, or after. Thus `".e0"` is invalid like `"."`, when using `parse()`. Fixes#40654. As mentioned in the issue, this is technically a breaking change... but clearly incorrect behaviour at present.
Add Iterator::flatten
This adds the trait method `.flatten()` on `Iterator` which flattens one level of nesting from an iterator or (into)iterators. The method `.flat_fmap(f)` is then redefined as `.map(f).flatten()`. The implementation of `Flatten` is essentially that of what it was for `FlatMap` but removing the call to `f` at various places.
Hopefully the type alias approach should be OK as was indicated / alluded to by @bluss and @eddyb in https://github.com/rust-lang/rfcs/pull/2306#issuecomment-361391370.
cc @scottmcm
A user in a reddit thread was confused by the name of the variable
"num_as_int"; they thought the example was trying to convert the
string "10" as if it were binary 2 by calling str::len(). In reality,
the example is simply demonstrating how to take an immutable reference
to the value of an Option. The confusion comes from the coincidence
that the length of the string "10" is also its binary representation,
and the implication from the variable names that a conversion was
occuring ("num_as_str" to "num_as_int").
This PR changes the example number to 12 instead of 10, and changes
the variable name from "num_as_int" to "num_length" to better
communicate what the example is doing.
The reddit thread:
https://www.reddit.com/r/rust/comments/7zpvev/notyetawesome_rust_what_use_cases_would_you_like/dur39xw/
Current document takes 2^4, which is equal to 4^2.
This example is not very helpful for those unfamiliar with math words in English and thus rely on example codes.
You can now choose between the following:
- `#[unwind(allowed)]`
- `#[unwind(aborts)]`
Per rust-lang/rust#48251, the default is `#[unwind(allowed)]`, though
I think we should change this eventually.
Currently, calling pow may panic in case of overflow, and the function
does not have non-panicking counterparts. Thus, it would be beneficial
to add those in.
RFC 2070 part 1: PanicInfo and Location API changes
This implements part of https://rust-lang.github.io/rfcs/2070-panic-implementation.html
Tracking issue: https://github.com/rust-lang/rust/issues/44489
* Move `std::panic::PanicInfo` and `std::panic::Location` to a new `core::panic` module. The two types and the `std` module were already `#[stable]` and stay that way, the new `core` module is `#[unstable]`.
* Add a new `PanicInfo::message(&self) -> Option<&fmt::Arguments>` method, which is `#[unstable]`.
* Implement `Display` for `PanicInfo` and `Location`
Primitive docs relevant
This fixes the documentation to show the right types in the examples for many integer methods.
I need to check if the result is correct before we merge.
#37653 support `default impl` for specialization
this commit implements the second part of the `default impl` feature:
> - a `default impl` need not include all items from the trait
> - a `default impl` alone does not mean that a type implements the trait
The first point allows rustc to compile and run something like this:
```
trait Foo {
fn foo_one(&self) -> &'static str;
fn foo_two(&self) -> &'static str;
}
default impl<T> Foo for T {
fn foo_one(&self) -> &'static str {
"generic"
}
}
struct MyStruct;
fn main() {
assert!(MyStruct.foo_one() == "generic");
}
```
but it shows a proper error if trying to call `MyStruct.foo_two()`
The second point allows a `default impl` to be considered as not implementing the `Trait` if it doesn't implement all the trait items.
The tests provided (in the compile-fail section) should cover all the possible trait resolutions.
Let me know if some tests is missed.
See [referenced ](https://github.com/rust-lang/rust/issues/37653) issue for further info
r? @nikomatsakis
