The fail macro defines some function/static items internally, which got
a dead_code warning when `fail!()` is used inside a dead function. This
is ugly and unnecessarily reveals implementation details, so the
warnings can be squashed.
Fixes#16192.
This generalises the behaviour with struct fields (which recieve no
dead_code warning if they have a leading _), and other similar lints, to
all items, e.g. `fn _foo() {} fn main() {}` has no warnings.
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 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.)
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]
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).
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.)
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.
Generic extern functions written in Rust have their names mangled, as well as their internal clownshoe __rust_abi functions. This allows e.g. specific monomorphizations of these functions to be used as callbacks.
Closes#12502.
Fixes missing overflow lint for i64 #14269
The `type_overflow` lint, doesn't catch the overflow for `i64` because the overflow happens earlier in the parse phase when the `u64` as biggest possible int gets casted to `i64` , without checking the for
overflows.
We can't lint in the parse phase, so we emit a compiler error, as we do for overflowing `u64`
Perhaps a consistent behaviour would be to emit a parse error for *all* overflowing integer types.
See #14269
The `type_overflow` lint, doesn't catch the overflow for `i64` because
the overflow happens earlier in the parse phase when the `u64` as biggest
possible int gets casted to `i64` , without checking the for overflows.
We can't lint in the parse phase, so a refactoring of the `LitInt` type
was necessary.
The types `LitInt`, `LitUint` and `LitIntUnsuffixed` where merged to one
type `LitInt` which stores it's value as `u64`. An additional parameter was
added which indicate the signedness of the type and the sign of the value.
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]
Using the Show impl for Names created global symbols with names like
`"str\"str\"(1027)"`. This adjusts strings, binaries and vtables to
avoid using that impl.
Using the Show impl for Names created global symbols with names like
`"str\"str\"(1027)"`. This adjusts strings, binaries and vtables to
avoid using that impl.
Fixes#15799.
Before this commit, the LLVM IR of exported items was simply zip-compressed and stored as an object file inside rlib archives. This commit adds a header to this "object" containing a file identifier and a format version number so the compiler can deal with changes in the way bytecode objects are stored within rlibs.
While updating the format of bytecode objects, this commit also worksaround a problem in LLDB which could not handle odd-sized objects within archives before mid-2014.
This is an alternative to upgrading the way rvalues are handled in the
borrow check. Making rvalues handled more like lvalues in the borrow
check caused numerous problems related to double mutable borrows and
rvalue scopes. Rather than come up with more borrow check rules to try
to solve these problems, I decided to just forbid pattern bindings after
`@`. This affected fewer than 10 lines of code in the compiler and
libraries.
This breaks code like:
match x {
y @ z => { ... }
}
match a {
b @ Some(c) => { ... }
}
Change this code to use nested `match` or `let` expressions. For
example:
match x {
y => {
let z = y;
...
}
}
match a {
Some(c) => {
let b = Some(c);
...
}
}
Closes#14587.
[breaking-change]
When generating a unique symbol for things like closures or glue_drop,
we call token::gensym() to create a crate-unique Name. Recently, Name
changed its Show impl so it no longer prints as a number. This caused
symbols like glue_drop:1542 to become glue_drop:"glue_drop"(1542), or in
mangled form, glue_drop.$x22glue_drop$x22$LP$1542$RP$.
When generating a unique symbol for things like closures or glue_drop,
we call token::gensym() to create a crate-unique Name. Recently, Name
changed its Show impl so it no longer prints as a number. This caused
symbols like glue_drop:1542 to become glue_drop:"glue_drop"(1542), or in
mangled form, glue_drop.$x22glue_drop$x22$LP$1542$RP$.
Note: This PR is motivated by an attempt to write an custom syntax extension that tried to use `syntax::fold`, and that could only do so by fixing bugs in it and copying out private functions.
---
Refactored `syntax::fold`
Prior to this, the code there had a few issues:
- Default implementations inconsistenly either had the prefix `noop_` or
not.
- Some default methods where implemented in terms of a public noop function
for user code to call, others where implemented directly on the trait
and did not allow users of the trait to reuse the code.
- Some of the default implementations where private, and thus not reusable
for other implementors.
- There where some bugs where default implemntations called other default
implementations directly, rather than to the underlying Folder, with the
result of some ast nodes never being visted even if the user implemented that
method. (For example, the current Folder never folded struct fields)
This commit solves this situation somewhat radically by making __all__
`fold_...` functions in the module into Folder methods, and implementing
them all in terms of public `noop_...` functions for other implementors to
call out to.
Some public functions had to be renamed to fit the new system, so this is a
breaking change.
---
Also added a few trait implementations to `ast` types
Not included are two required patches:
* LLVM: segmented stack support for DragonFly [1]
* jemalloc: simple configure patches
[1]: http://reviews.llvm.org/D4705
Our implementation of ebml has diverged from the standard in order
to better serve the needs of the compiler, so it doesn't make much
sense to call what we have ebml anyore. Furthermore, our implementation
is pretty crufty, and should eventually be rewritten into a format
that better suits the needs of the compiler. This patch factors out
serialize::ebml into librbml, otherwise known as the Really Bad
Markup Language. This is a stopgap library that shouldn't be used
by end users, and will eventually be replaced by something better.
[breaking-change]
Currently, each time a function is monomorphized, all items within that function are translated. This is unnecessary work because the inner items already get translated when the function declaration is visited by `trans_item`. This patch adds a flag to the `FunctionContext` to prevent translation of items during monomorphization.
Remove the ability of the borrow checker to determine that repeated
dereferences of a Box<T> refer to the same memory object. This will
usually require one of two workarounds:
1) The interior of a Box<T> will sometimes need to be moved / borrowed
into a temporary before moving / borrowing individual derived paths.
2) A `ref x` pattern will have to be replaced with a `box ref x`
pattern.
Fixes#16094.
[breaking-change]
