333 Commits

Author SHA1 Message Date
Steven Fackler
c7cf5dc270 Method-ify CStore 2013-12-25 21:50:36 -07:00
Andreas Neuhaus
66e3fbebd9 Allow optional filename argument for --dep-info 2013-12-22 21:38:55 +01:00
bors
9d1de0b699 auto merge of #11077 : alexcrichton/rust/crate-id, r=cmr
Right now the --crate-id and related flags are all process *after* the entire
crate is parsed. This is less than desirable when used with makefiles because it
means that just to learn the output name of the crate you have to parse the
entire crate (unnecessary).

This commit changes the behavior to lift the handling of these flags much sooner
in the compilation process. This allows us to not have to parse the entire crate
and only have to worry about parsing the crate attributes themselves. The
related methods have all been updated to take an array of attributes rather than
a crate.

Additionally, this ceases duplication of the "what output are we producing"
logic in order to correctly handle things in the case of --test.

Finally, this adds tests for all of this functionality to ensure that it does
not regress.
2013-12-20 15:21:33 -08:00
Alex Crichton
87add53327 rustc: Improve crate id extraction
Right now the --crate-id and related flags are all process *after* the entire
crate is parsed. This is less than desirable when used with makefiles because it
means that just to learn the output name of the crate you have to parse the
entire crate (unnecessary).

This commit changes the behavior to lift the handling of these flags much sooner
in the compilation process. This allows us to not have to parse the entire crate
and only have to worry about parsing the crate attributes themselves. The
related methods have all been updated to take an array of attributes rather than
a crate.

Additionally, this ceases duplication of the "what output are we producing"
logic in order to correctly handle things in the case of --test.

Finally, this adds tests for all of this functionality to ensure that it does
not regress.
2013-12-20 09:10:11 -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
Corey Richardson
b25a0524dc Add some things to inspect crate-id's 2013-12-19 10:18:37 -05:00
bors
3272b002b3 auto merge of #10979 : alexcrichton/rust/less-bc, r=cmr
By performing this logic very late in the build process, it ended up leading to
bugs like those found in #10973 where certain stages of the build process
expected a particular output format which didn't end up being the case. In order
to fix this, the build output generation is moved very early in the build
process to the absolute first thing in phase 2.

Closes #10973
2013-12-17 11:36:42 -08:00
Kiet Tran
4f95dceb59 Detect stability attributes on methods.
If it's a trait method, this checks the stability attribute of the
method inside the trait definition. Otherwise, it checks the method
implementation itself.
2013-12-16 16:25:45 -05:00
Alex Crichton
6ebacf2fd7 Move logic for test output generation forward
By performing this logic very late in the build process, it ended up leading to
bugs like those found in #10973 where certain stages of the build process
expected a particular output format which didn't end up being the case. In order
to fix this, the build output generation is moved very early in the build
process to the absolute first thing in phase 2.

Closes #10973
2013-12-15 22:36:44 -08:00
bors
378897a09c auto merge of #10916 : alexcrichton/rust/nounwind, r=pcwalton
When performing LTO, the rust compiler has an opportunity to completely strip
all landing pads in all dependent libraries. I've modified the LTO pass to
recognize the -Z no-landing-pads option when also running an LTO pass to flag
everything in LLVM as nothrow. I've verified that this prevents any and all
invoke instructions from being emitted.

I believe that this is one of our best options for moving forward with
accomodating use-cases where unwinding doesn't really make sense. This will
allow libraries to be built with landing pads by default but allow usage of them
in contexts where landing pads aren't necessary.
2013-12-13 12:56:36 -08:00
bors
6e0b82e07c auto merge of #10909 : sanxiyn/rust/coherence, r=alexcrichton
Now coherence checking is always done.
2013-12-13 06:26:42 -08:00
Jack Moffitt
9365375c7f Add --dep-info to write Makefile-compatible dependency info.
When --dep-info is given, rustc will write out a `$input_base.d` file in the
output directory that contains Makefile compatible dependency information for
use with tools like make and ninja.
2013-12-12 13:57:47 -07:00
Alex Crichton
667d114f47 Disable all unwinding on -Z no-landing-pads LTO
When performing LTO, the rust compiler has an opportunity to completely strip
all landing pads in all dependent libraries. I've modified the LTO pass to
recognize the -Z no-landing-pads option when also running an LTO pass to flag
everything in LLVM as nothrow. I've verified that this prevents any and all
invoke instructions from being emitted.

I believe that this is one of our best options for moving forward with
accomodating use-cases where unwinding doesn't really make sense. This will
allow libraries to be built with landing pads by default but allow usage of them
in contexts where landing pads aren't necessary.

cc #10780
2013-12-11 09:18:20 -08:00
Jack Moffitt
b349036e5f Make crate hash stable and externally computable.
This replaces the link meta attributes with a pkgid attribute and uses a hash
of this as the crate hash. This makes the crate hash computable by things
other than the Rust compiler. It also switches the hash function ot SHA1 since
that is much more likely to be available in shell, Python, etc than SipHash.

Fixes #10188, #8523.
2013-12-10 17:04:24 -07:00
Seo Sanghyeon
55d2d8eec9 Remove -Z coherence 2013-12-11 02:56:06 +09: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
bors
e5f2021202 auto merge of #10874 : vadimcn/rust/integrated-as, r=alexcrichton
Last LLVM update seems to have fixed whatever prevented LLVM integrated assembler from generating correct unwind tables on Windows.   This PR switches Windows builds to use internal assembler by default.
Compilation via external assembler can still be requested via the newly added `-Z no-integrated-as` option.

Closes #8809
2013-12-09 01:01:43 -08:00
Vadim Chugunov
554c3c316e Use LLVM integrated assembler on Windows too. 2013-12-08 20:14:36 -08:00
Kiet Tran
c06dd0e0af Add dead-code warning pass 2013-12-08 02:55:27 -05:00
Alex Crichton
17a951c7bf Remove unused upcalls
The main one removed is rust_upcall_reset_stack_limit (continuation of #10156),
and this also removes the upcall_trace function. The was hidden behind a
`-Z trace` flag, but if you attempt to use this now you'll get a linker error
because there is no implementation of the 'upcall_trace' function. Due to this
no longer working, I decided to remove it entirely from the compiler (I'm also a
little unsure on what it did in the first place).
2013-12-05 16:29:16 -08:00
Alex Crichton
6b34ba242d Update LLVM and jettison jit support
LLVM's JIT has been updated numerous times, and we haven't been tracking it at
all. The existing LLVM glue code no longer compiles, and the JIT isn't used for
anything currently.

This also rebases out the FixedStackSegment support which we have added to LLVM.
None of this is still in use by the compiler, and there's no need to keep this
functionality around inside of LLVM.

This is needed to unblock #10708 (where we're tripping an LLVM assertion).
2013-12-05 09:15:54 -08:00
Kevin Ballard
408dc5ad1b Revert "libstd: Change Path::new to Path::init."
This reverts commit c54427ddfbbab41a39d14f2b1dc4f080cbc2d41b.

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
Philipp Brüschweiler
32688f8f74 rustc: filter out empty linker args
This is inspired by a mystifying linker failure when using `pkg-config` to
generate the linker args: `pkg-config` produces output that ends in a
space, thus resulting in an empty linker argument.

Also added some updates to the concerning error messages that helped
spotting this bug.
2013-12-01 19:29:01 +01: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
Patrick Walton
c54427ddfb libstd: Change Path::new to Path::init. 2013-11-29 10:55:13 -08:00
bors
faf4c939fb auto merge of #10670 : eddyb/rust/node-u32, r=alexcrichton
### Rationale
There is no reason to support more than 2³² nodes or names at this moment, as compiling something that big (even without considering the quadratic space usage of some analysis passes) would take at least **64GB**.
Meanwhile, some can't (or barely can) compile rustc because it requires almost **1.5GB**.

### Potential problems
Can someone confirm this doesn't affect metadata (de)serialization? I can't tell myself, I know nothing about it.

### Results
Some structures have a size reduction of 25% to 50%: [before](https://gist.github.com/luqmana/3a82a51fa9c86d9191fa) - [after](https://gist.github.com/eddyb/5a75f8973d3d8018afd3).
Sadly, there isn't a massive change in the memory used for compiling stage2 librustc (it doesn't go over **1.4GB** as [before](http://huonw.github.io/isrustfastyet/mem/), but I can barely see the difference).
However, my own testcase (previously peaking at **1.6GB** in typeck) shows a reduction of **200**-**400MB**.
2013-11-26 22:07:44 -08:00
Eduard Burtescu
7ed27b5531 Shink NodeId, CrateNum, Name and Mrk down to 32 bits on x64. 2013-11-27 07:02:25 +02:00
Patrick Walton
8ceb374ab7 librustc: Remove non-procedure uses of do from librustc, librustdoc,
and librustpkg.
2013-11-26 08:25:00 -08:00
Marvin Löbel
24b316a3b9 Removed unneccessary _iter suffixes from various APIs 2013-11-26 10:02:26 +01:00
Luqman Aden
6820ed4dcf Fix up mingw64 target. 2013-11-22 20:39:58 -05:00
Patrick Walton
7e3f20133a librustc: Change most uses of &fn() to ||. 2013-11-19 13:22:03 -08:00
bors
314d6f693f auto merge of #10277 : dcrewi/rust/missing-doc-and-visibility-rules, r=alexcrichton
Now the privacy pass returns enough information that other passes do not need to duplicate the visibility rules, and the missing_doc implementation is more consistent with other lint checks.
2013-11-13 10:16:29 -08:00
David Creswick
1f7eb4f9aa make missing_doc lint respect the visibility rules
Previously, the `exported_items` set created by the privacy pass was
incomplete. Specifically, it did not include items that had been defined
at a private path but then `pub use`d at a public path. This commit
finds all crate exports during the privacy pass. Consequently, some code
in the reachable pass and in rustdoc is no longer necessary. This commit
then removes the separate `MissingDocLintVisitor` lint pass, opting to
check missing_doc lint in the same pass as the other lint checkers using
the visibility result computed by the privacy pass.

Fixes #9777.
2013-11-13 11:31:59 -06:00
Alex Crichton
49ee49296b Move std::rt::io to std::io 2013-11-11 20:44:07 -08:00
bors
c0b7972f7d auto merge of #10422 : alexcrichton/rust/explicit-crate-map, r=pcwalton
As we start to move runtime components into the crate map, it's becoming harder
and harder to start the runtime from a C function as rust is embedded in another
application. Right now if you compile a rust crate as a dynamic library which is
then linked to another application, when using std::rt::start there are no I/O
local services, even though rustuv was linked against and requested. The reason
for this is that there is no top level crate map available specifying where to
find libuv I/O.

This option is not meant to be used regularly, but rather whenever compiling a
final library crate and linking it into another application. This lifts the
requirement that to get a crate map you must have the final destination be an
executable.
2013-11-11 16:11:22 -08:00
Alex Crichton
7755ffd013 Remove #[fixed_stack_segment] and #[rust_stack]
These two attributes are no longer useful now that Rust has decided to leave
segmented stacks behind. It is assumed that the rust task's stack is always
large enough to make an FFI call (due to the stack being very large).

There's always the case of stack overflow, however, to consider. This does not
change the behavior of stack overflow in Rust. This is still normally triggered
by the __morestack function and aborts the whole process.

C stack overflow will continue to corrupt the stack, however (as it did before
this commit as well). The future improvement of a guard page at the end of every
rust stack is still unimplemented and is intended to be the mechanism through
which we attempt to detect C stack overflow.

Closes #8822
Closes #10155
2013-11-11 10:40:34 -08:00
Alex Crichton
2eb92b77a9 Add a flag to force generating toplevel crate map
As we start to move runtime components into the crate map, it's becoming harder
and harder to start the runtime from a C function as rust is embedded in another
application. Right now if you compile a rust crate as a dynamic library which is
then linked to another application, when using std::rt::start there are no I/O
local services, even though rustuv was linked against and requested. The reason
for this is that there is no top level crate map available specifying where to
find libuv I/O.

This option is not meant to be used regularly, but rather whenever compiling a
final library crate and linking it into another application. This lifts the
requirement that to get a crate map you must have the final destination be an
executable.
2013-11-11 09:26:24 -08:00
bors
3851f908d1 auto merge of #10367 : alexcrichton/rust/system-abi, r=nikomatsakis
This adds an other ABI option which allows a custom selection over the target
architecture and OS. The only current candidate for this change is that kernel32
on win32 uses stdcall, but on win64 it uses the cdecl calling convention.
Otherwise everywhere else this is defined as using the Cdecl calling convention.

cc #10049
Closes #8774
2013-11-09 12:26:12 -08:00
Alex Crichton
2fcc70ec9d Add a "system" ABI
This adds an other ABI option which allows a custom selection over the target
architecture and OS. The only current candidate for this change is that kernel32
on win32 uses stdcall, but on win64 it uses the cdecl calling convention.
Otherwise everywhere else this is defined as using the Cdecl calling convention.

cc #10049
Closes #8774
2013-11-09 11:16:09 -08:00
Niko Matsakis
5e54a7323d Update various tests and libraries that were incorrectly
annotated.
2013-11-08 19:45:50 -05:00
Niko Matsakis
8e1de17757 Create a new pass to resolve named lifetimes; rscope is not only
used to indicate when anonymous regions (i.e., &T) are permitted
2013-11-08 16:52:36 -05:00
Huon Wilson
b95a8c63fd std::ascii: Provide a copyless [Ascii] -> str method.
This renames to_str_ascii to as_str_ascii and makes it non-copying,
which is possible now that strings no longer have a hidden extra
byte/null terminator.

Fixes #6120.
2013-11-08 10:20:06 +11:00
bors
658637baf4 auto merge of #10179 : alexcrichton/rust/rt-improvements, r=cmr
This fleshes out the io::file module a fair bit more, adding all of the functionality that I can think of that we would want. Some questions about the representation which I'm curious about:

* I modified `FileStat` to be a little less platform-agnostic, but it's still fairly platform-specific. I don't want to hide information that we have, but I don't want to depend on this information being available. One possible route is to have an `extra` field which has all this os-dependent stuff which is clearly documented as it should be avoided.

* Does it make sense for directory functions to be top-level functions instead of static methods? It seems silly to import `std::rt::io::file` and `std::rt::io::File` at the top of files that need to deal with directories and files.
2013-11-04 12:21:11 -08:00
Alex Crichton
3c3ed1499a Move io::file to io::fs and fns out of File
This renames the `file` module to `fs` because that more accurately describes
its current purpose (manipulating the filesystem, not just files).

Additionally, this adds an UnstableFileStat structure as a nested structure of
FileStat to signify that the fields should not be depended on. The structure is
currently flagged with #[unstable], but it's unlikely that it has much meaning.

Closes #10241
2013-11-04 10:28:55 -08:00
Alex Crichton
c3089a1d31 Fix the temporary name of the object file created
This file did not respect the #[link(name = "...")] attribute when it was
clearly intended to do so. The problem is that the crate attributes just weren't
passed in. This causes lots of problems in rust today because the object file
for all our libraries is inferred to be 'lib.o' because all of the files are
called 'lib.rs'.

I tried to figure out a good way to test for this, but I wasn't able to come up
with a good way that fit into our current testing framework. Nonetheless, I have
tested this locally and object files get named as they should. This should fix
compiling with `make -jN` again (because the object files are all different
again).
2013-11-03 23:56:45 -08:00
Alex Crichton
f19d083362 Fill out the remaining functionality in io::file
This adds bindings to the remaining functions provided by libuv, all of which
are useful operations on files which need to get exposed somehow.

Some highlights:

* Dropped `FileReader` and `FileWriter` and `FileStream` for one `File` type
* Moved all file-related methods to be static methods under `File`
* All directory related methods are still top-level functions
* Created `io::FilePermission` types (backed by u32) that are what you'd expect
* Created `io::FileType` and refactored `FileStat` to use FileType and
  FilePermission
* Removed the expanding matrix of `FileMode` operations. The mode of reading a
  file will not have the O_CREAT flag, but a write mode will always have the
  O_CREAT flag.

Closes #10130
Closes #10131
Closes #10121
2013-11-03 15:15:42 -08:00
Alex Crichton
9c1851019f Remove all blocking std::os blocking functions
This commit moves all thread-blocking I/O functions from the std::os module.
Their replacements can be found in either std::rt::io::file or in a hidden
"old_os" module inside of native::file. I didn't want to outright delete these
functions because they have a lot of special casing learned over time for each
OS/platform, and I imagine that these will someday get integrated into a
blocking implementation of IoFactory. For now, they're moved to a private module
to prevent bitrot and still have tests to ensure that they work.

I've also expanded the extensions to a few more methods defined on Path, most of
which were previously defined in std::os but now have non-thread-blocking
implementations as part of using the current IoFactory.

The api of io::file is in flux, but I plan on changing it in the next commit as
well.

Closes #10057
2013-11-03 15:15:42 -08:00
Heather
8a593a8bdb support for GNU configure syntax 2013-10-29 16:22:08 -07:00