For historical reasons, "Win32" has been used in Rust codebase to mean "Windows OS in general".
This is confusing, especially now, that Rust supports Win64 builds.
[breaking-change]
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).
Extended `ast_map::Map` with an iterator over all node id's that match a path suffix.
Extended pretty printer to let users choose particular items to pretty print, either by indicating an integer node-id, or by providing a path suffix.
* Example 1: the suffix `typeck::check::check_struct` matches the item with the path `rustc::middle::typeck::check::check_struct` when compiling the `rustc` crate.
* Example 2: the suffix `and` matches `core::option::Option::and` and `core::result::Result::and` when compiling the `core` crate.
Refactored `pprust` slightly to support the pretty printer changes.
(See individual commits for more description.)
With this change:
* `--pretty variant=<node-id>` will print the item associated with
`<node-id>` (where `<node-id>` is an integer for some node-id in
the AST, and `variant` means one of {`normal`,`expanded`,...}).
* `--pretty variant=<path-suffix>` will print all of the items that
match the `<path-suffix>` (where `<path-suffix>` is a suffix of a
path, and `variant` again means one of {`normal`,`expanded`,...}).
Example 1: the suffix `typeck::check::check_struct` matches the
item with the path `rustc::middle::typeck::check::check_struct`
when compiling the `rustc` crate.
Example 2: the suffix `and` matches `core::option::Option::and`
and `core::result::Result::and` when compiling the `core` crate.
Both of the `--pretty variant=...` modes will include the full path to
the item in a comment that follows the item.
Note that when multiple paths match, then either:
1. all matching items are printed, in series; this is what happens in
the usual pretty-print variants, or
2. the compiler signals an error; this is what happens in flowgraph
printing.
----
Some drive-by improvements:
Heavily refactored the pretty-printing glue in driver.rs, introducing
a couple local traits to avoid cut-and-pasting very code segments that
differed only in how they accessed the `Session` or the
`ast_map::Map`. (Note the previous code had three similar calls to
`print_crate` which have all been unified in this revision; the
addition of printing individual node-ids exacerbated the situation
beyond tolerance.) We may want to consider promoting some of these
traits, e.g. `SessionCarrier`, for use more generally elsewhere in the
compiler; right now I have to double check how to access the `Session`
depending on what context I am hacking in.
Refactored `PpMode` to make the data directly reflect the fundamental
difference in the categories (in terms of printing source-code with
various annotations, versus printing a control-flow graph).
(also, addressed review feedback.)
This is useful e.g. for tools need a node-id, such as the flowgraph
pretty printer, since it can avoids the need to first pretty-print the
whole expanded,identified input in order to find out what the node-id
actually is.
It currently only supports path suffixes thst are made up of module
names (e.g. you cannot use the type instantiation form `a::<int>::b`
or `option::Option::unwrap_or` as a path suffix for this tool, though
the tool will produce paths that have non-modulues in the portion of
the path that is not included in the suffix).
(addressed review feedback too)
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.)
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>
