bors [Fri, 31 May 2013 07:43:45 +0000 (00:43 -0700)]
auto merge of #6833 : fdr/rust/fix-warnings, r=Aatch
Fix a laundry list of warnings involving unused imports that glutted
up compilation output. There are more, but there seems to be some
false positives (where 'remedy' appears to break the build), but this
particular set of fixes seems safe.
Daniel Farina [Thu, 30 May 2013 10:16:33 +0000 (03:16 -0700)]
Remove unnecessary 'use' forms
Fix a laundry list of warnings involving unused imports that glutted
up compilation output. There are more, but there seems to be some
false positives (where 'remedy' appears to break the build), but this
particular set of fixes seems safe.
bors [Thu, 30 May 2013 07:37:35 +0000 (00:37 -0700)]
auto merge of #6798 : alexcrichton/rust/doc-lints, r=pcwalton
These commits perform a variety of actions:
1. The linting of missing documentation has been consolidated under one `missing_doc` attribute, and many more things are linted about.
2. A test was added for linting missing documentation, which revealed a large number of corner cases in both linting and the `missing_doc` lint pass. Some notable edge cases:
* When compiling with `--test`, all `missing_doc` warnings are suppressed
* If any parent of the current item has `#[doc(hidden)]`, then the `missing_doc` warning is suppressed
3. Both the std and extra libraries were modified to `#[deny(missing_doc)]` by default.
I believe that the libraries are getting to the point where they're fairly well documented, and they should definitely stay that way. If developing a particular new module, it's easy enough to add `#[allow(missing_doc)]` at the top, but those should definitely be flags for removal in favor of actual documentation.
I added as much documentation as I could throughout std/extra, although I avoided trying to document things that I knew nothing about. I can't say that this lint pass will vouch for the quality of the documentation of std/extra, but it will certainly make sure that there's at least some describing words.
That being said, I may have a different opinion, so I don't mind amending these commits to turn off the lint by default for std/extra if people think otherwise.
bors [Wed, 29 May 2013 23:58:44 +0000 (16:58 -0700)]
auto merge of #6799 : Aatch/rust/pass-refactor, r=graydon
This refactors pass handling to use the argument names, so it can be used
in a similar manner to `opt`. This may be slightly less efficient than the
previous version, but it is much easier to maintain.
It also adds in the ability to specify a custom pipeline on the command
line, this overrides the normal passes, however. This should completely
close #2396.
bors [Wed, 29 May 2013 22:10:42 +0000 (15:10 -0700)]
auto merge of #6813 : pnkfelix/rust/fsk-issue-6805-ccache-support, r=catamorphism
Fix #6805: add --enable-ccache configure option to prefix compiler invocations with `ccache` to attempt to reuse common results, e.g. for LLVM (re)builds.
The information at developer [Note-ccache](../../wiki/Note-ccache) and at [ccache and clang concerns](http://petereisentraut.blogspot.fr/2011/09/ccache-and-clang-part-2.html) were what drove my introduction of the `-Qunused-arguments` and `CCACHE_CPP2` options. (Though I did confirm first-hand that at least the first really is necessary.)
Yes, one certainly can re-route how `gcc` and `clang` are resolved in one's PATH and use that as a way to invoke `ccache`. But I personally do not want to introduce that change to my own PATH, and this seems like a small enough change that it does not hurt to add it, at least for now. (I don't know what form it would take when we move over to `rustpkg`.)
Fix #6805: add --enable-ccache configure option to prefix compiler invocations with ccache to attempt to reuse common results, e.g. for LLVM (re)builds.
bors [Wed, 29 May 2013 20:29:06 +0000 (13:29 -0700)]
auto merge of #6803 : Thiez/rust/native_fmax_fmin, r=brson
Calls to the libc versions of fmin and fmax were relatively slow (perhaps because they could not be inlined?). This pull request provides f32 and f64 with fmin and fmax written in Rust, and shows a significant speed increase on my system; I used https://github.com/thiez/rustray as my benchmark, with --opt-level 3 it brings the ray-tracing time down from 10.8 seconds to about 9.2, which seemed significant to me.
bors [Wed, 29 May 2013 15:49:53 +0000 (08:49 -0700)]
auto merge of #6796 : sfackler/rust/FromBase64-type-fix, r=bstrie
Previously, FromBase64 was only implemented on ~[u8] and ~str when
any pointer would do. The implementations of FromBase64 are now
consistent with the implementations of ToBase64.
James Miller [Wed, 29 May 2013 08:08:20 +0000 (20:08 +1200)]
Further refactor optimization pass handling
This refactors pass handling to use the argument names, so it can be used
in a similar manner to `opt`. This may be slightly less efficient than the
previous version, but it is much easier to maintain.
It also adds in the ability to specify a custom pipeline on the command
line, this overrides the normal passes, however. This should completely
close #2396.
bors [Wed, 29 May 2013 05:16:50 +0000 (22:16 -0700)]
auto merge of #6784 : nikomatsakis/rust/moves-into-borrowck, r=pcwalton
Move the computation of what data is moved out of `liveness` and into `borrowck`. The resulting code is cleaner, since before we had a split distribution of responsibilities, and also this avoids having multiple implementations of the dataflow code. Liveness is still used to report warnings about useless writes. This will go away when we get the control-flow graph code landed (working on that).
Also adds borrow checker documentation.
Fixes #4384.
Required to support once fns and to properly fix closures (#2202).
First step to generalize our treatment of moves somewhat as well.
bors [Wed, 29 May 2013 04:01:53 +0000 (21:01 -0700)]
auto merge of #6778 : Aatch/rust/pass-refactor, r=graydon
Refactor the optimization passes to explicitly use the passes. This commit just re-implements the same passes as were already being run.
It also adds an option (behind `-Z`) to run the LLVM lint pass on the unoptimized IR.
This should close #2812. It is also the first step towards #2396
----------------
This is pretty much just an initial "get it out there" PR. With finer control over the optimization passes coming later. I also just blindly copied the passes we were already doing, so there could almost certainly be some more work in paring it down.
The other thing is the addition of the `mergefunctions` pass, which is currently enabled at `--opt-level=3` and does have a small impact on the code size. However the fact that it is at the end of the optimization pipeline is probably not ideal, so some more experimentation is in order.
Alex Crichton [Sat, 25 May 2013 06:05:31 +0000 (01:05 -0500)]
Define rustc's host triple at compile time
This way a cross-compiled rustc's answer to host_triple() is correct. The return
value of host_triple() reflects the actual host triple that the compiler was
build for, not the triple the compiler is being built on
projects / rust.git / log