This allows `io::Error` values to be stored in `Arc` properly.
Because this requires `Sync` of any value passed to `io::Error::new()`
and modifies the relevant `convert::From` impls, this is a
[breaking-change]
Fixes#24049.
Add conditional overflow-checking to signed negate operator.
I argue this can land independently of #24420 , because one can write the implementation of `wrapped_neg()` inline if necessary (as illustrated in two cases on this PR).
This needs to go into beta channel.
This makes it illegal to have unconstrained lifetimes that appear in an associated type definition. Arguably, we should prohibit all unconstrained lifetimes -- but it would break various macros. It'd be good to evaluate how large a break change it would be. But this seems like the minimal change we need to do to establish soundness, so we should land it regardless. Another variant would be to prohibit all lifetimes that appear in any impl item, not just associated types. I don't think that's necessary for soundness -- associated types are different because they can be projected -- but it would feel a bit more consistent and "obviously" safe. I'll experiment with that in the meantime.
r? @aturon
Fixes#22077.
which get mentioned in an associated type are constrained. Arguably we
should just require that all regions are constrained, but that is more
of a breaking change.
Fix Debug impl for RangeFull
The Debug impl was using quotes, which was inconsistent:
=> (.., 1.., 2..3, ..4)
(\"..\", 1.., 2..3, ..4)
Fix to use just ..
typeck: Do high-level structural/signature checks before function body checks.
This avoids various ICEs, e.g. premature calls to cat_expr that yield the dreaded "cat_expr Errd" ICE.
However, it also means that some early error feedback is now not provided. This may be for the best, because the error feedback were were providing in some of those cases were false positives -- it was spurious feedback and a distraction from the real problem.
So it is not 100% clear whether we actually want to put this change in or not. I think its a net win, but others might disagree.
(Kudos to @arielb1 for suggesting this modification.)
(The cast from the 64-bit value to isize was using the lower 32-bits,
which led to it being treated as a large positive value rather than a
smallish negative one. The fix was to use the same bits for the upper-
and lower- 32 bits.)
A few final improvements to rustdoc for 1.0:
* Improve how rustdoc handles stability
* Fix cross-crate macro source links
* Improve experience of types inheriting methods through `Deref`
Some more details can be found in the commits.
[Preview](http://people.mozilla.org/~acrichton/doc/std/)
Whenever a type implements Deref, rustdoc will now add a section to the "methods
available" sections for "Methods from Deref<Target=Foo>", listing all the
inherent methods of the type `Foo`.
Closes#19190
This commit is an overhaul to how rustdoc deals with stability of the standard
library. The handling has all been revisited with respect to Rust's current
approach to stability in terms of implementation as well as the state of the
standard library today. The high level changes made were:
* Stable items now have no marker by default
* Color-based small stability markers have been removed
* Module listings now fade out unstable/deprecated items slightly
* Trait methods have a separate background color based on stability and also
list the reason that they are unstable.
* `impl` blocks with stability no longer render at all. This may be re-added
once the compiler recognizes stability on `impl` blocks.
* `impl` blocks no longer have stability of the methods implemente indicated
* The stability summary has been removed
Closes#15468Closes#21674Closes#24201
