The collections debug helpers no longer prefix output with the
collection name, in line with the current conventions for Debug
implementations. Implementations that want to preserve the current
behavior can simply add a `try!(write!(fmt, "TypeName "));` at the
beginning of the `fmt` method.
[breaking-change]
The Send bound is an unnecessary restriction, and though provided as a convenience, can't be removed by downstream code.
The removal of this bound is a [breaking-change] since it removes an implicit Send bound on all `E: Error` and all `Error` trait objects.
To migrate, consider if your code actually requires the Send bound and, if so, add it explicitly.
Fixes#23774
r? @aturon
The Send bound is an unnecessary restriction, and though provided as a
convenience, can't be removed by downstream code.
The removal of this bound is a [breaking-change] since it
removes an implicit Send bound on all `E: Error` and all
`Error` trait objects.
To migrate, consider if your code actually requires the Send
bound and, if so, add it explicitly.
Fixes#23774
This allows `Wrapping<T>` to be used in `assert_eq!`, for example.
One of the tests (compile-fail/xc-private-method.rs) fails, but I can hardly imagine it is related to this change. I would also like to add a tests to ensure that `assert_eq!` compiles and keeps working in the future for `Wrapped<T>` values, but there appear to be no tests in libcore. What would be a good place to add such a test?
Marks as `#[stable}`:
* `ok_or`
* `ok_or_else`
* `iter_mut`
* `cloned`
Similarly to `IteratorExt::cloned`, the `cloned` method is pared down to
work only on `Option<&T>`. Thus, this is a:
[breaking-change]
r? @alexcrichton
This commit revises `path` and `os_str` to use blanket impls for `From`
on reference types. This both cuts down on the number of required impls,
and means that you can pass through e.g. `T: AsRef<OsStr>` to
`PathBuf::from` without an intermediate call to `as_ref`.
It also makes a FIXME note for later generalizing the blanket impls for
`AsRef` and `AsMut` to use `Deref`/`DerefMut`, once it is possible to do
so.
This attribute has been deprecated in favor of #[should_panic]. This also
updates rustdoc to no longer accept the `should_fail` directive and instead
renames it to `should_panic`.
Found a few 404s that seemed like simple fixes:
In footer.inc, certain 404 pages were 404ing on the request to jquery.js and playpen.js. This is easily demonstrated by visiting http://doc.rust-lang.org/foo then http://doc.rust-lang.org/foo/bar. The latter 404s, looking for foo/jquery.js.
The Result docs use old_io Writer as an example. Fix the link to old_io Writer. There's probably an effort to update the example away from a deprecated api but this was a simple fix.
rustc/plugin was pointing at the old guide and it was a broken link anyways (plugin vs plugins). Point at the book instead.
The main page of the API docs referenced c_{str,vec}. Looks like these were deleted in 25d5a3a19423fee01787de87a56d185dd4e0a4e7. Point at ffi docs instead.
This is technically a breaking change as it deprecates and unstables some previously stable apis that were missed in the last round of deprecations.
[breaking change]
This PR introduces a `Reflect` marker trait which is a supertrait of `Any`. The idea is that `Reflect` is defined for all concrete types, but is not defined for type parameters unless there is a `T:Reflect` bound. This is intended to preserve the parametricity property. This allows the `Any` interface to be stabilized without committing us to unbounded reflection that is not easily detectable by the caller.
The implementation of `Reflect` relies on an experimental variant of OIBIT. This variant behaves differently for objects, since it requires that all types exposed as part of the object's *interface* are `Reflect`, but isn't concerned about other types that may be closed over. In other words, you don't have to write `Foo+Reflect` in order for `Foo: Reflect` to hold (where `Foo` is a trait).
Given that `Any` is slated to stabilization and hence that we are committed to some form of reflection, the goal of this PR is to leave our options open with respect to parametricity. I see the options for full stabilization as follows (I think an RFC would be an appropriate way to confirm whichever of these three routes we take):
1. We make `Reflect` a lang-item.
2. We stabilize some version of the OIBIT variation I implemented as a general mechanism that may be appropriate for other use cases.
3. We give up on preserving parametricity here and just have `impl<T> Reflect for T` instead. In that case, `Reflect` is a harmless but not especially useful trait going forward.
cc @aturon
cc @alexcrichton
cc @glaebhoerl (this is more-or-less your proposal, as I understood it)
cc @reem (this is more-or-less what we discussed on IRC at some point)
cc @FlaPer87 (vaguely pertains to OIBIT)
Marks as `#[stable}`:
* `ok_or`
* `ok_or_else`
* `iter_mut`
* `cloned`
Similarly to `IteratorExt::cloned`, the `cloned` method is pared down to
work only on `Option<&T>`. Thus, this is a:
[breaking-change]
Found a few 404s that seemed like simple fixes:
The Result docs use old_io Writer as an example. Fix the link to old_io Writer. There's probably an effort to update the example away from a deprecated api but this was a simple fix.
rustc/plugin was pointing at the old guide and it was a broken link anyways (plugin vs plugins). Point at the book instead.
The main page of the API docs referenced c_{str,vec}. Looks like these were deleted in 25d5a3a19423fee01787de87a56d185dd4e0a4e7. Point at ffi docs instead.
This commit revises `path` and `os_str` to use blanket impls for `From`
on reference types. This both cuts down on the number of required impls,
and means that you can pass through e.g. `T: AsRef<OsStr>` to
`PathBuf::from` without an intermediate call to `as_ref`.
It also makes a FIXME note for later generalizing the blanket impls for
`AsRef` and `AsMut` to use `Deref`/`DerefMut`, once it is possible to do
so.
This attribute has been deprecated in favor of #[should_panic]. This also
updates rustdoc to no longer accept the `should_fail` directive and instead
renames it to `should_panic`.
This is technically a breaking change as it deprecates and unstables
some previously stable apis that were missed in the last round of
deprecations.
[breaking change]
Refactored code so that the drop-flag values for initialized
(`DTOR_NEEDED`) versus dropped (`DTOR_DONE`) are given explicit names.
Add `mem::dropped()` (which with `DTOR_DONE == 0` is semantically the
same as `mem::zeroed`, but the point is that it abstracts away from
the particular choice of value for `DTOR_DONE`).
Filling-drop needs to use something other than `ptr::read_and_zero`,
so I added such a function: `ptr::read_and_drop`. But, libraries
should not use it if they can otherwise avoid it.
Fixes to tests to accommodate filling-drop.
Main motivation was to update docs for the removal or "demotion" of certain extension traits. The update to the slice docs was larger, since the text was largely outdated.
The primary motivation here is to sidestep #19032 -- for a time, I thought that we should improve coherence or otherwise extend the language, but I now think that any such changes will require more time to bake. In the meantime, inheritance amongst the fn traits is both logically correct *and* a simple solution to that obstacle. This change introduces inheritance and modifies the compiler so that it can properly generate impls for closures and fns.
Things enabled by this PR (but not included in this PR):
1. An impl of `FnMut` for `&mut F` where `F : FnMut` (https://github.com/rust-lang/rust/issues/23015).
2. A better version of `Thunk` I've been calling `FnBox`.
I did not include either of these in the PR because:
1. Adding the impls in 1 currently induces a coherence conflict with the pattern trait. This is interesting and merits some discussion.
2. `FnBox` deserves to be a PR of its own.
The main downside to this design is (a) the need to write impls by hand; (b) the possibility of implementing `FnMut` with different semantics from `Fn`, etc. Point (a) is minor -- in particular, it does not affect normal closure usage -- and could be addressed in the future in many ways (better defaults; convenient macros; specialization; etc). Point (b) is unfortunate but "just a bug" from my POV, and certainly not unique to these traits (c.f. Copy/Clone, PartialEq/Eq, etc). (Until we lift the feature-gate on implementing the Fn traits, in any case, there is room to correct both of these if we find a nice way.)
Note that I believe this change is reversible in the future if we decide on another course of action, due to the feature gate on implementing the `Fn` traits, though I do not (currently) think we should reverse it.
Fixes#18835.
r? @nrc
Main access point of .split() and other similar methods are not using
the StrExt trait anymore, so update the libcore docs to reflect this
(because these docs are visible in libstd API documentation).