Rust 1.24.0 prelease testing

#1

Rust 1.24 will be released on Thursday, and builds are no available for testing. Release artifacts are uploaded to dev (dev-static.rust-lang.org) currently and will be promoted to prod (static.rust-lang.org) this Thursday. The URL is https://dev-static.rust-lang.org/dist/2018-02-12/.

You can test the release with rustup:

RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup update stable

Please let us know if you run into any issues! Pending any detected regressions these are likely to be the exact artifacts that we’ll release on Thursday.

You can find the release notes on GitHub.

#2

What about rustfmt? Rust 1.23 included rustfmt and not cargo-fmt, and this was an unannounced secret feature. Is rustfmt fully ready now? If so, we should yell about it (and incremental compilation) from the mountaintops!

#3

Hm, isn’t this the release of Cargo which changes the cwd of the compiler with various implications (https://github.com/rust-lang/cargo/pull/4788)? If so, this definitely should be mentioned in the release notes.

#4

Any chances to include fix for this issue?

Little be nervous, because of this would be the first stable release that would be completly unusable for me.

#5

@Dushistov do you know which editors are affected? It seems to me that the proper solution here is just to fix the editors?

For IntelliJ, the fix is already in the nightly and will be release later today.

#6

@matklad

At least GNU Emacs. All my workflow with rust is broken, for example running test that has cursor inside it.

Not all projects has enough man power:

And it seems not power effective, for me it looks like more energy-efficient to fix one place - cargo, then all existing tools, editor and IDE?

#7

And it seems not power effective, for me it looks like more energy-efficient to fix one place - cargo, then

I would say that Cargo is correct, and it’s the tools which should be fixed :slight_smile:

Anyway, fix for cargo.el: https://github.com/kwrooijen/cargo.el/pull/55

#8

Thank you, @matklad . Never heard about cargo metadata command, cargo help 2>&1 | grep metadata is empty. May be lack of documentation about metadata and in general the way to fix this issue, make cargo/4998 so inconvenient.

#9

The cargo metadata is documented at https://doc.rust-lang.org/cargo/reference/external-tools.html.

It is sort of intentional that it is not present in --help output, because it is mainly for those implementing tools on top of Cargo, and not for the actual Cargo users themselves :slight_smile:

There’s certainly some miscommunication happening: I myself learned about the new workspace_root key in metadata relatively recently :slight_smile: But I guess nightly/beta/stable trains and per-release testing work ok to discover such issues :slight_smile:

#10

Yes, I found it after look at your patch. But how should I guess that it exists? I heard about it before, but I run cargo help and decide that this is experimental feature not available in stable.

#11

Thank you, I use emacs for years, but my elisp skills is still pretty bad.

Sadly that this is not really fix, it just replace one bug with another. May be just revert commit in cargo tree that cause so many problems?

#12

What about rustfmt? Rust 1.23 included rustfmt and not cargo-fmt, and this was an unannounced secret feature. Is rustfmt fully ready now? If so, we should yell about it (and incremental compilation) from the mountaintops!

This release does include both cargo-fmt and rustfmt with the rustfmt-preview component. I’m not sure it’s something to put in the release notes, but I’ll ask @steveklabnik to include it in the blog post if we feel it’s ready.

As for the cargo working directory change, I think we’ve decided to land this and deal with the breakage. It’s unfortunate, but the Cargo team feels/felt that the breakage was warranted for the bug fix of no longer recompiling when we changed working directories. We’ll continue pushing on the issues you mentioned, though, and it seems likely that by 1.26 they’ll be ready to go (though no guarantees).

#13

I defiantly planned to include it, including explaining -preview.

I thought that the CWD fix was coming next release, it’s in this one? Good to know…

I’m hoping to have a draft of the blog post up later today.

#14

In the release notes…

rustc now uses 16 codegen units by default for release builds. For the fastest builds, utilize codegen-units=1.

I think “fastest builds” is somewhat ambiguous. Are we talking about the best compile times or the best runtime performance?

#15

Done: https://github.com/rust-lang/blog.rust-lang.org/pull/228

#16

I agree that “fastest builds” is ambiguous. The answer is that more codegen units should have faster compile times, but codegen-units=1 still has better runtime performance, tracked here.