New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add changelog for 1.13.0 #37600

Merged
merged 1 commit into from Nov 12, 2016

Conversation

@brson
Contributor

brson commented Nov 5, 2016

The diagnostics PRs are excellent and some have excellent examples thanks @jonathandturner @estebank.

Here are some notes about the performance changes during the release.
Compile times are improved %40 in some cases
.

This desires to be backported to beta for 1.13.

Sadly, the 1.12.1 changelog PR has not merged to master yet, and is sitting in a rollup PR.

r? @rust-lang/lang @rust-lang/compiler @rust-lang/libs @rust-lang/core

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Nov 5, 2016

Contributor
Contributor

brson commented Nov 5, 2016

@brson brson added the beta-nominated label Nov 5, 2016

@Mark-Simulacrum

This comment has been minimized.

Show comment
Hide comment
@Mark-Simulacrum

Mark-Simulacrum Nov 5, 2016

Member

For the reasoning behind improvement to compile times, the compile-time optimizations are the most likely causes.

I don't believe any other PRs intentionally optimized the compiler (at least majorly). If you or @steveklabnik want to note it, I know that there are at least a few more places that I know of where we may be able to make some potentially large gains in terms of memory usage at least, and possibly performance too. Edit: By "note it" I mean in the blog post that someone (@steveklabnik?) writes up.

Member

Mark-Simulacrum commented Nov 5, 2016

For the reasoning behind improvement to compile times, the compile-time optimizations are the most likely causes.

I don't believe any other PRs intentionally optimized the compiler (at least majorly). If you or @steveklabnik want to note it, I know that there are at least a few more places that I know of where we may be able to make some potentially large gains in terms of memory usage at least, and possibly performance too. Edit: By "note it" I mean in the blog post that someone (@steveklabnik?) writes up.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Nov 5, 2016

Contributor

This release includes builds for several new platforms, the standard library, compiler, and cargo:

  • powerpc-unknown-linux-gnu
  • powerpc64-unknown-linux-gnu
  • powerpc64le-unknown-linux-gnu
  • mips-unknown-linux-gnu
  • mipsel-unknown-linux-gnu
  • mips64-unknown-linux-gnuabi64
  • mips64el-unknown-linux-gnuabi64
  • s390x-unknown-linux-gnu

The builds have a deficiency though. I don't see "rust" packages for them on beta, so they can't be installed easily, either by "rust" tarball or by rustup toolchain install s930x-unknown-linux-gnu. I think the only way to install them from binary is by downloading therustcbinary and thecargo` nightly.

It may not be worth mentioning them yet if they are hard to install.

Contributor

brson commented Nov 5, 2016

This release includes builds for several new platforms, the standard library, compiler, and cargo:

  • powerpc-unknown-linux-gnu
  • powerpc64-unknown-linux-gnu
  • powerpc64le-unknown-linux-gnu
  • mips-unknown-linux-gnu
  • mipsel-unknown-linux-gnu
  • mips64-unknown-linux-gnuabi64
  • mips64el-unknown-linux-gnuabi64
  • s390x-unknown-linux-gnu

The builds have a deficiency though. I don't see "rust" packages for them on beta, so they can't be installed easily, either by "rust" tarball or by rustup toolchain install s930x-unknown-linux-gnu. I think the only way to install them from binary is by downloading therustcbinary and thecargo` nightly.

It may not be worth mentioning them yet if they are hard to install.

Show outdated Hide outdated RELEASES.md
@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Nov 5, 2016

Member

By "note it" I mean in the blog post that someone (@steveklabnik?) writes up.

Yes, usually @brson writes the release notes and then I write the draft of the blog post.

Member

steveklabnik commented Nov 5, 2016

By "note it" I mean in the blog post that someone (@steveklabnik?) writes up.

Yes, usually @brson writes the release notes and then I write the draft of the blog post.

Show outdated Hide outdated RELEASES.md
@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Nov 5, 2016

Contributor

Can we repro the perf improvements by hand rather than using the perf.rust-lang.org? We had some problems last time trying to repro them.

Contributor

jonathandturner commented Nov 5, 2016

Can we repro the perf improvements by hand rather than using the perf.rust-lang.org? We had some problems last time trying to repro them.

@Mark-Simulacrum

This comment has been minimized.

Show comment
Hide comment
@Mark-Simulacrum

Mark-Simulacrum Nov 5, 2016

Member

@jonathandturner At least for the #[inline] function fix, @retep998 commented here. That comment reports relatively huge decreases in compile time (LLVM passes down by an order of magnitude, trans down by 31% (628ms - 433ms).

Member

Mark-Simulacrum commented Nov 5, 2016

@jonathandturner At least for the #[inline] function fix, @retep998 commented here. That comment reports relatively huge decreases in compile time (LLVM passes down by an order of magnitude, trans down by 31% (628ms - 433ms).

@thepowersgang

This comment has been minimized.

Show comment
Hide comment
@thepowersgang

thepowersgang Nov 6, 2016

Contributor

The ? operator appears to be stable in current beta - This should be in these release notes, right?

Contributor

thepowersgang commented Nov 6, 2016

The ? operator appears to be stable in current beta - This should be in these release notes, right?

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Nov 6, 2016

Contributor

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

Contributor

bors commented Nov 6, 2016

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

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Nov 6, 2016

Member

One of the major improvements to compile time was the futures-rs-test-all test case which is basically exactly what #35761 targeted. Compiling the current test locally goes from 5.2s on stable to 4.7 on beta, but note that the test in the futures-rs repo is likely no longer exactly what's on the benchmark suite (I think I broke it up as it took too long to compile). Compiling the entire test suite of futures-rs takes 9.3s on stable and 9.2s on beta.

We... may not want to claim 40% perf improvements?

Member

alexcrichton commented Nov 6, 2016

One of the major improvements to compile time was the futures-rs-test-all test case which is basically exactly what #35761 targeted. Compiling the current test locally goes from 5.2s on stable to 4.7 on beta, but note that the test in the futures-rs repo is likely no longer exactly what's on the benchmark suite (I think I broke it up as it took too long to compile). Compiling the entire test suite of futures-rs takes 9.3s on stable and 9.2s on beta.

We... may not want to claim 40% perf improvements?

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Nov 6, 2016

Member

Hm so testing again, I wonder, is perf.rust-lang.org doing --release? The numbers I just gave for futures were in debug mode, but compiling the entire test suite in release mode takes 22.7s on stable and 16.9s on beta, a 25% improvement. Maybe that's what's being measured?

Member

alexcrichton commented Nov 6, 2016

Hm so testing again, I wonder, is perf.rust-lang.org doing --release? The numbers I just gave for futures were in debug mode, but compiling the entire test suite in release mode takes 22.7s on stable and 16.9s on beta, a 25% improvement. Maybe that's what's being measured?

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Nov 6, 2016

Contributor

25% in release mode sounds good. Can we check a few more packages just to be sure?  (I'd do it but I'm traveling today)

Jonathan

On Sun, Nov 6, 2016 at 12:30 PM -0500, "Alex Crichton" notifications@github.com wrote:

Hm so testing again, I wonder, is perf.rust-lang.org doing --release? The numbers I just gave for futures were in debug mode, but compiling the entire test suite in release mode takes 22.7s on stable and 16.9s on beta, a 25% improvement. Maybe that's what's being measured?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Contributor

jonathandturner commented Nov 6, 2016

25% in release mode sounds good. Can we check a few more packages just to be sure?  (I'd do it but I'm traveling today)

Jonathan

On Sun, Nov 6, 2016 at 12:30 PM -0500, "Alex Crichton" notifications@github.com wrote:

Hm so testing again, I wonder, is perf.rust-lang.org doing --release? The numbers I just gave for futures were in debug mode, but compiling the entire test suite in release mode takes 22.7s on stable and 16.9s on beta, a 25% improvement. Maybe that's what's being measured?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@Mark-Simulacrum

This comment has been minimized.

Show comment
Hide comment
@Mark-Simulacrum

Mark-Simulacrum Nov 6, 2016

Member

Hm so testing again, I wonder, is perf.rust-lang.org doing --release?

From what I can tell, it's not.

Member

Mark-Simulacrum commented Nov 6, 2016

Hm so testing again, I wonder, is perf.rust-lang.org doing --release?

From what I can tell, it's not.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Nov 6, 2016

Member

Whoa ok scratch that I was accidentally using nightly when I thought I was using stable ok, current numbers I'm getting are:

  • debug futures-rs-test-all (in the futures repo) - 8.37s on stable, 4.8 on beta, 5.3 on nightly
  • debug futures-rs all tests - 15.6s on stable, 9.4 on beta, 9.7 on nightly
  • release futures-rs all tests - 20.7s on stable, 16.9 on beta, 20.57 on nightly
  • debug winapi - 29.8s on stable, 25.1s on beta, 25.7 on nightly
  • release winapi - 35.6s on stable, 29.9s on beta, 32.1s on nightly

So it actually looks kind bad in some cases. While we universally improved stable -> beta we ended up regressing almost universally beta -> nightly.

Member

alexcrichton commented Nov 6, 2016

Whoa ok scratch that I was accidentally using nightly when I thought I was using stable ok, current numbers I'm getting are:

  • debug futures-rs-test-all (in the futures repo) - 8.37s on stable, 4.8 on beta, 5.3 on nightly
  • debug futures-rs all tests - 15.6s on stable, 9.4 on beta, 9.7 on nightly
  • release futures-rs all tests - 20.7s on stable, 16.9 on beta, 20.57 on nightly
  • debug winapi - 29.8s on stable, 25.1s on beta, 25.7 on nightly
  • release winapi - 35.6s on stable, 29.9s on beta, 32.1s on nightly

So it actually looks kind bad in some cases. While we universally improved stable -> beta we ended up regressing almost universally beta -> nightly.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Nov 6, 2016

Member

Compilers I used were:

rustc 1.12.1 (d4f39402a 2016-10-19)
rustc 1.13.0-beta.2 (85ca935b3 2016-10-19)
rustc 1.14.0-nightly (5665bdf3e 2016-11-02)
Member

alexcrichton commented Nov 6, 2016

Compilers I used were:

rustc 1.12.1 (d4f39402a 2016-10-19)
rustc 1.13.0-beta.2 (85ca935b3 2016-10-19)
rustc 1.14.0-nightly (5665bdf3e 2016-11-02)
@retep998

This comment has been minimized.

Show comment
Hide comment
@retep998

retep998 Nov 6, 2016

Member

For winapi 0.3 where every single function is inline.

rustc 1.12.0 (3191fbae9 2016-09-23) Finished release [optimized] target(s) in 11.66 secs

rustc 1.14.0-nightly (19ac57926 2016-10-08) Finished release [optimized] target(s) in 7.37 secs

This is a 37% reduction in time, which is pretty close to 40%.

Member

retep998 commented Nov 6, 2016

For winapi 0.3 where every single function is inline.

rustc 1.12.0 (3191fbae9 2016-09-23) Finished release [optimized] target(s) in 11.66 secs

rustc 1.14.0-nightly (19ac57926 2016-10-08) Finished release [optimized] target(s) in 7.37 secs

This is a 37% reduction in time, which is pretty close to 40%.

@bluss

This comment has been minimized.

Show comment
Hide comment
@bluss

bluss Nov 6, 2016

Contributor

My impression was that the inline PR had a huge impact on build times of various libraries.

Trying a relatively small library I get this now:

ndarray 0.6.8 clean build (including dependencies)  rev 6fd2f989a

rustc 1.12.1 (d4f39402a 2016-10-19)

cargo build -j1

    Finished debug [unoptimized + debuginfo] target(s) in 13.10 secs
    Finished debug [unoptimized + debuginfo] target(s) in 12.98 secs

rustc 1.13.0-beta.3 (106d18793 2016-11-04)

cargo build -j1

    Finished debug [unoptimized + debuginfo] target(s) in 6.45 secs
    Finished debug [unoptimized + debuginfo] target(s) in 6.50 secs

That's basically reducing the build time by 50%.

For the curious, the timing on current nightly is

rustc 1.14.0-nightly (cae6ab1c4 2016-11-05)
cargo build -j1
    Finished debug [unoptimized + debuginfo] target(s) in 5.89 secs
Contributor

bluss commented Nov 6, 2016

My impression was that the inline PR had a huge impact on build times of various libraries.

Trying a relatively small library I get this now:

ndarray 0.6.8 clean build (including dependencies)  rev 6fd2f989a

rustc 1.12.1 (d4f39402a 2016-10-19)

cargo build -j1

    Finished debug [unoptimized + debuginfo] target(s) in 13.10 secs
    Finished debug [unoptimized + debuginfo] target(s) in 12.98 secs

rustc 1.13.0-beta.3 (106d18793 2016-11-04)

cargo build -j1

    Finished debug [unoptimized + debuginfo] target(s) in 6.45 secs
    Finished debug [unoptimized + debuginfo] target(s) in 6.50 secs

That's basically reducing the build time by 50%.

For the curious, the timing on current nightly is

rustc 1.14.0-nightly (cae6ab1c4 2016-11-05)
cargo build -j1
    Finished debug [unoptimized + debuginfo] target(s) in 5.89 secs
@xen0n

This comment has been minimized.

Show comment
Hide comment
@xen0n

xen0n Nov 7, 2016

Contributor

@brson

The builds have a deficiency though. I don't see "rust" packages for them on beta, so they can't be installed easily, either by "rust" tarball or by rustup toolchain install s930x-unknown-linux-gnu. I think the only way to install them from binary is by downloading the rustc binary and the cargo nightly.

Can confirm that the above is true for MIPSel and MIPS64el, as libc on MIPS lacks SIGCHLD which is holding wait-timeout, a rustup dependency. For rustup to work we would have to wait until we fix libc. I'm preparing a fix but 1.13.0 release is imminent and libc changes really shouldn't be rushed, so perhaps it's worth a little explanation for users of said platforms. But again non-x86 development platforms are a minority at present, so I wouldn't expect any significant warning note or something like that; a one-line remainder should be enough.

Contributor

xen0n commented Nov 7, 2016

@brson

The builds have a deficiency though. I don't see "rust" packages for them on beta, so they can't be installed easily, either by "rust" tarball or by rustup toolchain install s930x-unknown-linux-gnu. I think the only way to install them from binary is by downloading the rustc binary and the cargo nightly.

Can confirm that the above is true for MIPSel and MIPS64el, as libc on MIPS lacks SIGCHLD which is holding wait-timeout, a rustup dependency. For rustup to work we would have to wait until we fix libc. I'm preparing a fix but 1.13.0 release is imminent and libc changes really shouldn't be rushed, so perhaps it's worth a little explanation for users of said platforms. But again non-x86 development platforms are a minority at present, so I wouldn't expect any significant warning note or something like that; a one-line remainder should be enough.

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Nov 7, 2016

Contributor

Yeah, looks good -

hyper-0.5.0: 57.25s (stable) vs 36.93s (beta)
inflate-0.1.0: 18.91s (stable) vs 17.4s (beta)
regex-0.1.30: 7.67s (stable) vs 6.91s (beta)
rust-encoding.0.2.32: 6.70s (stable) vs 5.61s (beta)

Definitely some improvement there.

Contributor

jonathandturner commented Nov 7, 2016

Yeah, looks good -

hyper-0.5.0: 57.25s (stable) vs 36.93s (beta)
inflate-0.1.0: 18.91s (stable) vs 17.4s (beta)
regex-0.1.30: 7.67s (stable) vs 6.91s (beta)
rust-encoding.0.2.32: 6.70s (stable) vs 5.61s (beta)

Definitely some improvement there.

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Nov 7, 2016

Contributor

@alexcrichton - did you file issues on the perf regressions?

Contributor

jonathandturner commented Nov 7, 2016

@alexcrichton - did you file issues on the perf regressions?

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Nov 7, 2016

Contributor

The ? operator appears to be stable in current beta - This should be in these release notes, right?

Oh yes! Thanks for pointing that out. Also attributes on statements: #36995

Contributor

brson commented Nov 7, 2016

The ? operator appears to be stable in current beta - This should be in these release notes, right?

Oh yes! Thanks for pointing that out. Also attributes on statements: #36995

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Nov 7, 2016

Contributor

Updated to add ? and statement attributes, and I removed mention of the new ports, which aren't fully working, and the ability to not install rust-docs since I failed to deploy that change to the buildbot on Friday.

Contributor

brson commented Nov 7, 2016

Updated to add ? and statement attributes, and I removed mention of the new ports, which aren't fully working, and the ability to not install rust-docs since I failed to deploy that change to the buildbot on Friday.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Nov 7, 2016

Contributor

I'm going to port this to beta now.

Contributor

brson commented Nov 7, 2016

I'm going to port this to beta now.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Nov 8, 2016

Contributor

@Mark-Simulacrum would either winapi-0.3 or ndarray-0.6.8 be good for the perf suite?

Contributor

brson commented Nov 8, 2016

@Mark-Simulacrum would either winapi-0.3 or ndarray-0.6.8 be good for the perf suite?

@Mark-Simulacrum

This comment has been minimized.

Show comment
Hide comment
@Mark-Simulacrum

Mark-Simulacrum Nov 8, 2016

Member

I'd guess that winapi would be non-trivial to add since (AFAIK) it compiles next to nothing on *nix platforms, which is what the perf server is. Adding ndarray should be relatively trivial--let me know if you'd like that to happen, and I'll try and get it done soon.

Member

Mark-Simulacrum commented Nov 8, 2016

I'd guess that winapi would be non-trivial to add since (AFAIK) it compiles next to nothing on *nix platforms, which is what the perf server is. Adding ndarray should be relatively trivial--let me know if you'd like that to happen, and I'll try and get it done soon.

@retep998

This comment has been minimized.

Show comment
Hide comment
@retep998

retep998 Nov 8, 2016

Member

@Mark-Simulacrum Cross compilation of winapi is trivially easy because it's just an rlib so you don't even need a linker or system libraries. Just libcore compiled for a windows target is enough. Don't forget to pass --features everything.

Member

retep998 commented Nov 8, 2016

@Mark-Simulacrum Cross compilation of winapi is trivially easy because it's just an rlib so you don't even need a linker or system libraries. Just libcore compiled for a windows target is enough. Don't forget to pass --features everything.

@bluss

This comment has been minimized.

Show comment
Hide comment
@bluss

bluss Nov 8, 2016

Contributor

please don't use ndarray for that. Maybe I can propose some application of it to use instead (i.e. where the ndarray operations are actually instantiated and used).

Contributor

bluss commented Nov 8, 2016

please don't use ndarray for that. Maybe I can propose some application of it to use instead (i.e. where the ndarray operations are actually instantiated and used).

* [Stabilize the `?` operator][36995]. `?` is a simple way to propagate
errors, like the `try!` macro, described in [RFC 0243].
* [Stabilize macros in type position][36014]. Described in [RFC 873].
* [Stabilize attributes on statements][36995]. Described in [RFC 0016].

This comment has been minimized.

@Razican

Razican Nov 9, 2016

Contributor

Is this issue number correct? it has the same ID as the Stabilize the ? operator, and redirects to the same PR.

@Razican

Razican Nov 9, 2016

Contributor

Is this issue number correct? it has the same ID as the Stabilize the ? operator, and redirects to the same PR.

This comment has been minimized.

@brson

brson Nov 9, 2016

Contributor

Yes. They were stabilized in the same PR.

@brson

brson Nov 9, 2016

Contributor

Yes. They were stabilized in the same PR.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson
Contributor

brson commented Nov 9, 2016

@CryZe

This comment has been minimized.

Show comment
Hide comment
@CryZe

CryZe Nov 9, 2016

Contributor

I'm a bit confused how the ? operator is already hitting stable, if it just got stabilized 4 weeks ago? Isn't it supposed to be in beta first? Seems like it just skipped a cycle? Also the code suggests that it should be in 1.14 instead: https://github.com/rust-lang/rust/blob/master/src/libsyntax/feature_gate.rs#L357

// `expr?`
(accepted, question_mark, "1.14.0", Some(31436)),
Contributor

CryZe commented Nov 9, 2016

I'm a bit confused how the ? operator is already hitting stable, if it just got stabilized 4 weeks ago? Isn't it supposed to be in beta first? Seems like it just skipped a cycle? Also the code suggests that it should be in 1.14 instead: https://github.com/rust-lang/rust/blob/master/src/libsyntax/feature_gate.rs#L357

// `expr?`
(accepted, question_mark, "1.14.0", Some(31436)),
@bluss

This comment has been minimized.

Show comment
Hide comment
@bluss

bluss Nov 10, 2016

Contributor

@CryZe Stabilised and nominated for beta backport in #36995, so yes, it ran a slightly sped-up path to get here.

Contributor

bluss commented Nov 10, 2016

@CryZe Stabilised and nominated for beta backport in #36995, so yes, it ran a slightly sped-up path to get here.

@CryZe

This comment has been minimized.

Show comment
Hide comment
@CryZe

CryZe Nov 10, 2016

Contributor

@bluss Yeah, people told me about it in IRC by now. Seems like the "1.14.0" should be updated though. Looks like there's already a PR for this though: #37661

Contributor

CryZe commented Nov 10, 2016

@bluss Yeah, people told me about it in IRC by now. Seems like the "1.14.0" should be updated though. Looks like there's already a PR for this though: #37661

@bluss

This comment has been minimized.

Show comment
Hide comment
@bluss

bluss Nov 10, 2016

Contributor

Another new feature in 1.13 that I can't see in the changelog: Reflect was removed, so you can now call TypeId::of::<T> with only the bound T: 'static, previously T: Reflect or equivalently T: Any was required.

This simplifies ad-hoc type based dispatch on stable (as used by ndarray to call f32- and f64-specific linear algebra functions).

Contributor

bluss commented Nov 10, 2016

Another new feature in 1.13 that I can't see in the changelog: Reflect was removed, so you can now call TypeId::of::<T> with only the bound T: 'static, previously T: Reflect or equivalently T: Any was required.

This simplifies ad-hoc type based dispatch on stable (as used by ndarray to call f32- and f64-specific linear algebra functions).

@mrageh

This comment has been minimized.

Show comment
Hide comment
@mrageh

mrageh Nov 10, 2016

Hey Folks

any ideas on when 1.13 will be stable?

mrageh commented Nov 10, 2016

Hey Folks

any ideas on when 1.13 will be stable?

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
Contributor

jonathandturner commented Nov 10, 2016

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Nov 10, 2016

Member

@brson is this just waiting for an r+? Given that we just shipped 1.13.0 seems like no, but just wanted to make sure :)

Member

alexcrichton commented Nov 10, 2016

@brson is this just waiting for an r+? Given that we just shipped 1.13.0 seems like no, but just wanted to make sure :)

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Nov 11, 2016

Contributor

Yeah this needs an r+.

Contributor

brson commented Nov 11, 2016

Yeah this needs an r+.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton
Member

alexcrichton commented Nov 11, 2016

@bors: r+

Ok!

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Nov 11, 2016

Contributor

📌 Commit 0f817a0 has been approved by alexcrichton

Contributor

bors commented Nov 11, 2016

📌 Commit 0f817a0 has been approved by alexcrichton

eddyb added a commit to eddyb/rust that referenced this pull request Nov 11, 2016

Rollup merge of #37600 - brson:relnotes-1.13, r=alexcrichton
Add changelog for 1.13.0

The diagnostics PRs are excellent and some have excellent examples thanks @jonathandturner @estebank.

[Here are some notes about the performance changes during the release.
Compile times are improved %40 in some cases](https://gist.github.com/brson/1404c4bf4868d7d108f240a6ecba7f31).

This desires to be backported to beta for 1.13.

Sadly, the [1.12.1 changelog PR](rust-lang#37317) has not merged to master yet, and is sitting in a [rollup PR](rust-lang#37597).

r? @rust-lang/lang @rust-lang/compiler @rust-lang/libs @rust-lang/core

@eddyb eddyb referenced this pull request Nov 11, 2016

Closed

Rollup of 29 pull requests #37726

bors added a commit that referenced this pull request Nov 12, 2016

eddyb added a commit to eddyb/rust that referenced this pull request Nov 12, 2016

Rollup merge of #37600 - brson:relnotes-1.13, r=alexcrichton
Add changelog for 1.13.0

The diagnostics PRs are excellent and some have excellent examples thanks @jonathandturner @estebank.

[Here are some notes about the performance changes during the release.
Compile times are improved %40 in some cases](https://gist.github.com/brson/1404c4bf4868d7d108f240a6ecba7f31).

This desires to be backported to beta for 1.13.

Sadly, the [1.12.1 changelog PR](rust-lang#37317) has not merged to master yet, and is sitting in a [rollup PR](rust-lang#37597).

r? @rust-lang/lang @rust-lang/compiler @rust-lang/libs @rust-lang/core

@eddyb eddyb referenced this pull request Nov 12, 2016

Merged

Rollup of 30 pull requests #37730

bors added a commit that referenced this pull request Nov 12, 2016

@bors bors merged commit 0f817a0 into rust-lang:master Nov 12, 2016

1 check failed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment