| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
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]
|
|
|
|
|
|
|
|
try to get capacity for usize::MAX
|
|
|
|
for only half of the maximum size available on the architecture. This
allows vectors to keep expanding with those two methods until the amount
of bytes exceeds usize.
|
|
r=alexcrichton
|
|
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]
|
|
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/test/run-pass/issue-13027.rs
|
|
Until some backwards-compatibility hazards are fixed in #23121,
these need to be unstable.
[breaking-change]
|
|
Conflicts:
src/libcollections/vec.rs
|
|
r? @alexcrichton
|
|
This syntax has been deprecated for quite some time, and there were only a few
remaining uses of it in the codebase anyway.
|
|
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]
|
|
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]`.
|
|
|
|
|
|
|
|
|
|
This syntax has been deprecated for quite some time, and there were only a few
remaining uses of it in the codebase anyway.
|
|
|
|
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]
|
|
(Reviewed rest of code; did not see other `pub` items that needed such
treatment.)
Driveby: fix typo in comment in ptr.rs.
|
|
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.
|
|
Fixes #23564
|
|
Makes Vec::push considerably smaller: 25 instructions, rather than 42, on
x86_64.
|
|
A lot has changed since this doc text was last touched up, and this is
just a minor edit. I remove the trait section entirely since we don't
use extension traits that much anymore, so there are no significant
trait hilights for this module.
|
|
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).
|
|
Makes Vec::push considerably smaller: 25 instructions, rather than 42, on
x86_64.
|
|
|
|
This permits all coercions to be performed in casts, but adds lints to warn in those cases.
Part of this patch moves cast checking to a later stage of type checking. We acquire obligations to check casts as part of type checking where we previously checked them. Once we have type checked a function or module, then we check any cast obligations which have been acquired. That means we have more type information available to check casts (this was crucial to making coercions work properly in place of some casts), but it means that casts cannot feed input into type inference.
[breaking change]
* Adds two new lints for trivial casts and trivial numeric casts, these are warn by default, but can cause errors if you build with warnings as errors. Previously, trivial numeric casts and casts to trait objects were allowed.
* The unused casts lint has gone.
* Interactions between casting and type inference have changed in subtle ways. Two ways this might manifest are:
- You may need to 'direct' casts more with extra type information, for example, in some cases where `foo as _ as T` succeeded, you may now need to specify the type for `_`
- Casts do not influence inference of integer types. E.g., the following used to type check:
```
let x = 42;
let y = &x as *const u32;
```
Because the cast would inform inference that `x` must have type `u32`. This no longer applies and the compiler will fallback to `i32` for `x` and thus there will be a type error in the cast. The solution is to add more type information:
```
let x: u32 = 42;
let y = &x as *const u32;
```
|
|
|
|
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
|
|
|
|
`btree_map::IntoIter` (and `btree_set::IntoIter`) remains, but it is a bit trickier.
|
|
This is a [breaking-change]. When indexing a generic map (hashmap, etc) using the `[]` operator, it is now necessary to borrow explicitly, so change `map[key]` to `map[&key]` (consistent with the `get` routine). However, indexing of string-valued maps with constant strings can now be written `map["abc"]`.
r? @japaric
cc @aturon @Gankro
|
|
|
|
Conflicts:
src/librustc_back/rpath.rs
|
