| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
`s/(?<!\{ self)(?<=\.)len\(\) == 0/is_empty()/g`
|
|
Conflicts:
src/libstd/net/ip.rs
src/libstd/sys/unix/fs.rs
src/libstd/sys/unix/mod.rs
src/libstd/sys/windows/mod.rs
|
|
|
|
|
|
Signed-off-by: Tibor Benke <ihrwein@gmail.com>
|
|
Allow a few specific ones but otherwise this helps ensure that our examples are
squeaky clean!
Closes #18199
|
|
|
|
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).
Closes #19470
[breaking-change]
|
|
* The `io::Seek` trait.
* The `Iterator::{partition, unsip}` methods.
* The `Vec::into_boxed_slice` method.
* The `LinkedList::append` method.
* The `{or_insert, or_insert_with` methods in the `Entry` APIs.
r? @alexcrichton
|
|
This commit cleans out a large amount of deprecated APIs from the standard
library and some of the facade crates as well, updating all users in the
compiler and in tests as it goes along.
|
|
* The `io::Seek` trait, and `SeekFrom` enum.
* The `Iterator::{partition, unsip}` methods.
* The `Vec::into_boxed_slice` method.
* The `LinkedList::append` method.
* The `{or_insert, or_insert_with` methods in the `Entry` APIs.
|
|
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]
|
|
This functions swaps the order of arguments to a few functions that previously
took (output, input) parameters, but now take (input, output) parameters (in
that order).
The affected functions are:
* ptr::copy
* ptr::copy_nonoverlapping
* slice::bytes::copy_memory
* intrinsics::copy
* intrinsics::copy_nonoverlapping
Closes #22890
[breaking-change]
|
|
Fixes #23320
|
|
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]
|
|
All methods are inlined into Iterator with `Self: Sized` bounds to make
sure Iterator is still object safe.
[breaking-change]
|
|
Fixes #23320
|
|
Also convert [T]'s Debug impl. The behavior of the alternate flag here's
changing.
|
|
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]
|
|
Pretty much what it says on the tin.
|
|
|
|
Conflicts:
src/librustc/middle/ty.rs
src/librustc_trans/trans/adt.rs
src/librustc_typeck/check/mod.rs
src/libserialize/json.rs
src/test/run-pass/spawn-fn.rs
|
|
Conflicts:
src/libcollections/vec.rs
|
|
Replace zeroing-on-drop with filling-on-drop.
This is meant to set the stage for removing *all* zeroing and filling (on drop) in the future.
Note that the code is meant to be entirely abstract with respect to the particular values used for the drop flags: the final commit demonstrates how to go from zeroing-on-drop to filling-on-drop by changing the value of three constants (in two files).
See further discussion on the internals thread:
http://internals.rust-lang.org/t/attention-hackers-filling-drop/1715/11
[breaking-change] especially for structs / enums using `#[unsafe_no_drop_flag]`.
|
|
|
|
|
|
|
|
Now that support has been removed, all lingering use cases are renamed.
|
|
|
|
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.
|
|
Conflicts:
src/compiletest/compiletest.rs
src/libcollections/lib.rs
src/librustc_back/lib.rs
src/libserialize/lib.rs
src/libstd/lib.rs
src/libtest/lib.rs
src/test/run-make/rustdoc-default-impl/foo.rs
src/test/run-pass/env-home-dir.rs
|
|
- Successful merges: #22954, #23119, #23509, #23561, #23590, #23607, #23608, #23618, #23622, #23639, #23641
- Failed merges: #23401
|
|
|
|
|
|
This commit marks as `#[stable]` the `Entry` types for the maps provided
by `std`. The main reason these had been left unstable previously was
uncertainty about an eventual trait design, but several plausible
designs have been proposed that all work fine with the current type definitions.
r? @Gankro
|
|
references. For collections whose keys are integers, we take both
references and by-value.
|
|
|
|
This commit removes the `IndexMut` impls on `HashMap` and `BTreeMap`, in
order to future-proof the API against the eventual inclusion of an
`IndexSet` trait.
Ideally, we would eventually be able to support:
```rust
map[owned_key] = val;
map[borrowed_key].mutating_method(arguments);
&mut map[borrowed_key];
```
but to keep the design space as unconstrained as possible, we do not
currently want to support `IndexMut`, in case some other strategy will
eventually be needed.
Code currently using mutating index notation can use `get_mut` instead.
[breaking-change]
Closes #23448
|
|
This commit marks as `#[stable]` the `Entry` types for the maps provided
by `std`. The main reason these had been left unstable previously was
uncertainty about an eventual trait design, but several plausible
designs have been proposed that all work fine with the current type definitions.
|
|
|
|
|
|
|
|
closes #23327
|
|
This brings comments in line with https://github.com/rust-lang/rfcs/blob/master/text/0505-api-comment-conventions.md#using-markdown
|
|
|
|
|
|
|
