In the general case, at least, it is not possible to make an object out of an unsized type. This is because the object type would have to store the fat pointer information for the `self` value *and* the vtable -- meaning it'd have to be a fat pointer with three words -- but for the compiler to know that the object requires three words, it would have to know the self-type of the object (is `self` a thin or fat pointer?), which of course it doesn't.
Fixes#18333.
r? @nick29581
(Previously, scopes were solely identified with NodeId's; this
refactoring prepares for a future where that does not hold.)
Ground work for a proper fix to #8861.
(Previously, statically identifiable scopes/regions were solely
identified with NodeId's; this refactoring prepares for a future
where that 1:1 correspondence does not hold.)
Use the expected type to infer the argument/return types of unboxed closures. Also, in `||` expressions, use the expected type to decide if the result should be a boxed or unboxed closure (and if an unboxed closure, what kind).
This supercedes PR #19089, which was already reviewed by @pcwalton.
This PR changes `AsSlice` to work on unsized types, and changes the
`impl` for `&[T]` to `[T]`. Aside from making the trait more general,
this also helps some ongoing work with method resolution changes.
This is a breaking change: code that uses generics bounded by `AsSlice`
will have to change. In particular, such code previously often took
arguments of type `V` where `V: AsSlice<T>` by value. These should now
be taken by reference:
```rust
fn foo<Sized? V: AsSlice<T>>(v: &V) { .. }
```
A few std lib functions have been changed accordingly.
The PR also relaxes constraints on generics and traits within the
`core::ops` module and for the `Equiv` trait.
[breaking-change]
r? @nikomatsakis
cc @japaric
This commit changes `AsSlice` to work on unsized types, and changes the
`impl` for `&[T]` to `[T]`. Aside from making the trait more general,
this also helps some ongoing work with method resolution changes.
This is a breaking change: code that uses generics bounded by `AsSlice`
will have to change. In particular, such code previously often took
arguments of type `V` where `V: AsSlice<T>` by value. These should now
be taken by reference:
```rust
fn foo<Sized? V: AsSlice<T>>(v: &V) { .. }
```
A few std lib functions have been changed accordingly.
[breaking-change]
This commit adds stability markers for the APIs that have recently been aligned with [numerics reform](https://github.com/rust-lang/rfcs/pull/369). For APIs that were changed as part of that reform, `#[unstable]` is used to reflect the recency, but the APIs will become `#[stable]` in a follow-up pass.
In addition, a few aspects of the APIs not explicitly covered by the RFC are marked here -- in particular, constants for floats.
This commit does not mark the `uint` or `int` modules as `#[stable]`, given the ongoing debate out the names and roles of these types.
Due to some deprecation (see the RFC for details), this is a:
[breaking-change]
r? @alexcrichton
cc @bjz
Futureproof Rust for fancier suffixed literals. The Rust compiler tokenises a literal followed immediately (no whitespace) by an identifier as a single token: (for example) the text sequences `"foo"bar`, `1baz` and `1u1024` are now a single token rather than the pairs `"foo"` `bar`, `1` `baz` and `1u` `1024` respectively.
The compiler rejects all such suffixes in the parser, except for the 12 numeric suffixes we have now.
I'm fairly sure this will affect very few programs, since it's not currently legal to have `<literal><identifier>` in a Rust program, except in a macro invocation. Any macro invocation relying on this behaviour can simply separate the two tokens with whitespace: `foo!("bar"baz)` becomes `foo!("bar" baz)`.
This implements [RFC 463](https://github.com/rust-lang/rfcs/blob/master/text/0463-future-proof-literal-suffixes.md), and so closes https://github.com/rust-lang/rust/issues/19088.
This commit applies the stabilization of std::fmt as outlined in [RFC 380][rfc].
There are a number of breaking changes as a part of this commit which will need
to be handled to migrated old code:
* A number of formatting traits have been removed: String, Bool, Char, Unsigned,
Signed, and Float. It is recommended to instead use Show wherever possible or
to use adaptor structs to implement other methods of formatting.
* The format specifier for Boolean has changed from `t` to `b`.
* The enum `FormatError` has been renamed to `Error` as well as becoming a unit
struct instead of an enum. The `WriteError` variant no longer exists.
* The `format_args_method!` macro has been removed with no replacement. Alter
code to use the `format_args!` macro instead.
* The public fields of a `Formatter` have become read-only with no replacement.
Use a new formatting string to alter the formatting flags in combination with
the `write!` macro. The fields can be accessed through accessor methods on the
`Formatter` structure.
Other than these breaking changes, the contents of std::fmt should now also all
contain stability markers. Most of them are still #[unstable] or #[experimental]
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0380-stabilize-std-fmt.md
[breaking-change]
Closes#18904
As-is, there's no indication that the code examples pop out into a window that runs on `play.rust-lang.org` until you mouse over them. I managed to get to section 4 of the guide before realizing you could do this since it didn't occur to me to mouse over the example text.
cc @rose since we went through the tutorial together and I think it wasn't obvious to her either.
Ensure that the type parameters passed to methods outlive the call expression.
Fixes#18899.
This is yet another case of forgotten to consistently enforce the constraints in every instance where they apply. Might be nice to try and refactor to make this whole thing more DRY, but for now here's a targeted fix.
r? @pcwalton
Now that we've done `fail` -> `panic`, I feel bringing back the error handling guide is a good idea. We had one long ago, but it was removed when conditions were removed.
This doesn't cover the new FromError stuff, but I feel like it's already useful in this state, so I'm sending this PR now.
This fixes#17388.
Note that we don't check type parameters in trait-references and so on, so we accept some nonsense (I opened https://github.com/rust-lang/rust/issues/18865). (It may be easier to just add support for `T::Foo` and deprecate the qpath code until we can implement it more robustly using the trait lookup infrastructure, not sure.)
