This is a deprecated attribute that is slated for removal, and it also affects
all implementors of the trait. This commit removes the attribute and fixes up
implementors accordingly. The primary implementation which was lost was the
ability to compare `&[T]` and `Vec<T>` (in that order).
This change also modifies the `assert_eq!` macro to not consider both directions
of equality, only the one given in the left/right forms to the macro. This
modification is motivated due to the fact that `&[T] == Vec<T>` no longer
compiles, causing hundreds of errors in unit tests in the standard library (and
likely throughout the community as well).
cc #19470
[breaking-change]
The documentation says that 'The current convention is to use the `test` module
to hold your "unit-style"' but then defines the module as "tests" instead.
Also in the output of the command we can see:
```
test test::it_works ... ok
```
So I think the name of the module was meant to be "test"
The documentation says that 'The current convention is to use the `test` module
to hold your "unit-style"' but then defines the module as "tests" instead.
This was originally used to set up the guessing game, but that no longer
exists. This version uses `old_io`, and updating it involves talking
about `&mut` and such, which we haven't covered yet. So, for now, let's
just remove it.
Fixes#23760
curl's progress meter would otherwise interfere with sudo's password prompt.
In addition, add the -f flag to make sure 4xx status codes are treated as errors.
r? @brson
Fixes#11794
I mostly removed superflous examples which use the standard library.
I have one more quesiton here though: threads. They're mostly a library thing, at this point, right?
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`.
Was reading the 'Looping' section of the book and was puzzled why the last example uses `0u32..10` when the others don't. Tried it out without and it seems to work, so I figured it should just be `0..10`. If there is a reason it needs to be `0u32..10` it should be explained in the text (I'd offer to do it but I have no idea).
r? @steveklabnik
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`.
Reject specialized Drop impls.
See Issue #8142 for discussion.
This makes it illegal for a Drop impl to be more specialized than the original item.
So for example, all of the following are now rejected (when they would have been blindly accepted before):
```rust
struct S<A> { ... };
impl Drop for S<i8> { ... } // error: specialized to concrete type
struct T<'a> { ... };
impl Drop for T<'static> { ... } // error: specialized to concrete region
struct U<A> { ... };
impl<A:Clone> Drop for U<A> { ... } // error: added extra type requirement
struct V<'a,'b>;
impl<'a,'b:a> Drop for V<'a,'b> { ... } // error: added extra region requirement
```
Due to examples like the above, this is a [breaking-change].
(The fix is to either remove the specialization from the `Drop` impl, or to transcribe the requirements into the struct/enum definition; examples of both are shown in the PR's fixed to `libstd`.)
----
This is likely to be the last thing blocking the removal of the `#[unsafe_destructor]` attribute.
Fix#8142Fix#23584
I assume since both shifts say the same thing, I should fix both of them, but then I realized I don't strictly know about left shift.
Fixes#23421
r? @pnkfelix
