Nix doesn't compile anymore on rust nightly-2016-03-30 due to an LLVM error

[JohanLorenzo]

Thanks for this library!

When you compile nix on nightly-2016-03-30, you get the failure on the way to be fixed by #337.
Once this small nit is fixed, you get a more serious error:

rustc: /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/llvm/include/llvm/Support/Casting.h:237: typename llvm::cast_retty<X, Y*>::ret_type llvm::cast(Y*) [with X = llvm::Function; Y = llvm::Value; typename llvm::cast_retty<X, Y*>::ret_type = llvm::Function*]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.
error: Could not compile `nix`.

I got this failure locally, and I also noticed it appears in #337, see this line.

I believe this is a bug in the rust compiler. But I'd prefer starting to document the failure here, it case it remains in the compiler.

[JohanLorenzo]

After bisecting rustc locally, you can build the current master (4ca407d) with 2016-03-18 but not with 2016-03-20.

That matches the results stored on Travis:

• Last passing on master
• First failing

[fiveop]

Did you report a bug against rust as well? I am pretty sure that triggering an assertion in llvm is a bug in the compiler itself.

[kamalmarhubi]

@JohanLorenzo thanks for the issue and the investigation!

[JohanLorenzo]

Did you report a bug against rust as well? I am pretty sure that triggering an assertion in llvm is a bug in the compiler itself.

I haven't yet. I'm trying to narrow down the code so the bug will be actionable by the rustc devs. @pnkfelix helped to get suitable debug traces.

@JohanLorenzo thanks for the issue and the investigation!

np! 😃

[pnkfelix]

Here is some information that may or may not be useful for fixing this issue, but I thought was worth noting since it may be a sign of problems elsewhere.

While investigating this I determined that the gettid code in unistd.rs seems to be related in some weird ways.

gettid is a very short function:

pub fn gettid() -> pid_t {
    unsafe { libc::syscall(libc::SYS_gettid) as pid_t }
}

This function is weird in the context of the nix crate, because as far as I can tell, it is the only function that is calling libc::syscall, i.e. the syscall extern function that is provided by the libc crate.

The (relatively few) other functions in the nix crate that invoke syscalls all do it by invoking the sys::syscall, where sys is a module that is defined by nix itself.

Also worth noting: the type signatures for libc::syscall and sys::syscall have different return types; one is returning c_long and the other c_int.

Finally, if I replace the current body of gettid with one that calls sys::syscall, then it seems to compile successfully.

---

(Despite the above observations, I have not managed to figure out enough of the problem to make a small isolated test case...)

[kamalmarhubi]

@pnkfelix thanks for the observations! Not relevant to the compiler error, but the sys::syscall function should go away at some point (#264).

Looking at syscall(2) on Linux, it should return a long. On FreeBSD, it returns an int. This needs fixing. Filed #341 to track.

[pnkfelix]

I'm stashing the state of my attempt to narrow the problem down in the following gist:

https://gist.github.com/pnkfelix/727d5533e16f40b5f55068fec4a8e17b

(I've gotten the test case down to a single 4.7K line file. It is a semi-mechanical process to continue removing unused code, i.e. replacing function bodies with loop { } and checking whether the compiler still assert-fails, and eventually removing entirely unused modules ...)

[pnkfelix]

eddyb says that rust-lang/rust#32742 will fix this once it lands (see discussion in rust-lang/rust#32740)

[kamalmarhubi]

yay!

[JohanLorenzo]

The latest nightly contains rust-lang/rust#32742. I confirm you can compile nix again with it!

Closing the issue.