| Age | Commit message (Collapse) | Author | Lines |
|---|
|
As discovered in #15460, a particular #[link(kind = "static", ...)] line is not
actually guaranteed to link the library at all. The reason for this is that if
the external library doesn't have any referenced symbols in the object generated
by rustc, the entire library is dropped by the linker.
For dynamic native libraries, this is solved by passing -lfoo for all downstream
compilations unconditionally. For static libraries in rlibs this is solved
because the entire archive is bundled in the rlib. The only situation in which
this was a problem was when a static native library was linked to a rust dynamic
library.
This commit brings the behavior of dylibs in line with rlibs by passing the
--whole-archive flag to the linker when linking native libraries. On OSX, this
uses the -force_load flag. This flag ensures that the entire archive is
considered candidate for being linked into the final dynamic library.
This is a breaking change because if any static library is included twice in the
same compilation unit then the linker will start emitting errors about duplicate
definitions now. The fix for this would involve only statically linking to a
library once.
Closes #15460
[breaking-change]
|
|
|
|
This was motivated by a desire to remove allocation in the common
pattern of
let old = key.replace(None)
do_something();
key.replace(old);
This also switched the map representation from a Vec to a TreeMap. A Vec
may be reasonable if there's only a couple TLD keys, but a TreeMap
provides better behavior as the number of keys increases.
Like the Vec, this TreeMap implementation does not shrink the container
when a value is removed. Unlike Vec, this TreeMap implementation cannot
reuse an empty node for a different key. Therefore any key that has been
inserted into the TLD at least once will continue to take up space in
the Map until the task ends. The expectation is that the majority of
keys that are inserted into TLD will be expected to have a value for
most of the rest of the task's lifetime. If this assumption is wrong,
there are two reasonable ways to fix this that could be implemented in
the future:
1. Provide an API call to either remove a specific key from the TLD and
destruct its node (e.g. `remove()`), or instead to explicitly clean
up all currently-empty nodes in the map (e.g. `compact()`). This is
simple, but requires the user to explicitly call it.
2. Keep track of the number of empty nodes in the map and when the map
is mutated (via `replace()`), if the number of empty nodes passes
some threshold, compact it automatically. Alternatively, whenever a
new key is inserted that hasn't been used before, compact the map at
that point.
---
Benchmarks:
I ran 3 benchmarks. tld_replace_none just replaces the tld key with None
repeatedly. tld_replace_some replaces it with Some repeatedly. And
tld_replace_none_some simulates the common behavior of replacing with
None, then replacing with the previous value again (which was a Some).
Old implementation:
test tld_replace_none ... bench: 20 ns/iter (+/- 0)
test tld_replace_none_some ... bench: 77 ns/iter (+/- 4)
test tld_replace_some ... bench: 57 ns/iter (+/- 2)
New implementation:
test tld_replace_none ... bench: 11 ns/iter (+/- 0)
test tld_replace_none_some ... bench: 23 ns/iter (+/- 0)
test tld_replace_some ... bench: 12 ns/iter (+/- 0)
|
|
|
|
This was motivated by a desire to remove allocation in the common
pattern of
let old = key.replace(None)
do_something();
key.replace(old);
This also switched the map representation from a Vec to a TreeMap. A Vec
may be reasonable if there's only a couple TLD keys, but a TreeMap
provides better behavior as the number of keys increases.
Like the Vec, this TreeMap implementation does not shrink the container
when a value is removed. Unlike Vec, this TreeMap implementation cannot
reuse an empty node for a different key. Therefore any key that has been
inserted into the TLD at least once will continue to take up space in
the Map until the task ends. The expectation is that the majority of
keys that are inserted into TLD will be expected to have a value for
most of the rest of the task's lifetime. If this assumption is wrong,
there are two reasonable ways to fix this that could be implemented in
the future:
1. Provide an API call to either remove a specific key from the TLD and
destruct its node (e.g. `remove()`), or instead to explicitly clean
up all currently-empty nodes in the map (e.g. `compact()`). This is
simple, but requires the user to explicitly call it.
2. Keep track of the number of empty nodes in the map and when the map
is mutated (via `replace()`), if the number of empty nodes passes
some threshold, compact it automatically. Alternatively, whenever a
new key is inserted that hasn't been used before, compact the map at
that point.
---
Benchmarks:
I ran 3 benchmarks. tld_replace_none just replaces the tld key with None
repeatedly. tld_replace_some replaces it with Some repeatedly. And
tld_replace_none_some simulates the common behavior of replacing with
None, then replacing with the previous value again (which was a Some).
Old implementation:
test tld_replace_none ... bench: 20 ns/iter (+/- 0)
test tld_replace_none_some ... bench: 77 ns/iter (+/- 4)
test tld_replace_some ... bench: 57 ns/iter (+/- 2)
New implementation:
test tld_replace_none ... bench: 11 ns/iter (+/- 0)
test tld_replace_none_some ... bench: 23 ns/iter (+/- 0)
test tld_replace_some ... bench: 12 ns/iter (+/- 0)
|
|
Closes #16097 (fix variable name in tutorial)
Closes #16100 (More defailbloating)
Closes #16104 (Fix deprecation commment on `core::cmp::lexical_ordering`)
Closes #16105 (fix formatting in pointer guide table)
Closes #16107 (remove serialize::ebml, add librbml)
Closes #16108 (Fix heading levels in pointer guide)
Closes #16109 (rustrt: Don't conditionally init the at_exit QUEUE)
Closes #16111 (hexfloat: Deprecate to move out of the repo)
Closes #16113 (Add examples for GenericPath methods.)
Closes #16115 (Byte literals!)
Closes #16116 (Add a non-regression test for issue #8372)
Closes #16120 (Deprecate semver)
Closes #16124 (Deprecate uuid)
Closes #16126 (Deprecate fourcc)
Closes #16127 (Remove incorrect example)
Closes #16129 (Add note about production deployments.)
Closes #16131 (librustc: Don't ICE when trying to subst regions in destructor call.)
Closes #16133 (librustc: Don't ICE with struct exprs where the name is not a valid struct.)
Closes #16136 (Implement slice::Vector for Option<T> and CVec<T>)
Closes #16137 (alloc, arena, test, url, uuid: Elide lifetimes.)
|
|
Not included are two required patches:
* LLVM: segmented stack support for DragonFly [1]
* jemalloc: simple configure patches
[1]: http://reviews.llvm.org/D4705
|
|
This initialization should happen unconditionally, but the rtassert! macro is
gated on the ENFORCE_SANITY define
Closes #16106
|
|
Smaller text size.
|
|
The correct terminology is Task-Local Data, or TLD. Task-Local Storage,
or TLS, is the old terminology that was abandoned because of the
confusion with Thread-Local Storage (TLS).
|
|
Like with libnative, when a green task failed to spawn it would leave the world
in a corrupt state where the local scheduler had been dropped as well as the
local task. Also like libnative, this patch sets up a "bomb" which when it goes
off will restore the state of the world.
|
|
Previously, the call to bookkeeping::increment() was never paired with a
decrement when the spawn failed (due to unwinding). This fixes the problem by
returning a "bomb" from increment() which will decrement on drop, and then
moving the bomb into the child task's procedure which will be dropped naturally.
|
|
When a new task fails to spawn, it triggers a task failure of the spawning task.
This ends up causing runtime aborts today because of the destructor bomb in the
Task structure. The bomb doesn't actually need to go off until *after* the task
has run at least once.
This now prevents a runtime abort when a native thread fails to spawn.
|
|
Not included are two required patches:
* LLVM: segmented stack support for DragonFly [1]
* jemalloc: simple configure patches
[1]: http://reviews.llvm.org/D4705
|
|
A few refactorings to decrease text size and increase data size. I'm not sure about this tradeoff. Various stats below. cc @pcwalton
This reduces the code needed to pass arguments for `fail!()`, `fail!("{}", ...)`, and to a lesser extent `fail!("...")`. Still more work to be done on compiler-generated failures and the `fail!("...")` case.
do_fail_empty:
```
#[inline(never)]
fn do_fail_empty() {
fail!()
}
```
do_fail_empty before:
```
leaq 8(%rsp), %rdi
movabsq $13, %rsi
leaq "str\"str\"(1494)"(%rip), %rax
movq %rax, 8(%rsp)
movq $19, 16(%rsp)
callq _ZN6unwind31begin_unwind_no_time_to_explain20h57030457935ab6111SdE@PLT
```
do_fail_empty after:
```
leaq _ZN13do_fail_empty9file_line20h339df6a0541e837eIaaE(%rip), %rdi
callq _ZN6unwind31begin_unwind_no_time_to_explain20h33184cfdcce4dfd8QTdE@PLT
```
do_fail_fmt:
```
#[inline(never)]
fn do_fail_fmt() {
fail!("guh{}", "faw")
}
```
do_fail_fmt before:
```
... (snip lots of fmt stuff)
callq _ZN3fmt22Arguments$LT$$x27a$GT$3new20he09b3a3f473879c41paE
leaq 144(%rsp), %rsi
movabsq $23, %rdx
leaq "str\"str\"(1494)"(%rip), %rax
leaq 32(%rsp), %rcx
movq %rcx, 160(%rsp)
movq 160(%rsp), %rdi
movq %rax, 144(%rsp)
movq $19, 152(%rsp)
callq _ZN6unwind16begin_unwind_fmt20h3ebeb42f4d189b2buQdE@PLT
```
do_fail_fmt after:
```
... (snip lots of fmt stuff)
callq _ZN3fmt22Arguments$LT$$x27a$GT$3new20h42e5bb8d1711ee61OqaE
leaq _ZN11do_fail_fmt7run_fmt9file_line20h339df6a0541e837eFbaE(%rip), %rsi
leaq 32(%rsp), %rax
movq %rax, 144(%rsp)
movq 144(%rsp), %rdi
callq _ZN6unwind16begin_unwind_fmt20hfdcadc14d188656biRdE@PLT
```
File size increases.
file size before:
```
-rw-rw-r-- 1 brian brian 100501740 Jul 24 23:28 /home/brian/dev/rust2/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc-4e7c5e5c.rlib
-rwxrwxr-x 1 brian brian 21201780 Jul 24 23:27 /home/brian/dev/rust2/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc-4e7c5e5c.so
```
file size after:
```
-rw-rw-r-- 1 brian brian 101542484 Jul 25 00:34 x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc-4e7c5e5c.rlib
-rwxrwxr-x 1 brian brian 21348862 Jul 25 00:34 x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc-4e7c5e5c.so
```
Text size decreases by 52486 while data size increases by 143686.
section size before:
```
text data bss dec hex filename
12712262 5924997 368 18637627 11c633b x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc-4e7c5e5c.so
```
section size after:
```
text data bss dec hex filename
12659776 6068683 368 18728827 11dc77b /home/brian/dev/rust/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc-4e7c5e5c.so
```
I don't know if anything can be learned from these benchmarks. Looks like a wash.
std bench before:
```
test collections::hashmap::bench::find_existing ... bench: 43452 ns/iter (+/- 2423)
test collections::hashmap::bench::find_nonexisting ... bench: 42416 ns/iter (+/- 3996)
test collections::hashmap::bench::find_pop_insert ... bench: 214 ns/iter (+/- 11)
test collections::hashmap::bench::hashmap_as_queue ... bench: 123 ns/iter (+/- 6)
test collections::hashmap::bench::insert ... bench: 153 ns/iter (+/- 14)
test collections::hashmap::bench::new_drop ... bench: 547 ns/iter (+/- 259)
test collections::hashmap::bench::new_insert_drop ... bench: 682 ns/iter (+/- 366)
test io::buffered::test::bench_buffered_reader ... bench: 1046 ns/iter (+/- 86)
test io::buffered::test::bench_buffered_stream ... bench: 2156 ns/iter (+/- 801)
test io::buffered::test::bench_buffered_writer ... bench: 1057 ns/iter (+/- 75)
test io::extensions::bench::u64_from_be_bytes_4_aligned ... bench: 80 ns/iter (+/- 5)
test io::extensions::bench::u64_from_be_bytes_4_unaligned ... bench: 81 ns/iter (+/- 6)
test io::extensions::bench::u64_from_be_bytes_7_aligned ... bench: 80 ns/iter (+/- 4)
test io::extensions::bench::u64_from_be_bytes_7_unaligned ... bench: 69 ns/iter (+/- 4)
test io::extensions::bench::u64_from_be_bytes_8_aligned ... bench: 69 ns/iter (+/- 3)
test io::extensions::bench::u64_from_be_bytes_8_unaligned ... bench: 81 ns/iter (+/- 4)
test io::mem::test::bench_buf_reader ... bench: 628 ns/iter (+/- 18)
test io::mem::test::bench_buf_writer ... bench: 478 ns/iter (+/- 19)
test io::mem::test::bench_mem_reader ... bench: 712 ns/iter (+/- 44)
test io::mem::test::bench_mem_writer_001_0000 ... bench: 31 ns/iter (+/- 1)
test io::mem::test::bench_mem_writer_001_0010 ... bench: 51 ns/iter (+/- 3)
test io::mem::test::bench_mem_writer_001_0100 ... bench: 121 ns/iter (+/- 8)
test io::mem::test::bench_mem_writer_001_1000 ... bench: 774 ns/iter (+/- 47)
test io::mem::test::bench_mem_writer_100_0000 ... bench: 756 ns/iter (+/- 50)
test io::mem::test::bench_mem_writer_100_0010 ... bench: 2726 ns/iter (+/- 198)
test io::mem::test::bench_mem_writer_100_0100 ... bench: 8961 ns/iter (+/- 712)
test io::mem::test::bench_mem_writer_100_1000 ... bench: 105673 ns/iter (+/- 24711)
test num::bench::bench_pow_function ... bench: 5849 ns/iter (+/- 371)
test num::strconv::bench::f64::float_to_string ... bench: 662 ns/iter (+/- 202)
test num::strconv::bench::int::to_str_base_36 ... bench: 424 ns/iter (+/- 7)
test num::strconv::bench::int::to_str_bin ... bench: 1227 ns/iter (+/- 80)
test num::strconv::bench::int::to_str_dec ... bench: 466 ns/iter (+/- 13)
test num::strconv::bench::int::to_str_hex ... bench: 498 ns/iter (+/- 22)
test num::strconv::bench::int::to_str_oct ... bench: 502 ns/iter (+/- 229)
test num::strconv::bench::uint::to_str_base_36 ... bench: 375 ns/iter (+/- 7)
test num::strconv::bench::uint::to_str_bin ... bench: 1011 ns/iter (+/- 590)
test num::strconv::bench::uint::to_str_dec ... bench: 407 ns/iter (+/- 17)
test num::strconv::bench::uint::to_str_hex ... bench: 442 ns/iter (+/- 7)
test num::strconv::bench::uint::to_str_oct ... bench: 433 ns/iter (+/- 46)
test path::posix::bench::ends_with_path_home_dir ... bench: 167 ns/iter (+/- 10)
test path::posix::bench::ends_with_path_missmatch_jome_home ... bench: 148 ns/iter (+/- 6)
test path::posix::bench::is_ancestor_of_path_with_10_dirs ... bench: 221 ns/iter (+/- 31)
test path::posix::bench::join_abs_path_home_dir ... bench: 144 ns/iter (+/- 23)
test path::posix::bench::join_home_dir ... bench: 196 ns/iter (+/- 9)
test path::posix::bench::join_many_abs_path_home_dir ... bench: 143 ns/iter (+/- 6)
test path::posix::bench::join_many_home_dir ... bench: 195 ns/iter (+/- 8)
test path::posix::bench::path_relative_from_backward ... bench: 248 ns/iter (+/- 10)
test path::posix::bench::path_relative_from_forward ... bench: 241 ns/iter (+/- 13)
test path::posix::bench::path_relative_from_same_level ... bench: 296 ns/iter (+/- 11)
test path::posix::bench::push_abs_path_home_dir ... bench: 104 ns/iter (+/- 7)
test path::posix::bench::push_home_dir ... bench: 27311 ns/iter (+/- 2727)
test path::posix::bench::push_many_abs_path_home_dir ... bench: 109 ns/iter (+/- 5)
test path::posix::bench::push_many_home_dir ... bench: 23263 ns/iter (+/- 1726)
test rand::bench::rand_isaac ... bench: 884 ns/iter (+/- 31) = 904 MB/s
test rand::bench::rand_isaac64 ... bench: 440 ns/iter (+/- 126) = 1818 MB/s
test rand::bench::rand_shuffle_100 ... bench: 2518 ns/iter (+/- 1371)
test rand::bench::rand_std ... bench: 429 ns/iter (+/- 17) = 1864 MB/s
test rand::bench::rand_xorshift ... bench: 0 ns/iter (+/- 0) = 800000 MB/s
```
std bench after:
```
test collections::hashmap::bench::find_existing ... bench: 43635 ns/iter (+/- 4508)
test collections::hashmap::bench::find_nonexisting ... bench: 42323 ns/iter (+/- 1753)
test collections::hashmap::bench::find_pop_insert ... bench: 216 ns/iter (+/- 11)
test collections::hashmap::bench::hashmap_as_queue ... bench: 125 ns/iter (+/- 8)
test collections::hashmap::bench::insert ... bench: 153 ns/iter (+/- 63)
test collections::hashmap::bench::new_drop ... bench: 517 ns/iter (+/- 282)
test collections::hashmap::bench::new_insert_drop ... bench: 734 ns/iter (+/- 264)
test io::buffered::test::bench_buffered_reader ... bench: 1063 ns/iter (+/- 206)
test io::buffered::test::bench_buffered_stream ... bench: 2321 ns/iter (+/- 2302)
test io::buffered::test::bench_buffered_writer ... bench: 1060 ns/iter (+/- 24)
test io::extensions::bench::u64_from_be_bytes_4_aligned ... bench: 69 ns/iter (+/- 2)
test io::extensions::bench::u64_from_be_bytes_4_unaligned ... bench: 81 ns/iter (+/- 7)
test io::extensions::bench::u64_from_be_bytes_7_aligned ... bench: 70 ns/iter (+/- 5)
test io::extensions::bench::u64_from_be_bytes_7_unaligned ... bench: 69 ns/iter (+/- 5)
test io::extensions::bench::u64_from_be_bytes_8_aligned ... bench: 80 ns/iter (+/- 6)
test io::extensions::bench::u64_from_be_bytes_8_unaligned ... bench: 81 ns/iter (+/- 5)
test io::mem::test::bench_buf_reader ... bench: 663 ns/iter (+/- 44)
test io::mem::test::bench_buf_writer ... bench: 489 ns/iter (+/- 17)
test io::mem::test::bench_mem_reader ... bench: 700 ns/iter (+/- 23)
test io::mem::test::bench_mem_writer_001_0000 ... bench: 31 ns/iter (+/- 3)
test io::mem::test::bench_mem_writer_001_0010 ... bench: 49 ns/iter (+/- 5)
test io::mem::test::bench_mem_writer_001_0100 ... bench: 112 ns/iter (+/- 6)
test io::mem::test::bench_mem_writer_001_1000 ... bench: 765 ns/iter (+/- 59)
test io::mem::test::bench_mem_writer_100_0000 ... bench: 727 ns/iter (+/- 54)
test io::mem::test::bench_mem_writer_100_0010 ... bench: 2586 ns/iter (+/- 215)
test io::mem::test::bench_mem_writer_100_0100 ... bench: 8846 ns/iter (+/- 439)
test io::mem::test::bench_mem_writer_100_1000 ... bench: 105747 ns/iter (+/- 17443)
test num::bench::bench_pow_function ... bench: 5844 ns/iter (+/- 421)
test num::strconv::bench::f64::float_to_string ... bench: 669 ns/iter (+/- 571)
test num::strconv::bench::int::to_str_base_36 ... bench: 417 ns/iter (+/- 24)
test num::strconv::bench::int::to_str_bin ... bench: 1216 ns/iter (+/- 36)
test num::strconv::bench::int::to_str_dec ... bench: 466 ns/iter (+/- 24)
test num::strconv::bench::int::to_str_hex ... bench: 492 ns/iter (+/- 8)
test num::strconv::bench::int::to_str_oct ... bench: 496 ns/iter (+/- 295)
test num::strconv::bench::uint::to_str_base_36 ... bench: 366 ns/iter (+/- 8)
test num::strconv::bench::uint::to_str_bin ... bench: 1005 ns/iter (+/- 69)
test num::strconv::bench::uint::to_str_dec ... bench: 396 ns/iter (+/- 20)
test num::strconv::bench::uint::to_str_hex ... bench: 435 ns/iter (+/- 4)
test num::strconv::bench::uint::to_str_oct ... bench: 436 ns/iter (+/- 451)
test path::posix::bench::ends_with_path_home_dir ... bench: 171 ns/iter (+/- 6)
test path::posix::bench::ends_with_path_missmatch_jome_home ... bench: 152 ns/iter (+/- 6)
test path::posix::bench::is_ancestor_of_path_with_10_dirs ... bench: 215 ns/iter (+/- 8)
test path::posix::bench::join_abs_path_home_dir ... bench: 143 ns/iter (+/- 6)
test path::posix::bench::join_home_dir ... bench: 192 ns/iter (+/- 29)
test path::posix::bench::join_many_abs_path_home_dir ... bench: 144 ns/iter (+/- 9)
test path::posix::bench::join_many_home_dir ... bench: 194 ns/iter (+/- 19)
test path::posix::bench::path_relative_from_backward ... bench: 254 ns/iter (+/- 15)
test path::posix::bench::path_relative_from_forward ... bench: 244 ns/iter (+/- 17)
test path::posix::bench::path_relative_from_same_level ... bench: 293 ns/iter (+/- 27)
test path::posix::bench::push_abs_path_home_dir ... bench: 108 ns/iter (+/- 5)
test path::posix::bench::push_home_dir ... bench: 32292 ns/iter (+/- 4361)
test path::posix::bench::push_many_abs_path_home_dir ... bench: 108 ns/iter (+/- 6)
test path::posix::bench::push_many_home_dir ... bench: 20305 ns/iter (+/- 1331)
test rand::bench::rand_isaac ... bench: 888 ns/iter (+/- 35) = 900 MB/s
test rand::bench::rand_isaac64 ... bench: 439 ns/iter (+/- 17) = 1822 MB/s
test rand::bench::rand_shuffle_100 ... bench: 2582 ns/iter (+/- 1001)
test rand::bench::rand_std ... bench: 431 ns/iter (+/- 93) = 1856 MB/s
test rand::bench::rand_xorshift ... bench: 0 ns/iter (+/- 0) = 800000 MB/s
```
|
|
This commit applies stability attributes to the contents of these modules,
summarized here:
* The `unit` and `bool` modules have become #[unstable] as they are purely meant
for documentation purposes and are candidates for removal.
* The `ty` module has been deprecated, and the inner `Unsafe` type has been
renamed to `UnsafeCell` and moved to the `cell` module. The `marker1` field
has been removed as the compiler now always infers `UnsafeCell` to be
invariant. The `new` method i stable, but the `value` field, `get` and
`unwrap` methods are all unstable.
* The `tuple` module has its name as stable, the naming of the `TupleN` traits
as stable while the methods are all #[unstable]. The other impls in the module
have appropriate stability for the corresponding trait.
* The `arc` module has received the exact same treatment as the `rc` module
previously did.
* The `any` module has its name as stable. The `Any` trait is also stable, with
a new private supertrait which now contains the `get_type_id` method. This is
to make the method a private implementation detail rather than a public-facing
detail.
The two extension traits in the module are marked #[unstable] as they will not
be necessary with DST. The `is` method is #[stable], the as_{mut,ref} methods
have been renamed to downcast_{mut,ref} and are #[unstable].
The extension trait `BoxAny` has been clarified as to why it is unstable as it
will not be necessary with DST.
This is a breaking change because the `marker1` field was removed from the
`UnsafeCell` type. To deal with this change, you can simply delete the field and
only specify the value of the `data` field in static initializers.
[breaking-change]
|
|
This reverts commit c61f9763e2e03afbe62445877ceb3ed15e22e123.
Conflicts:
src/librustrt/unwind.rs
src/libstd/macros.rs
|
|
Passing one pointer takes less code than one pointer and an integer.
|
|
This eliminates the last vestige of the `~` syntax.
Instead of `~self`, write `self: Box<TypeOfSelf>`; instead of `mut
~self`, write `mut self: Box<TypeOfSelf>`, replacing `TypeOfSelf` with
the self-type parameter as specified in the implementation.
Closes #13885.
[breaking-change]
|
|
This also removes checks in other methods of `CString`
Breaking changes:
* `CString::new` now fails if `buf` is null. To avoid this add a check
before creatng a new `CString` .
* The `is_null` and `is_not_null` methods are deprecated, because a
`CString` cannot be null.
* Other methods which used to fail if the `CString` was null do not fail anymore
[breaking-change]
|
|
We use use `from_utf8_lossy` to convert it to a MaybeOwned string, to
avoid failing in case the CString contains invalid UTF-8
|
|
Implement for Vec, DList, RingBuf. Add MutableSeq to the prelude.
Since the collections traits are in the prelude most consumers of
these methods will continue to work without change.
[breaking-change]
|
|
Adds a new runtime unwinding function that encapsulates the printing of the words "explicit failure" when `fail!()` is called w/o arguments.
The before/after optimized assembly:
```
leaq "str\"str\"(1412)"(%rip), %rax
movq %rax, 24(%rsp)
movq $16, 32(%rsp)
leaq "str\"str\"(1413)"(%rip), %rax
movq %rax, 8(%rsp)
movq $19, 16(%rsp)
leaq 24(%rsp), %rdi
leaq 8(%rsp), %rsi
movl $11, %edx
callq _ZN6unwind12begin_unwind21h15836560661922107792E
```
```
leaq "str\"str\"(1369)"(%rip), %rax
movq %rax, 8(%rsp)
movq $19, 16(%rsp)
leaq 8(%rsp), %rdi
movl $11, %esi
callq _ZN6unwind31begin_unwind_no_time_to_explain20hd1c720cdde6a116480dE@PLT
```
Before/after filesizes:
rwxrwxr-x 1 brian brian 21479503 Jul 20 22:09 stage2-old/lib/librustc-4e7c5e5c.so
rwxrwxr-x 1 brian brian 21475415 Jul 20 22:30 x86_64-unknown-linux-gnu/stage2/lib/librustc-4e7c5e5c.so
This is the lowest-hanging fruit in the fail-bloat wars. Further fixes are going to require harder tradeoffs.
r? @pcwalton
|
|
|
|
Adds a special-case fail function, rustrt::unwind::begin_unwind_no_time_to_explain,
that encapsulates the printing of the words "explicit failure".
The before/after optimized assembly:
```
leaq "str\"str\"(1369)"(%rip), %rax
movq %rax, 8(%rsp)
movq $19, 16(%rsp)
leaq 8(%rsp), %rdi
movl $11, %esi
callq _ZN6unwind31begin_unwind_no_time_to_explain20hd1c720cdde6a116480dE@PLT
```
```
leaq "str\"str\"(1412)"(%rip), %rax
movq %rax, 24(%rsp)
movq $16, 32(%rsp)
leaq "str\"str\"(1413)"(%rip), %rax
movq %rax, 8(%rsp)
movq $19, 16(%rsp)
leaq 24(%rsp), %rdi
leaq 8(%rsp), %rsi
movl $11, %edx
callq _ZN6unwind12begin_unwind21h15836560661922107792E
```
Before/after filesizes:
rwxrwxr-x 1 brian brian 21479503 Jul 20 22:09 stage2-old/lib/librustc-4e7c5e5c.so
rwxrwxr-x 1 brian brian 21475415 Jul 20 22:30 x86_64-unknown-linux-gnu/stage2/lib/librustc-4e7c5e5c.so
|
|
I blame @ChrisMorgan for the hyphens.
|
|
This implements RFC 39. Omitted lifetimes in return values will now be
inferred to more useful defaults, and an error is reported if a lifetime
in a return type is omitted and one of the two lifetime elision rules
does not specify what it should be.
This primarily breaks two uncommon code patterns. The first is this:
unsafe fn get_foo_out_of_thin_air() -> &Foo {
...
}
This should be changed to:
unsafe fn get_foo_out_of_thin_air() -> &'static Foo {
...
}
The second pattern that needs to be changed is this:
enum MaybeBorrowed<'a> {
Borrowed(&'a str),
Owned(String),
}
fn foo() -> MaybeBorrowed {
Owned(format!("hello world"))
}
Change code like this to:
enum MaybeBorrowed<'a> {
Borrowed(&'a str),
Owned(String),
}
fn foo() -> MaybeBorrowed<'static> {
Owned(format!("hello world"))
}
Closes #15552.
[breaking-change]
|
|
* Deprecated `to_owned` in favor of `to_vec`
* Deprecated `into_owned` in favor of `into_vec`
[breaking-change]
|
|
This PR is the outcome of the library stabilization meeting for the
`liballoc::owned` and `libcore::cell` modules.
Aside from the stability attributes, there are a few breaking changes:
* The `owned` modules is now named `boxed`, to better represent its
contents. (`box` was unavailable, since it's a keyword.) This will
help avoid the misconception that `Box` plays a special role wrt
ownership.
* The `AnyOwnExt` extension trait is renamed to `BoxAny`, and its `move`
method is renamed to `downcast`, in both cases to improve clarity.
* The recently-added `AnySendOwnExt` extension trait is removed; it was
not being used and is unnecessary.
[breaking-change]
|
|
This PR is the outcome of the library stabilization meeting for the
`liballoc::owned` and `libcore::cell` modules.
Aside from the stability attributes, there are a few breaking changes:
* The `owned` modules is now named `boxed`, to better represent its
contents. (`box` was unavailable, since it's a keyword.) This will
help avoid the misconception that `Box` plays a special role wrt
ownership.
* The `AnyOwnExt` extension trait is renamed to `BoxAny`, and its `move`
method is renamed to `downcast`, in both cases to improve clarity.
* The recently-added `AnySendOwnExt` extension trait is removed; it was
not being used and is unnecessary.
[breaking-change]
|
|
|
|
This commit changes the `io::process::Command` API to provide
fine-grained control over the environment:
* The `env` method now inserts/updates a key/value pair.
* The `env_remove` method removes a key from the environment.
* The old `env` method, which sets the entire environment in one shot,
is renamed to `env_set_all`. It can be used in conjunction with the
finer-grained methods. This renaming is a breaking change.
To support these new methods, the internal `env` representation for
`Command` has been changed to an optional `HashMap` holding owned
`CString`s (to support non-utf8 data). The `HashMap` is only
materialized if the environment is updated. The implementation does not
try hard to avoid allocation, since the cost of launching a process will
dwarf any allocation cost.
This patch also adds `PartialOrd`, `Eq`, and `Hash` implementations for
`CString`.
[breaking-change]
|
|
Closes #15544
|
|
[breaking-change]
|
|
|
|
|
|
|
|
Conflicts:
src/libstd/lib.rs
|
|
POSIX has recvfrom(2) and sendto(2), but their name seem not to be
suitable with Rust. We already renamed getpeername(2) and
getsockname(2), so I think it makes sense.
Alternatively, `receive_from` would be fine. However, we have `.recv()`
so I chose `recv_from`.
Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
|
|
floating point numbers for real.
This will break code that looks like:
let mut x = 0;
while ... {
x += 1;
}
println!("{}", x);
Change that code to:
let mut x = 0i;
while ... {
x += 1;
}
println!("{}", x);
Closes #15201.
[breaking-change]
|
|
This should be called rarely, but it was placed first in the list of
methods, making it very tempting to call.
|
|
|
|
These forms return the pointer directly, rather than the added
indirection, indentation, and inefficiencies of the closures in
`.with_ref` and `.with_mut_ref`. The two closure functions are
deprecated.
Replace
foo(c_str.with_ref(|p| p))
c_str.with_ref(|p| {
foo(p);
bar(p);
})
with
foo(c_str.as_ptr())
let p = c_str.as_ptr();
foo(p);
bar(p);
This change does mean that one has to be careful to avoid writing `let p
= x.to_c_str().as_ptr();` since the `CString` will be freed at the end
of the statement. Previously, `with_ref` was used (and `as_ptr` avoided)
for this reason, but Rust has strongly moved away from closures to more
RAII-style code, and most uses of `.with_ref` where in the form
`.with_ref(|p| p)` anyway, that is, they were exactly `.as_ptr`.
[breaking-change]
|
|
This change registers new snapshots, allowing `*T` to be removed from the language. This is a large breaking change, and it is recommended that if compiler errors are seen that any FFI calls are audited to determine whether they should be actually taking `*mut T`.
|
|
|
|
|
|
Most of the comments are available on the Task structure itself, but this commit
is aimed at making FFI-style usage of Rust tasks a little nicer.
Primarily, this commit enables re-use of tasks across multiple invocations. The
method `run` will no longer unconditionally destroy the task itself. Rather, the
task will be internally re-usable if the closure specified did not fail. Once a
task has failed once it is considered poisoned and it can never be used again.
Along the way I tried to document shortcomings of the current method of tearing
down a task, opening a few issues as well. For now none of the behavior is a
showstopper, but it's useful to acknowledge it. Also along the way I attempted
to remove as much `unsafe` code as possible, opting for safer abstractions.
|
|
This change starts denying `*T` in the parser. All code using `*T` should ensure
that the FFI call does indeed take `const T*` on the other side before renaming
the type to `*const T`.
Otherwise, all code can rename `*T` to `*const T`.
[breaking-change]
|
|
It's unclear what you are supposed to do with this memory.
Let's make that more clear.
|
|
This breaks a fair amount of code. The typical patterns are:
* `for _ in range(0, 10)`: change to `for _ in range(0u, 10)`;
* `println!("{}", 3)`: change to `println!("{}", 3i)`;
* `[1, 2, 3].len()`: change to `[1i, 2, 3].len()`.
RFC #30. Closes #6023.
[breaking-change]
|
