| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
for `~str`/`~[]`.
Note that `~self` still remains, since I forgot to add support for
`Box<self>` before the snapshot.
How to update your code:
* Instead of `~EXPR`, you should write `box EXPR`.
* Instead of `~TYPE`, you should write `Box<Type>`.
* Instead of `~PATTERN`, you should write `box PATTERN`.
[breaking-change]
|
|
The compiler has previously been producing binaries on the order of 1.8MB for
hello world programs "fn main() {}". This is largely a result of the compilation
model used by compiling entire libraries into a single object file and because
static linking is favored by default.
When linking, linkers will pull in the entire contents of an object file if any
symbol from the object file is used. This means that if any symbol from a rust
library is used, the entire library is pulled in unconditionally, regardless of
whether the library is used or not.
Traditional C/C++ projects do not normally encounter these large executable
problems because their archives (rust's rlibs) are composed of many objects.
Because of this, linkers can eliminate entire objects from being in the final
executable. With rustc, however, the linker does not have the opportunity to
leave out entire object files.
In order to get similar benefits from dead code stripping at link time, this
commit enables the -ffunction-sections and -fdata-sections flags in LLVM, as
well as passing --gc-sections to the linker *by default*. This means that each
function and each global will be placed into its own section, allowing the
linker to GC all unused functions and data symbols.
By enabling these flags, rust is able to generate much smaller binaries default.
On linux, a hello world binary went from 1.8MB to 597K (a 67% reduction in
size). The output size of dynamic libraries remained constant, but the output
size of rlibs increased, as seen below:
libarena - 2.27% bigger ( 292872 => 299508)
libcollections - 0.64% bigger ( 6765884 => 6809076)
libflate - 0.83% bigger ( 186516 => 188060)
libfourcc - 14.71% bigger ( 307290 => 352498)
libgetopts - 4.42% bigger ( 761468 => 795102)
libglob - 2.73% bigger ( 899932 => 924542)
libgreen - 9.63% bigger ( 1281718 => 1405124)
libhexfloat - 13.88% bigger ( 333738 => 380060)
liblibc - 10.79% bigger ( 551280 => 610736)
liblog - 10.93% bigger ( 218208 => 242060)
libnative - 8.26% bigger ( 1362096 => 1474658)
libnum - 2.34% bigger ( 2583400 => 2643916)
librand - 1.72% bigger ( 1608684 => 1636394)
libregex - 6.50% bigger ( 1747768 => 1861398)
librustc - 4.21% bigger (151820192 => 158218924)
librustdoc - 8.96% bigger ( 13142604 => 14320544)
librustuv - 4.13% bigger ( 4366896 => 4547304)
libsemver - 2.66% bigger ( 396166 => 406686)
libserialize - 1.91% bigger ( 6878396 => 7009822)
libstd - 3.59% bigger ( 39485286 => 40902218)
libsync - 3.95% bigger ( 1386390 => 1441204)
libsyntax - 4.96% bigger ( 35757202 => 37530798)
libterm - 13.99% bigger ( 924580 => 1053902)
libtest - 6.04% bigger ( 2455720 => 2604092)
libtime - 2.84% bigger ( 1075708 => 1106242)
liburl - 6.53% bigger ( 590458 => 629004)
libuuid - 4.63% bigger ( 326350 => 341466)
libworkcache - 8.45% bigger ( 1230702 => 1334750)
This increase in size is a result of encoding many more section names into each
object file (rlib). These increases are moderate enough that this change seems
worthwhile to me, due to the drastic improvements seen in the final artifacts.
The overall increase of the stage2 target folder (not the size of an install)
went from 337MB to 348MB (3% increase).
Additionally, linking is generally slower when executed with all these new
sections plus the --gc-sections flag. The stage0 compiler takes 1.4s to link the
`rustc` binary, where the stage1 compiler takes 1.9s to link the binary. Three
megabytes are shaved off the binary. I found this increase in link time to be
acceptable relative to the benefits of code size gained.
This commit only enables --gc-sections for *executables*, not dynamic libraries.
LLVM does all the heavy lifting when producing an object file for a dynamic
library, so there is little else for the linker to do (remember that we only
have one object file).
I conducted similar experiments by putting a *module's* functions and data
symbols into its own section (granularity moved to a module level instead of a
function/static level). The size benefits of a hello world were seen to be on
the order of 400K rather than 1.2MB. It seemed that enough benefit was gained
using ffunction-sections that this route was less desirable, despite the lesser
increases in binary rlib size.
|
|
No subtyping, no interaction with traits. Partially addresses #9912.
|
|
|
|
|
|
|
|
Fixes issue #13213, that is linker errors when the inlined static has been optimized out of the exporting crate.
|
|
|
|
From the 0.10 changelog:
* The inner attribute syntax has changed from `#[foo];` to `#![foo]`.
|
|
This was missed when dropping the null-termination from our string
types. An explicit null byte can still be placed anywhere in a string if
desired, but there's no reason to stick one at the end of every string
constant.
|
|
This was missed when dropping the null-termination from our string
types. An explicit null byte can still be placed anywhere in a string if
desired, but there's no reason to stick one at the end of every string
constant.
|
|
Fixes #10474
|
|
|
|
Only supports crate level statics. No debug info is generated for
function level statics. Closes #9227.
|
|
(And fix some tests.)
|
|
|
|
variations.
Fixes issue #12787.
|
|
* Chan<T> => Sender<T>
* Port<T> => Receiver<T>
* Chan::new() => channel()
* constructor returns (Sender, Receiver) instead of (Receiver, Sender)
* local variables named `port` renamed to `rx`
* local variables named `chan` renamed to `tx`
Closes #11765
|
|
Fixes #12811 as described in the issue.
|
|
This test is blocking a snapshot. Apparently the snapshot bot doesn't print
'limited-debuginfo::main()' but rather just 'main()'. Who knew?
|
|
The `-g` flag does not take an argument anymore while the argument to `--debuginfo` becomes mandatory. This change makes it possible again to run the compiler like this:
`rustc -g ./file.rs`
This did not work before because `./file.rs` was misinterpreted as the argument to `-g`. In order to get limited debuginfo, one now has to use `--debuginfo=1`.
|
|
|
|
|
|
|
|
not interfere with RUSTFLAGS=-g
|
|
|
|
|
|
Move them all behind a new -C switch. This migrates some -Z flags and some
top-level flags behind this -C codegen option.
The -C flag takes values of the form "-C name=value" where the "=value" is
optional for some flags.
Flags affected:
* --llvm-args => -C llvm-args
* --passes => -C passes
* --ar => -C ar
* --linker => -C linker
* --link-args => -C link-args
* --target-cpu => -C target-cpu
* --target-feature => -C target-fature
* --android-cross-path => -C android-cross-path
* --save-temps => -C save-temps
* --no-rpath => -C no-rpath
* -Z no-prepopulate => -C no-prepopulate-passes
* -Z no-vectorize-loops => -C no-vectorize-loops
* -Z no-vectorize-slp => -C no-vectorize-slp
* -Z soft-float => -C soft-float
* -Z gen-crate-map => -C gen-crate-map
* -Z prefer-dynamic => -C prefer-dynamic
* -Z no-integrated-as => -C no-integrated-as
As a bonus, this also promotes the -Z extra-debug-info flag to a first class -g
or --debuginfo flag.
* -Z debug-info => removed
* -Z extra-debug-info => -g or --debuginfo
Closes #9770
Closes #12000
|
|
|
|
|
|
|
|
cc #12021
|
|
|
|
This is still used for Rust code (`Options.NoFramePointerElim = true`).
|
|
This can almost be fully disabled, as it no longer breaks retrieving a
backtrace on OS X as verified by @alexcrichton. However, it still
breaks retrieving the values of parameters. This should be fixable in
the future via a proper location list...
Closes #7477
|
|
|
|
|
|
Unique pointers and vectors currently contain a reference counting
header when containing a managed pointer.
This `{ ref_count, type_desc, prev, next }` header is not necessary and
not a sensible foundation for tracing. It adds needless complexity to
library code and is responsible for breakage in places where the branch
has been left out.
The `borrow_offset` field can now be removed from `TyDesc` along with
the associated handling in the compiler.
Closes #9510
Closes #11533
|
|
|
|
The `print!` and `println!` macros are now the preferred method of printing, and so there is no reason to export the `stdio` functions in the prelude. The functions have also been replaced by their macro counterparts in the tutorial and other documentation so that newcomers don't get confused about what they should be using.
|
|
`expand_include_str()` in libsyntax seems to have corrupted the CodeMap by always setting the BytePos of any included files to zero. It now uses `CodeMap::new_filemap()` which should set everything properly. This should fix issue #11322 but I don't want to close it before I have confirmation from the reporters that the problem is indeed fixed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
