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).
This moves `std::rand::distribitions::{Normal, StandardNormal}` to `...::distributions::normal`, reexporting `Normal` from `distributions` (and similarly for `Exp` and Exp1`), and adds:
- Log-normal
- Chi-squared
- F
- Student T
all of which are implemented in C++11's random library. Tests in 0424b8aded. Note that these are approximately half documentation & half implementation (of which a significant portion is boilerplate `}`'s and so on).
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
Before applying this patch, the included testcase fails with:
```
src/test/run-pass/xcrate-trait-lifetime-param.rs:20:10: 20:28 error: wrong number of lifetime parameters: expected 0 but found 1
src/test/run-pass/xcrate-trait-lifetime-param.rs:20 impl <'a> other::FromBuf<'a> for Reader<'a> {
^~~~~~~~~~~~~~~~~~
```
There's another example in my comments to #10506.
PR for issue #1749 mainly to get some feedback and suggestion. This adds a pass that warns if a function, struct, enum, or static item is never used. For the following code,
```rust
pub static pub_static: int = 0;
static priv_static: int = 0;
static used_static: int = 0;
pub fn pub_fn() { used_fn(); }
fn priv_fn() { let unused_struct = PrivStruct; }
fn used_fn() {}
pub struct PubStruct();
struct PrivStruct();
struct UsedStruct1 { x: int }
struct UsedStruct2(int);
struct UsedStruct3();
pub enum pub_enum { foo1, bar1 }
enum priv_enum { foo2, bar2 }
enum used_enum { foo3, bar3 }
fn foo() {
bar();
let unused_enum = foo2;
}
fn bar() {
foo();
}
fn main() {
let used_struct1 = UsedStruct1 { x: 1 };
let used_struct2 = UsedStruct2(1);
let used_struct3 = UsedStruct3;
let t = used_static;
let e = foo3;
}
```
it would add the following warnings:
```rust
/home/ktt3ja/test.rs:2:0: 2:28 warning: code is never used: `priv_static`, #[warn(dead_code)] on by default
/home/ktt3ja/test.rs:2 static priv_static: int = 0;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/ktt3ja/test.rs:6:0: 6:48 warning: code is never used: `priv_fn`, #[warn(dead_code)] on by default
/home/ktt3ja/test.rs:6 fn priv_fn() { let unused_struct = PrivStruct; }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/ktt3ja/test.rs:10:0: 10:20 warning: code is never used: `PrivStruct`, #[warn(dead_code)] on by default
/home/ktt3ja/test.rs:10 struct PrivStruct();
^~~~~~~~~~~~~~~~~~~~
/home/ktt3ja/test.rs:16:0: 16:29 warning: code is never used: `priv_enum`, #[warn(dead_code)] on by default
/home/ktt3ja/test.rs:16 enum priv_enum { foo2, bar2 }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/ktt3ja/test.rs:19:0: 22:1 warning: code is never used: `foo`, #[warn(dead_code)] on by default
/home/ktt3ja/test.rs:19 fn foo() {
/home/ktt3ja/test.rs:20 bar();
/home/ktt3ja/test.rs:21 let unused_enum = foo2;
/home/ktt3ja/test.rs:22 }
/home/ktt3ja/test.rs:24:0: 26:1 warning: code is never used: `bar`, #[warn(dead_code)] on by default
/home/ktt3ja/test.rs:24 fn bar() {
/home/ktt3ja/test.rs:25 foo();
/home/ktt3ja/test.rs:26 }
```
Furthermore, I would like to solicit some test cases since I haven't tested extensively and I'm still unclear about some of the things in here. For example, I'm not sure how reexports would affect this and just assumed that LiveContext (which is a copy of reachable::ReachableContext) does enough work to handle it. Also, the test case above doesn't include any impl or methods, etc.
Right now multiple targets/hosts is broken because the libdir passed for all of
the LLVM libraries is for the wrong architecture. By using the right arch
(target, not host), everything is linked and assembled just fine.
Right now multiple targets/hosts is broken because the libdir passed for all of
the LLVM libraries is for the wrong architecture. By using the right arch
(target, not host), everything is linked and assembled just fine.
Previously something like
struct NotEq;
#[deriving(Eq)]
struct Error {
foo: NotEq
}
would just point to the `foo` field, with no mention of the
`deriving(Eq)`. With this patch, the compiler creates a note saying "in
expansion of #[deriving(Eq)]" pointing to the Eq.
(includes some cleanup/preparation; the commit view might be nicer, to filter out the noise of the first one.)
This implements parts of the changes to `Result` and `Option` I proposed and discussed in this thread: https://mail.mozilla.org/pipermail/rust-dev/2013-November/006254.html
This PR includes:
- Adding `ok()` and `err()` option adapters for both `Result` variants.
- Removing `get_ref`, `expect` and iterator constructors for `Result`, as they are reachable with the variant adapters.
- Removing `Result`s `ToStr` bound on the error type because of composability issues. (See https://mail.mozilla.org/pipermail/rust-dev/2013-November/006283.html)
- Some warning cleanups
In order to keep up to date with changes to the libraries that `llvm-config`
spits out, the dependencies to the LLVM are a dynamically generated rust file.
This file is now automatically updated whenever LLVM is updated to get kept
up-to-date.
At the same time, this cleans out some old cruft which isn't necessary in the
makefiles in terms of dependencies.
Closes#10745Closes#10744
using the expansion info.
Previously something like
struct NotEq;
#[deriving(Eq)]
struct Error {
foo: NotEq
}
would just point to the `foo` field, with no mention of the
`deriving(Eq)`. With this patch, the compiler creates a note saying "in
expansion of #[deriving(Eq)]" pointing to the Eq.
This upgrades LLVM in order to make progress on #10708, and it's also been awhile since we last upgraded!
The contentious point of this upgrade is that all JIT support has been removed because LLVM is changing it and we're not keeping up with it.
as recommended by @huonw on this PR https://github.com/mozilla/rust/pull/10711 , I removed intermediate step that generates a string instead of directly writing to Writer without generating intermediate string.
Fixes#10565.
`'self` is still allowed for the moment, as it is used everywhere in the codebase. And I'm not sure if it still has a special meaning currently or not.
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).
Make trait lifetime parameters early bound in static fn type. Reasoning for this change is (hopefully) explained well enough in the comment, so I'll not duplicate it here. Fixes#10391.
r? @pnkfelix
It's useful to allow users to get at the internal std::rc::comm::Port,
and other such fields, since they implement important traits like
Select.
See [rust-dev] "select on std::comm::Port and different types" at https://mail.mozilla.org/pipermail/rust-dev/2013-November/006735.html for background.
Right now, as pointed out in #8132, it is very easy to introduce a subtle race
in the runtime. I believe that this is the cause of the current flakiness on the
bots.
I have taken the last idea mentioned in that issue which is to use a lock around
descheduling and context switching in order to solve this race.
Closes#8132
