
Announcing Rust 1.10 - steveklabnik
http://blog.rust-lang.org/2016/07/07/Rust-1.10.html
======
parley
I'm really looking forward to when rustup.rs is stable (atleast for Linux)!
I'm trying to push Rust at work, and it's one of those polishy things that
would help.

Unfortunately, last time I checked development (on issues blocking the initial
stable release) seemed to have slowed as of late, but I should be helping out
instead of whining - the Rust community is doing great work!

~~~
ssebastianj
I've just upgraded from Rust 1.8 -> 1.9 -> 1.10 using rustup.rs without any
issue (at least I didn't _see_ any issue :P). I'm on Ubuntu 16.04 amd64.

~~~
caconym_
I've been using it on my Mac since the post about it on here a few months ago
and I've had no issues at all, though I haven't tried to do anything
strange/difficult with it.

~~~
ssebastianj
A quick update: on a Windows 10 box the whole upgrade (1.9 -> 1.10) ran
smoothly. This kind of tools really get me excited about Rust future.

------
dikaiosune
Exciting!

Tongue-in-cheek, it's very exciting that distros will now have an easier time
patching Rust and producing bugs like this one:

[https://bugs.launchpad.net/ubuntu/+source/gcc-4.2/+bug/25679...](https://bugs.launchpad.net/ubuntu/+source/gcc-4.2/+bug/256797)

~~~
reubenmorais
I've tried for a few minutes, but I can't understand Launchpad. How do I find
the code changes associated with that bug? I want to see the fix…

~~~
pietroalbini
Yeah, Launchpad has not the greatest UX.

In the last comment [1] on the bug, it's mentioned the release in which the
fix was released. From its page [2] you can see all the details of it,
including its diffs.

[1]
[https://bugs.launchpad.net/ubuntu/+source/gcc-4.2/+bug/25679...](https://bugs.launchpad.net/ubuntu/+source/gcc-4.2/+bug/256797/comments/9)

[2]
[https://launchpad.net/ubuntu/+source/gcc-4.2/4.2.4-1ubuntu3](https://launchpad.net/ubuntu/+source/gcc-4.2/4.2.4-1ubuntu3)

~~~
reubenmorais
I looked at that, and eventually found a reference to the Launchpad bug in
this 500KB patch[0]. It says:

    
    
        +  * Fixes included in the 4.2.4 upstream release (compared to 4.2.3-3ubuntu7):
        +    - Fix LP: #256797, wrong-code on ia32, taken from the gcc-4_2-branch.
    

Which makes it sound like the problem was in GCC, not the Ubuntu package. I
was under the impression that the bug was caused by an Ubuntu-specific patch,
from dikaiosune's comment. Am I missing something?

Edit: Ah, so the fix was added in 4.2.4-1ubuntu1, not 4.2.4-1ubuntu3. Which
narrows the actual source changes to something inside this other 500KB
patch[1]. From here I looked at the upstream changes using GitHub compare[2]
(warning, big page). I ran a one liner in the JS console to expand all the "…"
buttons next to the commit messages so I could search for relevant text, which
lead me to this commit[3], which seems to be the actual code changes to fix
that particular bug. That finally lead me to the bug in GCC's bug tracker[4].

I don't know if I have just been very lucky with the open source projects I've
collaborated with, but this journey to find where a bug was actually fixed
seems completely insane to me. Is all this info passed down from maintainer to
maintainer just via folklore? Crazy.

Oh, I almost forgot about what I actually wanted to know. This looks like a
GCC bug that wasn't caused by Ubuntu specific patches, so I don't know what
dikaiosune wanted to say.

[0]
[https://launchpadlibrarian.net/18364478/gcc-4.2_4.2.4-1ubunt...](https://launchpadlibrarian.net/18364478/gcc-4.2_4.2.4-1ubuntu3.diff.gz)

[1]
[https://launchpadlibrarian.net/17472542/gcc-4.2_4.2.3-2ubunt...](https://launchpadlibrarian.net/17472542/gcc-4.2_4.2.3-2ubuntu7_4.2.4-1ubuntu1.diff.gz)

[2] [https://github.com/gcc-
mirror/gcc/compare/gcc-4_2_3-release....](https://github.com/gcc-
mirror/gcc/compare/gcc-4_2_3-release...gcc-4_2_4-release)

[3] [https://github.com/gcc-
mirror/gcc/commit/80cacf54c3d410d5552...](https://github.com/gcc-
mirror/gcc/commit/80cacf54c3d410d5552b2bf262bc9ac5dc6a1e05)

[4]
[https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35163](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35163)

------
rustc
How's the MIR stuff going on? Is there an ETA on when MIR will land in
beta/stable? Will the incremental compilation work start after that?

~~~
steveklabnik
MIR is still going well. To be clear, it's already landed, and has been
working, it's just not the default yet. There's a PR [https://github.com/rust-
lang/rust/pull/34096](https://github.com/rust-lang/rust/pull/34096) and there
are currently three blockers: [https://github.com/rust-
lang/rust/milestone/29](https://github.com/rust-lang/rust/milestone/29)

Incremental compilation has been worked on while MIR development was
happening, so it won't start, it's already in-progress. :)

~~~
moosingin3space
Does this imply we should see single-crate compile times improve?

~~~
steveklabnik
Which part?

With MIR, yes, the idea is that compile time should improve. One of those
tracking bugs is to make sure that it doesn't regress before turning it on by
default.

With incremental compilation, you should see compiles after the first improve;
you'll need to compile a lot less code for each change. Right now, the entire
crate is recompiled, but afterwards, just the portion that changed will need
to be.

~~~
moosingin3space
My understanding of compilers is somewhat limited, but I'm curious how the
compiler can detect "just the portion that changed", given that Rust does
heavy inlining.

~~~
kibwen
Indeed, inlining is an obstacle for such fine-grained incremental
recompilation as Rust envisions. However, when compiling in debug mode (which
is the default) Rust (or rather LLVM) does not do all that much inlining, and
considering that people compile in debug mode much more often than they
compile in release mode this should present a large time savings to the
average developer use case.

(Note also that MIR should generate somewhat faster debug binaries than
current trans (by virtue of doing "obvious" optimizations in the frontend,
rather than asking LLVM to chew on it), so if there are people out there who
currently make release builds during development because their debug builds
are too doggone slow, then this should help alleviate that.)

------
moosingin3space
Congratulations on the release! `cdylib` targets should prove very helpful for
embedding, and compilation from a recent stable version will make it much
easier to package.

~~~
snuxoll
The bootstrap problem is exactly why rust isn't in the Fedora repos right now,
so I am very excited about this. Also, dylib will likely end up being
preferred for distribution packaging (especially Fedora which HEAVILY
discourages static linking, though there's no longer a strict no-static
linking policy).

~~~
moosingin3space
Do you think it would be reasonable to package rustup in the Fedora repos? I
ask because for a development machine, it makes more sense to be able to
install multiple toolchains in parallel.

~~~
snuxoll
In the repos directly? No, probably not. rbenv and pyenv aren't in the repos
either, I'm not aware of any specific policy against it but it introduces some
hesitance to provide software in the repos that can be used to then install
software that may conflict with software managed by the package manager
itself. rubygems, setuptools/pip and cargo as examples only typically handle
installation of libraries and are generally "well behaved" citizens that put
files in specific locations and don't install or manage new versions of the
underlying language runtime, meanwhile rbenv/pyenv/rustup can mess with your
path and potentially cause conflicts that could end up with people filing bugs
that are closed "not our problem, we support this one specific environment
that's in the repos".

Someone is welcome to try, feel free to open a thread on the fedora-devel
mailing list and see what anyone else thinks. But even if rustup doesn't make
it into the official repos I don't see why someone couldn't put it up on COPR.

~~~
tmzt
Could rustup use PackageKit/yum/dnf to do this on Fedora? It would be really
nice to be able to point to one command in the documentation that would work
whether installed directly by the developer or provided by a distro.

Debian specifically provides it's own alternatives system to handle symlinks
in a global manner, but nothing for directory-specific ones. I'm not sure
about Fedora. With `rustup` replacing `multirust`, it would be useful to point
to a common command that in turn would call the distro-provided facility for
global links.

Also, congratulations on 1.10! Looking forward to servo.apk in the coming
weeks as well.

------
outworlder
> Rust is implemented in Rust, which means that to build a copy of Rust, you
> need a copy of Rust. This is commonly referred to as ‘bootstrapping’.
> Historically, we would do this by “snapshotting” a specific version of the
> compiler, and always bootstrapping from that

So, does that mean that Rust (has/will have) issues regarding binary blobs in
pure free software Linux distributions?

~~~
Narishma
Why would it? This is the same situation as a C compiler requiring another C
compiler to build it.

~~~
ben0x539
Obviously C compilers should be written in Javascript, since everybody already
has a Javascript engine installed.

------
yarper
What amazes me, is all this cool stuff but a Rust process still can't return
an exit code [0] without using a workaround.

I actually use Rust in production, and have generally found it very good -
compared to the well discussed difficulties with CPP. I will continue to do
so, but I think that the edges really need covering off properly before it'll
be treated as a serious competitor to CPP (and equally often, Go).

[0]: [https://github.com/rust-lang/rfcs/issues/1176](https://github.com/rust-
lang/rfcs/issues/1176)

~~~
tveita
Calling std::process::exit doesn't seem like much of a "workaround"? That's
basically the same as Java, which is doing OK as a language.

[https://doc.rust-lang.org/std/process/fn.exit.html](https://doc.rust-
lang.org/std/process/fn.exit.html)

~~~
yarper
This is true! Perhaps my comment was a bit in haste, however there's a lot of
caveats with "exits" rather than returns which complicate the matter, for
example in Java System.exit can fail (and finizalizers may or may not be run).

On top of that you have to type System.exit all the time, which is quite
annoying

------
progman
Congratulations! Are there any plans to support bootstrap from source?
Currently any install requires a binary Rust compiler.

I like the way how Nim handles the bootstrap. It's always easy, and it also
eases ports to other platforms significantly since everthing is coded in C.

~~~
steveklabnik

      > Are there any plans to support bootstrap from source?
    

The source code is fully available, so we are/have "bootstrapped from source",
it's just much more convenient to not do it yourself.

We don't have any more significant plans to change things in the near future.

~~~
wldcordeiro
Wasn't the old bootstrap basically just pointing to specific commits to rust
rather than tagged prior releases? I remember the servo repo doing something
like that and maybe the Rust one as well (cloned it but have yet to build rust
on my system from source!)

~~~
steveklabnik
Yes, they were specific SHAs, rather than releases.

~~~
wldcordeiro
Thought so! Know if servo is joining you guys on the build from a release
train?

~~~
steveklabnik
Well, Servo is a bit different, given that it's not a rust compiler, so
there's no 'bootstrapping' component.

Until Servo stops using nightly features (which may not be ever, given that
they are part of how we test new features!), they'll need to stick with a
nightly build. We made an exception for the compiler when compiling itself,
but won't make any more.

------
dfdfghhhfgh
The marketing of Rust programming language has been excellent. Hats off for
having pulled off something like this.

------
pjmlp
Congratulations on the work.

Very nice to see the push for relying only on stable releases while building
Rust.

