rustc: 1.0.0 -> 1.1.0

[telotortium]

No description provided.

[telotortium]

@madjar @cstrahan @wizeman @globin

[madjar]

Looks good to me.

@telotortium Did you build it locally ? If not, I guess we could just send it to hydra.

[flosse]

Great! Could you update cargo too? Thanks a lot.

[wizeman]

Looks good to me too.

[wizeman]

@flosse I'm in the process of updating nightly rust, cargo and racerRust.

[telotortium]

@flosse I've updated cargo locally too, as well as rustPlatform in order to build cargo. I have a couple more questions:

1. They've started to release cargo with SemVer-based version numbers (specifically, I've built 0.3.0, which builds with stable Rust 1.1.0). Should we switch over the non-snapshot build to use these numbers rather than dates?
2. I've switched rustCargoPlatform to use the stable rustc rather than the nightly rustcMaster. OK?
3. No new Cargo snapshot has been made in the rust-lang/cargo repo, so cargoSnapshot has not been updated and is even more out of date than before. Is there a way to hide the cargoSnapshot package from nix-env -qa, since it's only used to build cargo?

[wizeman]

@telotortium

1. I think that should be fine, but IMO you should also change fetchgit's rev attribute (i.e., the src.rev attribute) in cargo's default.nix file to be "refs/tags/0.3.0".
2. Perfect
3. I don't know whether there is a better way to do this (it seems kind of hack), but if you change cargoSnapshot = callPackage... to something like cargoSnapshot = { cargo = callPackage... };, then nix-env won't see it (unless you'd also add a recurseIntoAttrs). In this case you'd then have to change cargoSnapshot references to cargoSnapshot.cargo. But I suspect that there's a better way to do this...

[telotortium]

Actually, I needed to update the Cargo snapshot to some later nightly (I used 2015-06-17) to avoid rust-lang/cargo#976.

[telotortium]

@madjar I've installed rustc and cargo locally, but I'm going to use nix-build to test out the builds locally as well (since I just found out about that command).

[jagajaga]

What about racer pkg, wasn't it broken by update?

[telotortium]

@jagajaga The current version of racer builds fine for me after the updates to rustc and cargo.

[telotortium]

@wizeman Implemented your suggestions.

[Havvy]

Instead of removing 1.0.0.nix and adding 1.1.0.nix, can you just name the file to stable.nix or possibly default.nix?

Furthermore, I didn't see that this was here, so I made a PR (#8701) myself that included various comments for how to update the rustc snapshot information. Can you perhaps merge those comments into your PR?

[telotortium]

Patched the contents of #8701 into this PR (including adding @Havvy as a maintainer, let me know if you want me to remove that).

[Havvy]

You can keep me as a maintainer. Now that I know how, it's not a major burden to do it.

[wizeman]

When testing these commits locally I got a hash mismatch in cargo:

Failed: output path ‘/nix/store/l5rfbx2b1plrjljilpv8zfg8ix6wssfw-cargo’ should have r:sha256 hash ‘1y90d5zdlivsx67ac5k4zr5d4m6mirbhj76xp0fwd7k61rx0svws’, instead has ‘1ckb2xd7nm8357imw6b1ci2ar8grnihzan94kvmjrijq6sz8yv9i’

Did you update the hash when you switched to using refs/tags/0.3.0 instead of the commit hash?

[telotortium]

I remember a vague mention somewhere that leaveDotGit may cause problems.

[wizeman]

Perhaps you're referring to #8567.

It could be because of that, but this type of problem is more likely to be because you didn't update the hash when you switched to using refs/tags/0.3.0 instead of the commit hash. Did you forget to do this, by any chance?

Note that you won't necessarily experience this error even if you forgot to update the hash, because Nix will reuse the output of the previous hash if you had already downloaded it. This means it would work on your machine (because Nix had already fetched the contents that had the previous hash), but it wouldn't work on others...

[telotortium]

That could be it. How do you force Nix to do a rebuild?

[wizeman]

Usually nix will not rebuild the same package unless the inputs have changed. Right now, on your machine, even though you changed the git revision, nix still thinks the inputs haven't changed because the input hash hasn't changed.

So what I do in this case is to change the last character of the hash (to a zero, for example), which makes Nix think that the input has changed. If you then tell Nix to build the package, Nix will rebuild it (because the hash changed), then it will complain about a wrong hash and tell you the correct one at the same time (like in the error message I showed above).

There is a more standard solution to rebuild a package, which involves running nix-store --delete /nix/store/<derivation-path> and then nix-build it. However, this is much harder to get right unless you're sure you know what you're doing, because nix will refuse to delete something when there are references to it somewhere in the nix store or in some profile, and also, you'd have to be sure you're deleting the right derivation. For example, in this case, the right derivation to delete wouldn't be the cargo package, it would be the src attribute of the cargo derivation (i.e. the result of fetchgit)...

So I think the first suggestion I mentioned, although hackier, is easier to get right.

[telotortium]

I pushed the change to the Cargo hash

[wizeman]

Merged. Thanks!