I _think_ this is the right place to introduce strings. It's a bit hard to talk about without understanding pointers and ownership, but you need to have some idea of what's going on...
I wasn't 100% sure of what level of detail I wanted to go into things here. For example, 1:1 vs M:N tasks seems like a better distinction to leave to the Guide.
This does a few things:
- remove references to ~[] and the OwnedVector trait, which are both
obsolete
- correct the docs to say that this is the slice module, not the vec
module
- add a sentence pointing out that vectors are distinct from Vec
- remove documentation on Vec.
closes#15459
This leaves the `Share` trait at `std::kinds` via a `#[deprecated]` `pub use`
statement, but the `NoShare` struct is no longer part of `std::kinds::marker`
due to #12660 (the build cannot bootstrap otherwise).
All code referencing the `Share` trait should now reference the `Sync` trait,
and all code referencing the `NoShare` type should now reference the `NoSync`
type. The functionality and meaning of this trait have not changed, only the
naming.
Closes#16281
[breaking-change]
This does a few things:
- remove references to ~[] and the OwnedVector trait, which are both
obsolete
- correct the docs to say that this is the slice module, not the vec
module
- add a sentence pointing out that vectors are distinct from Vec
- remove documentation on Vec.
closes#15459
Now that rustdoc is spawning a child task, the program won't exit with a default
error code if the main task fails (because it never fails). This commit forces
the main task to wait for a child task in order to correctly propagate failure.
Closes#16341
Rust already builds all code as position independent by default, so the
linker can be told to build a position independent executable if it's
not disabled with `-C relocation-model=dynamic-no-pic`. Position
independent code does have a significant cost on i686 (not on x86_64 or
ARM) but there's no significant cost to linking code that's already
position independent as a position independent executable.
Address space layout randomization makes exploiting vulnerabilities much
more difficult by providing a statistical defence against an attempt to
find or modify existing code / data. Without ASLR, it's trivial to use a
vulnerability to take over control of the process via return-oriented
programming.
Rust code can be used for return-oriented programming whether it is safe
or unsafe, so even a fully safe application needs to be built as a
position independent executable to defend against vulnerabilities in
unsafe blocks or C libraries.
Sample program:
extern crate libc;
use std::mem;
static mut global: u32 = 5;
static constant: u32 = 5;
fn foo() {}
fn main() {
let local = 5;
println!("stack: {}, global: {}, constant: {}, fn: {}, lib fn: {}",
&local as *const u32,
unsafe { &global as *const u32 },
&constant as *const u32,
unsafe { mem::transmute::<_, *const ()>(foo) },
unsafe { mem::transmute::<_, *const ()>(libc::mprotect) });
}
Before:
stack: 0x3ff15eb9f94, global: 0x6ab488, constant: 0x47db40, fn: 0x4030e0, lib fn: 0x32749547530
stack: 0x3b5d47d80e4, global: 0x6ab488, constant: 0x47db40, fn: 0x4030e0, lib fn: 0x394469a7530
stack: 0x3fe2c4e5564, global: 0x6ab488, constant: 0x47db40, fn: 0x4030e0, lib fn: 0x399734a2530
stack: 0x3e525e0fb24, global: 0x6ab488, constant: 0x47db40, fn: 0x4030e0, lib fn: 0x2f62a810530
stack: 0x3b50fb3eae4, global: 0x6ab488, constant: 0x47db40, fn: 0x4030e0, lib fn: 0x2e590e86530
After:
stack: 0x38cf12c90a4, global: 0x3e2d46b488, constant: 0x3e2d23cf80, fn: 0x3e2d1c2510, lib fn: 0x2617d3b4530
stack: 0x3d733faf474, global: 0x7eb1839488, constant: 0x7eb160af80, fn: 0x7eb1590510, lib fn: 0x32d30c1f530
stack: 0x3bb42212ec4, global: 0x5bbb365488, constant: 0x5bbb136f80, fn: 0x5bbb0bc510, lib fn: 0x3595e6c1530
stack: 0x39f678c1ab4, global: 0x22c4e3c488, constant: 0x22c4c0df80, fn: 0x22c4b93510, lib fn: 0x3835b727530
stack: 0x3afb25bd394, global: 0x493eab2488, constant: 0x493e883f80, fn: 0x493e809510, lib fn: 0x3478d6a7530
This may also be necessary on other platforms, but I can only test on
Linux right now. Note that GDB gained support for debugging position
independent executables in version 7.1 (March 2010).
Made INVALID_HANDLE_VALUE actually a HANDLE.
Removed all useless casts during INVALID_HANDLE_VALUE comparisons.
Signed-off-by: Peter Atashian <retep998@gmail.com>
This leaves the `Share` trait at `std::kinds` via a `#[deprecated]` `pub use`
statement, but the `NoShare` struct is no longer part of `std::kinds::marker`
due to #12660 (the build cannot bootstrap otherwise).
All code referencing the `Share` trait should now reference the `Sync` trait,
and all code referencing the `NoShare` type should now reference the `NoSync`
type. The functionality and meaning of this trait have not changed, only the
naming.
Closes#16281
[breaking-change]
This requires avoiding `quote_...!` for constructing the parts of the
__test module, since that stringifies and reinterns the idents, losing
the special gensym'd nature of them. (#15962.)
Introduce syntax for lifetime bounds like `'b:'a`, meaning `'b outlives 'a`. Syntax currently does nothing but is needed for full fix to #5763. To use this syntax, the issue_5763_bootstrap feature guard is required.
meaning `'b outlives 'a`. Syntax currently does nothing but is needed for full
fix to #5763. To use this syntax, the issue_5763_bootstrap feature guard is
required.
Simplifying the code of methods: `nth`, `fold`, `rposition`, and iterators: `Filter`, `FilterMap`, `SkipWhile`.
```
before
test iter::bench_multiple_take ... bench: 15 ns/iter (+/- 0)
test iter::bench_rposition ... bench: 349 ns/iter (+/- 94)
test iter::bench_skip_while ... bench: 158 ns/iter (+/- 6)
after
test iter::bench_multiple_take ... bench: 15 ns/iter (+/- 0)
test iter::bench_rposition ... bench: 314 ns/iter (+/- 2)
test iter::bench_skip_while ... bench: 107 ns/iter (+/- 0)
```
@koalazen has the code for `Skip`.
Once #16011 is fixed, `min_max` could use a for loop.
