Rust 1.24.0 prelease testing

Mark_Simulacrum · February 13, 2018, 12:42am

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.

matklad · February 13, 2018, 7:53am

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!

matklad · February 13, 2018, 8:00am

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.

Dushistov · February 13, 2018, 8:02am

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.

matklad · February 13, 2018, 8:08am

@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.

Dushistov · February 13, 2018, 8:50am

@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:

github.com/kwrooijen/cargo.el

Support Cargo project with workspace

opened 12:04AM - 26 Dec 17 UTC

closed 11:09AM - 21 May 18 UTC

nebgnahz

See sample project: https://github.com/nebgnahz/cargo.el-workspace For a proj…ect with workspace, Cargo returns issue relative to the workspace root directory. `cargo.el` instead find the directory with `Cargo.toml`, which can be different. When these two project root directory differ, Emacs compilation mode fails to find the correct file path. To a user, Emacs is unable to jump to the error location and a window prompt is open. In the linked sample project, the file in `add-one/src/lib.rs` has a typo `x1`. When one does a `cargo build`, we see the following compilation log: ``` -*- mode: cargo-process; default-directory: "~/repos/cargo.el-workspace/add-one/" -*- Cargo-Process started at Mon Dec 25 15:50:13 cargo build Compiling add-one v0.1.0 (file:///Users/benzh/repos/cargo.el-workspace/add-one) error[E0425]: cannot find value `x1` in this scope --> add-one/src/lib.rs:2:5 | 2 | x1 + 1 | ^^ did you mean `x`? error: aborting due to previous error error: Could not compile `add-one`. To learn more, run the command again with --verbose. Cargo-Process exited abnormally with code 101 at Mon Dec 25 15:50:15 ``` And Emacs wants to open a non-existant file `~/repos/cargo.el-workspace/add-one/add-one/src/lib.rs`. `cargo.el` finds file relative to `~/repos/cargo.el-workspace/add-one/` while Cargo `~/repos/cargo.el-workspace/`. Note: this wasn't an issue for old Cargo/`cargo.el`. I did a package update today and start experiencing this issue. Edit: ``` $ cargo --version cargo 0.25.0-nightly (e08f31018 2017-12-24) ``` ``` // emacs package-list-packages Status: Installed in ‘cargo-20171218.855/’ (unsigned). Delete Version: 20171218.855 Summary: Emacs Minor Mode for Cargo, Rust's Package Manager. Requires: emacs-24.3, rust-mode-0.2.0 Keywords: tools Other versions: 20171218.855 (melpa). ```

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?

matklad · February 13, 2018, 10:10am

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

Anyway, fix for cargo.el: Use cargo-metadata command to learn about workspace root by matklad · Pull Request #55 · kwrooijen/cargo.el · GitHub

Dushistov · February 13, 2018, 10:21am

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.

matklad · February 13, 2018, 10:32am

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

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

Dushistov · February 13, 2018, 10:39am

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.

davemilter · February 13, 2018, 11:03am

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?

Mark_Simulacrum · February 13, 2018, 3:05pm

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).

steveklabnik · February 13, 2018, 3:15pm

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.

HadrienG · February 13, 2018, 3:30pm

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?

steveklabnik · February 13, 2018, 6:09pm

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

cuviper · February 14, 2018, 5:47pm

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.

Mark_Simulacrum · March 25, 2019, 8:29am

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Rust 1.18.0 prerelease testing	8	1192	March 25, 2019
Rust 1.22.0 prerelease testing! announcements	6	1742	March 25, 2019
Rust 1.23.0 prerelease testing announcements	4	1678	March 25, 2019
Rust 1.21.0 prerelease testing announcements	3	1151	March 25, 2019
1.26.0 prerelease testing announcements	8	1588	March 25, 2019

Rust 1.24.0 prelease testing

Related topics