Commit Graph

19 Commits

Author SHA1 Message Date
Alex Crichton
a9bd447400 Roll std::run into std::io::process
The std::run module is a relic from a standard library long since past, and
there's not much use to having two modules to execute processes with where one
is slightly more convenient. This commit merges the two modules, moving lots of
functionality from std::run into std::io::process and then deleting
std::run.

New things you can find in std::io::process are:

* Process::new() now only takes prog/args
* Process::configure() takes a ProcessConfig
* Process::status() is the same as run::process_status
* Process::output() is the same as run::process_output
* I/O for spawned tasks is now defaulted to captured in pipes instead of ignored
* Process::kill() was added (plus an associated green/native implementation)
* Process::wait_with_output() is the same as the old finish_with_output()
* destroy() is now signal_exit()
* force_destroy() is now signal_kill()

Closes #2625
Closes #10016
2014-02-23 21:51:17 -08:00
Brian Anderson
3e57808a01 std: Move raw to std::raw
Issue #1457
2014-02-23 01:07:53 -08:00
Alex Crichton
7bb498bd7a Mass rename if_ok! to try!
This "bubble up an error" macro was originally named if_ok! in order to get it
landed, but after the fact it was discovered that this name is not exactly
desirable.

The name `if_ok!` isn't immediately clear that is has much to do with error
handling, and it doesn't look fantastic in all contexts (if if_ok!(...) {}). In
general, the agreed opinion about `if_ok!` is that is came in as subpar.

The name `try!` is more invocative of error handling, it's shorter by 2 letters,
and it looks fitting in almost all circumstances. One concern about the word
`try!` is that it's too invocative of exceptions, but the belief is that this
will be overcome with documentation and examples.

Close #12037
2014-02-20 09:16:52 -08:00
Alex Crichton
2eacc729e2 Fix staticlib outputs linking to blank archives
When creating a staticlib, it unzips all static archives it finds and then
inserts the files manually into the output file. This process is done through
`ar`, and `ar` doesn't like if you specify you want to add files and you don't
give it any files.

This case arose whenever you linked to an archive that didn't have any contents
or all of the contents were filtered out. This just involved ignoring the case
where the number of inputs we have is 0, because we don't have any files to add
anyway.
2014-02-18 16:07:09 -08:00
Alex Crichton
5e8ba7252a rustc: Remove io_error usage 2014-02-03 09:32:34 -08:00
Simon Sapin
b8c4149293 [std::str] Rename from_utf8_opt() to from_utf8(), drop the old from_utf8() behavior 2014-01-21 15:48:48 -08:00
chromatic
0578c15abd Fixed typos in comments of librustc backend. 2014-01-17 17:14:47 -08:00
Young-il Choi
c8c99429d2 librustc: move target dependent logic to back::link 2014-01-06 13:04:26 +09:00
Young-il Choi
19e97f5c5d librustc: ar call fix to support android cross compile on mac 2014-01-06 13:04:26 +09:00
Patrick Walton
02d31b7d1a librustc: De-@mut the additional library search paths 2013-12-26 15:54:31 -08:00
Alex Crichton
64faafba19 rustc: Optimize reading metadata by 4x
We were previously reading metadata via `ar p`, but as learned from rustdoc
awhile back, spawning a process to do something is pretty slow. Turns out LLVM
has an Archive class to read archives, but it cannot write archives.

This commits adds bindings to the read-only version of the LLVM archive class
(with a new type that only has a read() method), and then it uses this class
when reading the metadata out of rlibs. When you put this in tandem of not
compressing the metadata, reading the metadata is 4x faster than it used to be
The timings I got for reading metadata from the respective libraries was:

    libstd-04ff901e-0.9-pre.dylib    => 100ms
    libstd-04ff901e-0.9-pre.rlib     => 23ms
    librustuv-7945354c-0.9-pre.dylib => 4ms
    librustuv-7945354c-0.9-pre.rlib  => 1ms
    librustc-5b94a16f-0.9-pre.dylib  => 87ms
    librustc-5b94a16f-0.9-pre.rlib   => 35ms
    libextra-a6ebb16f-0.9-pre.dylib  => 63ms
    libextra-a6ebb16f-0.9-pre.rlib   => 15ms
    libsyntax-2e4c0458-0.9-pre.dylib => 86ms
    libsyntax-2e4c0458-0.9-pre.rlib  => 22ms

In order to always take advantage of these faster metadata read-times, I sort
the files in filesearch based on whether they have an rlib extension or not
(prefer all rlib files first).

Overall, this halved the compile time for a `fn main() {}` crate from 0.185s to
0.095s on my system (when preferring dynamic linking). Reading metadata is still
the slowest pass of the compiler at 0.035s, but it's getting pretty close to
linking at 0.021s! The next best optimization is to just not copy the metadata
from LLVM because that's the most expensive part of reading metadata right now.
2013-12-19 23:34:32 -08:00
Cadence Marseille
5de42701a8 Fix #10754 - std::run functions fail after io_error
The problem was that std::run::Process::new() was unwrap()ing the result
of std::io::process::Process::new(), which returns None in the case
where the io_error condition is raised to signal failure to start the
process.

Have std::run::Process::new() similarly return an Option<run::Process>
to reflect the fact that a subprocess might have failed to start. Update
utility functions run::process_status() and run::process_output() to
return Option<ProcessExit> and Option<ProcessOutput>, respectively.

Various parts of librustc and librustpkg needed to be updated to reflect
these API changes.

closes #10754
2013-12-14 12:50:04 -05:00
Alex Crichton
ee618e1e75 Don't always modify the symbol table in rlibs
Turns out that one some platforms the ar/ranlib tool will die with an assertion
if the file being added doesn't actually have any symbols (or if it's just not
an object file presumably).

This functionality is already all exercised on the bots, it just turns out that
the bots don't have an ar tool which dies in this situation, so it's difficult
for me to add a test.

Closes #10907
2013-12-11 19:37:26 -08:00
Alex Crichton
fce4a174b9 Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:

* When compiling an rlib, in addition to insdering foo.o into the archive, also
  insert foo.bc (the LLVM bytecode) of the optimized module.

* When the compiler detects the -Z lto option, it will attempt to perform LTO on
  a staticlib or binary output. The compiler will emit an error if a dylib or
  rlib output is being generated.

* The actual act of performing LTO is as follows:

    1. Force all upstream libraries to have an rlib version available.
    2. Load the bytecode of each upstream library from the rlib.
    3. Link all this bytecode into the current LLVM module (just using llvm
       apis)
    4. Run an internalization pass which internalizes all symbols except those
       found reachable for the local crate of compilation.
    5. Run the LLVM LTO pass manager over this entire module

    6a. If assembling an archive, then add all upstream rlibs into the output
        archive. This ignores all of the object/bitcode/metadata files rust
        generated and placed inside the rlibs.
    6b. If linking a binary, create copies of all upstream rlibs, remove the
        rust-generated object-file, and then link everything as usual.

As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.

Closes #10741
Closes #10740
2013-12-09 14:41:49 -08:00
Alex Crichton
52b835c5e7 Store metadata separately in rlib files
Right now whenever an rlib file is linked against, all of the metadata from the
rlib is pulled in to the final staticlib or binary. The reason for this is that
the metadata is currently stored in a section of the object file. Note that this
is intentional for dynamic libraries in order to distribute metadata bundled
with static libraries.

This commit alters the situation for rlib libraries to instead store the
metadata in a separate file in the archive. In doing so, when the archive is
passed to the linker, none of the metadata will get pulled into the result
executable. Furthermore, the metadata file is skipped when assembling rlibs into
an archive.

The snag in this implementation comes with multiple output formats. When
generating a dylib, the metadata needs to be in the object file, but when
generating an rlib this needs to be separate. In order to accomplish this, the
metadata variable is inserted into an entirely separate LLVM Module which is
then codegen'd into a different location (foo.metadata.o). This is then linked
into dynamic libraries and silently ignored for rlib files.

While changing how metadata is inserted into archives, I have also stopped
compressing metadata when inserted into rlib files. We have wanted to stop
compressing metadata, but the sections it creates in object file sections are
apparently too large. Thankfully if it's just an arbitrary file it doesn't
matter how large it is.

I have seen massive reductions in executable sizes, as well as staticlib output
sizes (to confirm that this is all working).
2013-12-09 08:25:58 -08:00
Kevin Ballard
408dc5ad1b Revert "libstd: Change Path::new to Path::init."
This reverts commit c54427ddfb.

Leave the #[ignores] in that were added to rustpkg tests.

Conflicts:
	src/librustc/driver/driver.rs
	src/librustc/metadata/creader.rs
2013-12-04 22:33:53 -08:00
Alex Crichton
cb823b09df Search for libfoo.a on windows as well as foo.lib
Turns out LLVM only builds libfoo.a libraries, so we're going to need this logic
to statically link librustc
2013-12-03 08:59:09 -08:00
Alex Crichton
56e4c82a38 Test fixes and merge conflicts 2013-11-30 14:34:59 -08:00
Alex Crichton
e338a4154b Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.

When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.

Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.

Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:

* If both a .dylib and .rlib are found for a rust library, the compiler will
  prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
  overridable by explicitly saying what flavor you'd like (rlib, staticlib,
  dylib).
* If no options are passed to the command line, and no crate_type is found in
  the destination crate, then an executable is generated

With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.

This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.

Closes #552
2013-11-29 18:36:13 -08:00