Add Illumos support #31078

nbaksalyar · Jan 21, 2016

This pull request adds support for Illumos-based operating systems: SmartOS, OpenIndiana, and others. For now it's x86-64 only, as I'm not sure if 32-bit installations are widespread. This PR is based on #28589 by @potatosalad, and also closes #21000, #25845, and #25846.

Required changes in libc are already merged: rust-lang/libc#138

Here's a snapshot required to build a stage0 compiler:
https://s3-eu-west-1.amazonaws.com/nbaksalyar/rustc-sunos-snapshot.tar.gz
It passes all checks from make check.

There are some changes I'm not quite sure about, e.g. macro usage in src/libstd/num/f64.rs and DirEntry structure in src/libstd/sys/unix/fs.rs, so any comments on how to rewrite it better would be greatly appreciated.

Also, LLVM configure script might need to be patched to build it successfully, or a pre-built libLLVM should be used. Some details can be found here: https://llvm.org/bugs/show_bug.cgi?id=25409

Thanks!

r? @brson

rust-highfive · Jan 21, 2016

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @brson (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

alexcrichton · Jan 21, 2016

alexcrichton reviewed Jan 21, 2016

View changes

alexcrichton · Jan 21, 2016

src/librustc_back/target/x86_64_sun_solaris.rs

+    let mut base = super::sunos_base::opts();
+    base.pre_link_args.push("-m64".to_string());
+    base.pre_link_args.push("-lsocket".to_string());
+    base.pre_link_args.push("-lposix4".to_string());


This sorts of "default libraries" are typically linked where they're needed rather than by the compiler unconditionally. Do you know what symbols these are pulling in? I suspect they're only needed by the standard library so could the linkage directives go there instead?

Yes, these are mostly for socket functions and e.g. fork.
Could you please point out to the correct place to move it in libstd?

Sure thing, they'll probably reside in rtdeps.rs.

Out of curiosity, is sunos posix? Or would a "true port" of libstd contain an entirely different implementation of std::sys basically (e.g. how Windows is entirely separate from Unix)

Oh, completely missed it, thank you!

is sunos posix?

Yes, absolutely. I believe historically it's derived from the Unix SVR4 codebase, and mostly compatible with BSD-like OSes. And, as I understand it, at least Illumos (the open source Solaris fork) strives to be maximally compatible with other *nixes, and it includes e.g. GCC toolkit by default instead of some proprietary compilers. Actually, I'm not even sure that this port would work on the original Sun/Oracle Solaris - there are much more diversions from standards.

Ah ok cool, sounds good to me!

alexcrichton · Jan 21, 2016

alexcrichton reviewed Jan 21, 2016

View changes

alexcrichton · Jan 21, 2016

src/librustdoc/flock.rs

+        pub const F_UNLCK: libc::c_short = 3;
+        pub const F_SETLK: libc::c_int = 6;
+        pub const F_SETLKW: libc::c_int = 7;
+    }


If you're feeling ambitious you could also feel free to remove all these definitions in favor of using the ones in libc, although that's fine to leave for another PR

alexcrichton · Jan 21, 2016

alexcrichton reviewed Jan 21, 2016

View changes

alexcrichton · Jan 21, 2016

src/libstd/num/f64.rs

+        } else {
+            return NAN // log(-Inf) = NaN
+        }
+    )


Instead of a macro, could this be done with something like:

fn foo<F: Fn(f64) -> f64>(val: f64, f: F) -> f64 { if !cfg!(target_os = "sunos") { f(val) } else { // contents of this macro } }

Sure! I just wasn't sure about duplicate code & runtime checks.

Oh these'll all be optimized away, and it's best to have as little #[cfg] or macro code as possible generally

alexcrichton · Jan 21, 2016

alexcrichton reviewed Jan 21, 2016

View changes

alexcrichton · Jan 21, 2016

src/libstd/sys/unix/fd.rs

@@ -50,14 +50,14 @@ impl FileDesc {
        Ok(ret as usize)
    }

-    #[cfg(not(target_env = "newlib"))]
+    #[cfg(not(any(target_env = "newlib", target_os = "sunos")))]


Does sunos not have ioctl?

It does, but FIOCLEX apparently doesn't work there (although it's available). So the solution is to set the cloexex flag by the means of fcntl.
I figured it out through some indirect references, e.g.: https://forum.nginx.org/read.php?29,232210,232210 (notice the Solaris workaround).

Ah ok, sounds good to me

alexcrichton · Jan 21, 2016

alexcrichton reviewed Jan 21, 2016

View changes

alexcrichton · Jan 21, 2016

src/libstd/sys/unix/fs.rs

@@ -132,6 +139,32 @@ impl FromInner<raw::mode_t> for FilePermissions {
 impl Iterator for ReadDir {
    type Item = io::Result<DirEntry>;

+    #[cfg(target_os = "sunos")]


Does sunos not have readdir_r? In posix at least the readdir function isn't thread safe (I believe) and can be harmful to use, so it would be best to share implementations here if possible.

There is a readdir_r function, but it's non-standard (i.e. it doesn't comply to POSIX). And if you refer to the manpage for readdir(3C) on Illumos, it says the following:

It is safe to use readdir() in a threaded application, so long as only one thread reads from the directory stream at any given time. The readdir() function is generally preferred over the readdir_r() function.

Hm ok, but in the interest of sharing an implementation would it be possible to use the readdir_r function if it's present?

Hm. Well, it looks like there is a standard-compliant readdir_r, actually, though it seems to be linked in some special way. I'll try to figure it out, thanks!

@alexcrichton, as it seems, the implementation can't be shared - not because of readdir_r (it does have a standard-compliant version), but because of a quite interesting dirent structure. This struct def on Solaris/Illumos contains a zero-length array:

typedef struct dirent { ino_t d_ino; /* "inode number" of entry */ off_t d_off; /* offset of disk directory entry */ unsigned short d_reclen; /* length of this record */ char d_name[1]; /* name of file */ } dirent_t;

Notice the d_name field of length 1. I asked a question on this issue on the Rust users forum, but haven't found a definite answer. Experiments showed that Rust supports such structures, but not when they're nested in another structure - as is the case with std::fs::DirEntry and libc::dirent.

So, I guess, a separate implementation would be required, and as it's OS-specific anyway, I used the Solaris/Illumos-specific readdir function, as recommended by the man page.

What do you think?

Interesting! In that case if we need a whole separate implementation anyway then I'm fine sticking with readdir as a separate implementation. Can you add some documentation indicating that although this function is avoided on Linux it's ok to call on sunos?

Er hm, actually on second though it may be best to call readdir_r anyway because we already have to store the path locally. I guess whatever's easiest really

it may be best to call readdir_r anyway because we already have to store the path locally

Well, in this case I guess it's required to pre-allocate memory to store the path - the specific instructions from the man page are:

The caller must allocate storage pointed to by entry to be large enough for a dirent structure with an array of char d_name member containing at least NAME_MAX (that is, pathconf(directory, _PC_NAME_MAX)) plus one elements. (_PC_NAME_MAX is defined in <unistd.h>.)

I.e. that'd also require a separate handling too, as it seems.

I'm not quite sure about what would work best here, TBH, so for now I've added some comments describing the current implementation. Please let me know if it requires polishing or a better implementation!

Yeah it seems like that won't necessarily be any less onerous than this is already doing, so let's stick to what you've implemented here.

alexcrichton · Jan 21, 2016

alexcrichton reviewed Jan 21, 2016

View changes

alexcrichton · Jan 21, 2016

src/libstd/sys/unix/os.rs

+        } else {
+            let filename = CStr::from_ptr(path).to_bytes();
+            if filename[0] == b'/' {
+                Ok(PathBuf::from(<OsStr as OsStrExt>::from_bytes(filename)))


You may be able to lift these &[u8] -> &OsStr conversions outside of the if branch as it happens in both branches

alexcrichton · Jan 21, 2016

alexcrichton reviewed Jan 21, 2016

View changes

alexcrichton · Jan 21, 2016

src/libstd/sys/unix/os.rs

+            } else {
+                // Prepend current working directory to the path if
+                // it doesn't contain an absolute pathname.
+                return getcwd().map(|cwd| cwd.join(<OsStr as OsStrExt>::from_bytes(filename)))


The return here can be elided

alexcrichton · Jan 21, 2016

Quite exciting, thanks @nbaksalyar!

nbaksalyar · Jan 21, 2016

Thanks for the review, Alex! :)

brson · Jan 22, 2016

brson reviewed Jan 22, 2016

View changes

brson · Jan 22, 2016

configure

@@ -1,5 +1,13 @@
 #!/bin/sh

+# /bin/sh on Solaris is not a POSIX compatible shell, but /usr/bin/ksh is.


ksh -> bash

brson · Jan 22, 2016

brson reviewed Jan 22, 2016

View changes

brson · Jan 22, 2016

configure

+    export POSIX_SHELL
+    exec /usr/bin/bash $0 "$@"
+fi
+unset POSIX_SHELL # clear it so if we invoke other scripts, they run as ksh as well


ksh -> bash

brson · Jan 22, 2016

lgtm r? @alexcrichton

alexcrichton · Jan 26, 2016

alexcrichton reviewed Jan 26, 2016

View changes

alexcrichton · Jan 26, 2016

src/libstd/num/f64.rs

+                self // log2(Inf) = Inf
+            } else {
+                NAN // log2(-Inf) = NaN
+            }


Ah sorry I was just indicating that the macro could probably be removed in favor of generic functions and/or otherwise non-meta-programming pieces. Could the duplication between the functions here be reduced?

Oh, sorry, got it - I think it should be possible to just pass a reference to a corresponding intrinsic function. Will give it a try in a moment.

EDIT: Actually, it turns out I totally missed your comment on this regard - sorry, will fix it. Thanks! :)

It hasn't worked with a generic signature fn foo<F: Fn(f64) -> f64>(val: f64, f: F) -> f64, because the intrinsic functions are unsafe & extern - they don't implement the Fn trait. However, it worked this way: fn foo(self, log_fn: unsafe extern "rust-intrinsic" fn(f64) -> f64) -> f64 - i.e., with a completely defined type in a function reference.

Would this work as a solution, or should I find a better way?

Ah you may want to all it like:

foo(val, |f| unsafe { intrinsics::doit(f) })

(or something like that). I think there are other bugs for taking intrinsics by-value unfortunately

alexcrichton · Jan 26, 2016

alexcrichton reviewed Jan 26, 2016

View changes

alexcrichton · Jan 26, 2016

src/libstd/sys/unix/fs.rs

+
+                let ret = DirEntry {
+                    entry: *entry_ptr,
+                    name: Arc::new(::slice::from_raw_parts(name as *const u8,


You can probably elide the Arc here in favor of just Box<[u8]> (no need to Clone a DirEntry)

bors · Jan 27, 2016

☔️ The latest upstream changes (presumably #31120) made this pull request unmergeable. Please resolve the merge conflicts.

alexcrichton · Jan 27, 2016

Ok cool, I think this is getting pretty close to being good-to-go. I've got a few final questions about this:

The target being passed down to LLVM is x86_64-pc-solaris2.11, but could you elaborate on what the 2.11 is?
The rustc target is being called x86_64-sun-solaris, but is this the standard name? This does seem to follow the "arch-vendor-os" pattern, right? I'm not sure if something like x86_64-unknown-solaris is really a thing
The target_os #[cfg] is currently called "sunos", but that string doesn't appear in the LLVM or rustc target, and going strictly by the way "target triples" are laid out this should technically be solaris, so I'm curious what led you to "sunos"?

potatosalad · Jan 27, 2016

@alexcrichton I might be able to add a little explanation to your questions:

The target being passed down to LLVM is x86_64-pc-solaris2.11, but could you elaborate on what the 2.11 is?

The 2.* prefix was historically used as an internal representation of the "compatibility" with the underlying version of solaris. The 5.* prefix, on the other hand, is typically the one returned by things like uname -a. So 2.10 was the same as 5.10 which also meant "Solaris 10" and 2.11, 5.11, and "Solaris 11" have the same meaning.

So, it's essentially specifying that it can run on a "Solaris 11" compatible system. The same binary built for a current illumos system in many cases will run just fine on an Oracle Solaris 11 system without an issue.

The rustc target is being called x86_64-sun-solaris, but is this the standard name? This does seem to follow the "arch-vendor-os" pattern, right? I'm not sure if something like x86_64-unknown-solaris is really a thing

I don't know about anywhere that it's an official standard, but based on Google search results alone (which I'm sure can always be trusted as a metric 😉):

x86_64-sun-solaris (~350 results)
x86_64-unknown-solaris (~2 results)

The target_os #[cfg] is currently called "sunos", but that string doesn't appear in the LLVM or rustc target, and going strictly by the way "target triples" are laid out this should technically be solaris, so I'm curious what led you to "sunos"?

The difference in terms of "solaris" and "sunos" might be more useful in the future, but are really no different than "darwin" and "macos" or "mingw32" and "windows".

The benefit is that if there is ever a future target triple for something like x86_64-unknown-illumos mapping "illumos" to "sunos" makes more sense than mapping it to "solaris". Historically, "sunos" has been used to describe the "type" of operating system (like "bsd"), rather than the actual operating system (like "solaris" or "freebsd").

However, beyond that I don't know if there is any explicit reason to use "sunos" over "solaris" for the target_os #[cfg].

nbaksalyar · Jan 27, 2016

I've got a few final questions about this:

@potatosalad has already answered them all, but I would add my 2c:

The rustc target is being called x86_64-sun-solaris, but is this the standard name?

Other than Google results, that's the standard build target for GCC on Illumos (only with addition of version 2.11). E.g. compiler tools are called like x86_64-sun-solaris2.11-gcc. I'm not sure that the version would be needed in this case, though - I believe it's optional.

going strictly by the way "target triples" are laid out this should technically be solaris, so I'm curious what led you to "sunos"?

@potatosalad is correct, it's more like "darwin". Solaris and Illumos self-identify with uname as "SunOS", which is for compatibility reasons (as SunOS is a completely different branch of operating systems, based on BSD rather than SVR4 Unix).

Technically, I think solaris would be more appropriate here, but now Solaris is a proprietary operating system that belongs to Oracle. And this port is intended to work on its open source derivatives too (SmartOS, OmniOS, OpenIndiana, etc.), so I was a bit reluctant to choose solaris as a tag.

But any would work here, so let me know if you want me to change it to some better name.

Hopefully that explains it a bit.
Thanks!

alexcrichton · Jan 28, 2016

@potatosalad, @nbaksalyar

Thanks for the info! That's certainly quite enlightenting.

Would it be possible to not pass down 2.11 to LLVM then? I don't think we do this for other platforms, and then LLVM would pick the "default level" I guess in theory. Or is solaris different where the OS version has major changes in ABI for things like thread locals each revision?

Also after some discussion with @brson, we think that the target_os should probably follow the os portion of the target triple itself, so in this case perhaps we can stick to solaris as the triple name is x86_64-sun-solaris?

nbaksalyar · Jan 28, 2016

@alexcrichton

so in this case perhaps we can stick to solaris as the triple name is x86_64-sun-solaris?

Sure! I will make required changes and resolve the merge conflict then.

bors · Jan 31, 2016

☔️ The latest upstream changes (presumably #31298) made this pull request unmergeable. Please resolve the merge conflicts.

nbaksalyar · Jan 31, 2016

I've rebased the commits - should be ready to go!
Please let me know if something has to be improved or changed.

alexcrichton · Jan 31, 2016

alexcrichton reviewed Jan 31, 2016

View changes

alexcrichton · Jan 31, 2016

src/libstd/sys/unix/fs.rs

@@ -25,6 +24,10 @@ use sys::platform::raw;
 use sys::{cvt, cvt_r};
 use sys_common::{AsInner, FromInner};
 use vec::Vec;
+#[cfg(target_os = "solaris")]
+use core_collections::borrow::ToOwned;


I think you can remove the #[cfg] and the one below by just adding use prelude::v1::* to the top of this file (these are both in the prelude), and then you don't need the #[cfg] as well I believe.

alexcrichton · Jan 31, 2016

Looks good to me, thanks @nbaksalyar! I had just one tiny nit but it's not very relevant, so I'm gonna send this to bors:

@bors: r+ bb6e646

bors · Jan 31, 2016

⌛️ Testing commit bb6e646 with merge 78d0184...

bors · Jan 31, 2016

💔 Test failed - auto-mac-ios-opt

nbaksalyar · Feb 3, 2016

The issue should be fixed by now. Sorry it took so long - it turned out that I was building the bootstrap compiler from an incorrect base (the issue is described in #31142). So actually to run make check with the new compiler version I have to rebase my branch upon the same commit that other snapshots use.

I've yet to make the new stage0 work correctly (it fails with SIGILL for now, for some reason). I guess the reason is that the codebase with the latest commits, on which I based my work, has diverged substantially. I'll try to find & fix the reason, but actually it might be better to wait for a snapshot update before rebuilding the bootstrapping compiler and adding it to the list of snapshots.

Other than that, it should work correctly, as the only major change from my previous snapshot is renaming "sunos" to "solaris" (and that's why it wouldn't work).

alexcrichton · Feb 3, 2016

@bors: r+ fae883c

Ok, sounds good to me!

bors · Feb 3, 2016

⌛️ Testing commit fae883c with merge e3bcddb...

bors · Feb 4, 2016

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt

nbaksalyar · Feb 4, 2016

Awesome! @alexcrichton, @potatosalad, and everyone - thanks for your help! :)
Next step - a working compiler snapshot and Cargo.

dhuseby · Feb 9, 2016

@nbaksalyar have you successfully bootstrapped rustc on illumos yet?

nbaksalyar · Feb 10, 2016

@dhuseby
Not for the recent versions of Rust. There's a working compiler (the link can be found in the first comment to this PR), but it expects target_os to be sunos, which is changed to solaris now. Besides, it was built from an incorrect source base - as it turns out, it has to be the same commit as the other snapshots use. Current WIP branch can be found here: https://github.com/nbaksalyar/rust/tree/illumos-stage0
It segfaults for now, but I think I'll have a working compiler this week.

dhuseby · Mar 21, 2016

@nbaksalyar any update on the WIP branch?

nbaksalyar · Mar 21, 2016

@dhuseby
Yes! @jperkin has built a Rust package for SmartOS, it's available in pkgsrc.
I plan to add it to the official list of snaphots soon & I'm working on a Cargo port for Illumos/Solaris.

alexcrichton · Mar 21, 2016

@nbaksalyar oh I should also mention that we've recently got cross-compiled nightlies from Linux to FreeBSD/NetBSD up and running, so we have nightly builds of rustc and the standard library for FreeBSD and NetBSD. If there's a cross compiler from Linux to Illumos then I'd be game to set one up as well for Illumos!

cneira · Jan 12, 2018

@alexcrichton
Maybe this could help https://gist.github.com/AlainODea/6679613

jperkin · Jan 12, 2018

FWIW we've been shipping rust/cargo packages in SmartOS for a while now, currently 1.22.1 but 1.23 should be ready soon. Our binaries should work on any illumos platform built after 20141030.

despair86 · Jan 21, 2019

...as I'm not sure if 32-bit installations are widespread.

not since 2.11, but a big chunk of userspace is still 32-bit (GNU CC always builds a 32-bit multilib-enabled compiler, for instance)

@nbaksalyar: do you still have the target spec JSON files originally used to bootstrap this port? Looking into an i386-sun-solaris2.11 build ~~(and finally rein in memory usage of the net's oldest browser at last: locking 6GB+1 segment at startup is in poor taste on an 8GB laptop)~~

rust-highfive assigned brson Jan 21, 2016

rust-highfive assigned alexcrichton and unassigned brson Jan 22, 2016

nbaksalyar force-pushed the nbaksalyar:illumos branch from f76db06 to a69f3ee Jan 28, 2016

nbaksalyar referenced this pull request Jan 29, 2016
Merged
Renames "sunos" to "solaris" (as a part of PR to add Illumos support to Rust) #161

nbaksalyar force-pushed the nbaksalyar:illumos branch from 55706f2 to bb6e646 Jan 31, 2016

Fix broken auto-mac-ios-opt build

Unverified

The key that signed this is expired.

GPG key ID: 3EEA378A0EA758DA Learn about signing commits

Loading status checks…

fae883c

bors merged commit fae883c into rust-lang:master Feb 4, 2016
2 checks passed

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

homu Test successful
Details

This was referenced Feb 4, 2016

Closed

std: Move pc-windows-gnu to SEH-based unwinding #31313

Merged

rustc: add a `--print targets` command #31358

Closed

Support configure for illumos or solaris (including SmartOS) #28589

nbaksalyar deleted the nbaksalyar:illumos branch Feb 21, 2016

faho referenced this pull request Jan 2, 2019
Closed
Error: Wrong color in test at index 3 in text (expected 0x104, actual 0x1): cd test/fish_highlight_test #5458

rust-lang/rust

Join GitHub today

Add Illumos support #31078

Conversation

nbaksalyar commented Jan 21, 2016

rust-highfive assigned brson Jan 21, 2016

This comment has been minimized.

rust-highfive commented Jan 21, 2016

alexcrichton reviewed Jan 21, 2016 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

alexcrichton reviewed Jan 21, 2016 View changes

This comment has been minimized.

alexcrichton reviewed Jan 21, 2016 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

alexcrichton reviewed Jan 21, 2016 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

alexcrichton reviewed Jan 21, 2016 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

alexcrichton reviewed Jan 21, 2016 View changes

This comment has been minimized.

alexcrichton reviewed Jan 21, 2016 View changes

This comment has been minimized.

This comment has been minimized.

alexcrichton commented Jan 21, 2016

This comment has been minimized.

nbaksalyar commented Jan 21, 2016

brson reviewed Jan 22, 2016 View changes

This comment has been minimized.

brson reviewed Jan 22, 2016 View changes

This comment has been minimized.

This comment has been minimized.

brson commented Jan 22, 2016

rust-highfive assigned alexcrichton and unassigned brson Jan 22, 2016

alexcrichton reviewed Jan 26, 2016 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

alexcrichton reviewed Jan 26, 2016 View changes

This comment has been minimized.

This comment has been minimized.

bors commented Jan 27, 2016

This comment has been minimized.

alexcrichton commented Jan 27, 2016

This comment has been minimized.

potatosalad commented Jan 27, 2016

This comment has been minimized.

nbaksalyar commented Jan 27, 2016

This comment has been minimized.

alexcrichton commented Jan 28, 2016

This comment has been minimized.

nbaksalyar commented Jan 28, 2016

nbaksalyar force-pushed the nbaksalyar:illumos branch from f76db06 to a69f3ee Jan 28, 2016

nbaksalyar referenced this pull request Jan 29, 2016

This comment has been minimized.

bors commented Jan 31, 2016

nbaksalyar added some commits Jan 21, 2016

nbaksalyar added some commits Jan 28, 2016

nbaksalyar force-pushed the nbaksalyar:illumos branch from 55706f2 to bb6e646 Jan 31, 2016

This comment has been minimized.

nbaksalyar commented Jan 31, 2016

alexcrichton reviewed Jan 31, 2016 View changes

This comment has been minimized.

This comment has been minimized.

alexcrichton reviewed Jan 21, 2016

View changes

alexcrichton reviewed Jan 21, 2016

View changes

alexcrichton reviewed Jan 21, 2016

View changes

alexcrichton reviewed Jan 21, 2016

View changes

alexcrichton reviewed Jan 21, 2016

View changes

alexcrichton reviewed Jan 21, 2016

View changes

alexcrichton reviewed Jan 21, 2016

View changes

brson reviewed Jan 22, 2016

View changes

brson reviewed Jan 22, 2016

View changes

alexcrichton reviewed Jan 26, 2016

View changes

alexcrichton reviewed Jan 26, 2016

View changes

nbaksalyar force-pushed the nbaksalyar:illumos branch from `f76db06` to `a69f3ee` Jan 28, 2016

nbaksalyar force-pushed the nbaksalyar:illumos branch from `55706f2` to `bb6e646` Jan 31, 2016

alexcrichton reviewed Jan 31, 2016

View changes

bors merged commit `fae883c` into rust-lang:master Feb 4, 2016
2 checks passed