2018 Edition End of Week Post (2018-08-04)

announcements
1

This is the weekly Edition Status Update; it contains the state of the content areas surveyed this week. This is the fourth post in this series. You can read the third post here. This week’s post should have been after the release of Preview 2. However, it will be somewhat delayed. Expect an announcement about the release soon.

Note: there has also been an important update to the Edition release schedule. We will have an extended beta period, meaning that the final release is now slated for 1.31 on December 6th.

Each content area below lists the blocking issues for the Preview 2 milestone described here, which was scheduled for 2018-08-02. We have slightly slipped on this deadline, but expect to announce it towards the end of next week. In addition, some areas highlight important news or places where contribution is needed. You can track the full issue burndown on this spreadsheet.

General note

  • Please keep trying to migrate crates, the weirder the better!
  • Cargo-fix is now part of Cargo proper — no separate cargo install step needed.
  • Preview 2 early next week.

WG-Embedded (@japaric)

  • On track for 2018.
  • The language team discussed #[panic_implementation] and were generally fine with the approach.
  • PR up for first section and outline of book.
  • RFC open for teams within rust-embedded for crate maintenance (news: please read!)
  • 3 issues scheduled for P2 will miss it; PRs 59, 124, 125 up this week.
  • japaric assigning and moving issues to RC1.
  • News
    • The second edition of the embedonomicon is out! It’s being temporarily hosted at https://rust-embedded.github.io/embedonomicon/. If you have always wondered how one would go at writing a bare metal (no_std) application from scratch for an embedded device this book is for you!
    • RISCV support has landed in nightly. You can use the new riscv32imac-unknown-none-elf target to build programs for the HiFive1. (rustup target add .. and then cargo build --target ..)
  • Help Wanted
    • We are looking for macOS and Windows users to help us test the examples in the embedonomicon (you don’t need any extra hardware to run the examples!). Let us know if you run into trouble following the examples.
    • If you are planning to read the embedonomicon you can help us add tests while you do so.
    • Have you heard of cargo-binutils? It’s a set of tools that let you inspect binaries of any architecture! We are looking for ways to make it easier to use and you can help us by giving us feedback or by implementing path inference.

TRPL (@steveklabnik)

  • Status is good. We have 0 blockers.

Edition Guide (@steveklabnik + @Centril)

  • The remaining 4 blockers were knocked out this week.
  • Preview 2 is on-track.
  • Release Candidate: 5 blockers, the section on modules is blocked on language changes.
    • We have assigned issues.

WG-CLI (@killercup)

Clippy (@oli-obk)

  • #[allow(clippy::foo)] now works.

cargo generate (@ag_dubs)

WG-WASM (@fitzgen)

  • 10 open issues due for 3 august (P2 + 1 day).
  • Things are on track.
  • fitzgen will schedule time in the next WG meeting to do some rough scheduling of things.

Lints (@alexcrichton)

Rustfix (@alexcrichton + @killercup)

  • Rapid progress, but slow to release due to rust-lang/rust queue delays, especially around stable release week.

rustfmt (@nrc)

  • Stabilization of tool attributes on the way.
  • Style guide RFC is in Proposed FCP.
  • In 1.0 Release Candidate status as of Edition Preview 2; rustfmt RC is available from cargo but not yet rustup. Please test this once it is available in rustup!

RLS (@nrc)

  • PR up for final remaining issue.
  • 1.0 Release Candidate coming soon. Stay tuned for an announcement! Please make sure to test it once it is available.

Editors (@nrc)

  • No Preview 2 blockers!

Language Design (@aturon)

  • A PR is open to extract impl_header_lifetime_elision out of in_band_lifetimes.
  • We will postpone in_band_lifetimes for Rust 2018 and revisit later.

Networking (@aturon)

2 Likes
2

What does it mean for rustfmt to release 1.0 ?

Will executing rustfmt 1.0 and afterwards executing rustfmt 1.0.1 or 1.1 on my code change the formatting ?

I mean, I use rustfmt every day, and been doing so for a long time already, but it still feels like it will take a long time till I can rely exclusively on rustfmt for formatting because almost every single time I use it I end up having to do many manual changes.

For example, it doesn't really work on macros: Rust Playground

Calling cargo fmt --all can succeed, but subsequently calling cargo fmt --all -- --check can report an error saying that formatting is incorrect (even though one just reformatted the whole project with cargo fmt --all!). Etc.

Don't get me wrong, rustfmt is really really nice, but it just overall feels to me to be beta quality at best.

I expect a 1.0 release to be able to 1) format rust code, and 2) be able to check that rust code is properly formatted. The tool doesn't really do either automatically yet, and I don't see it doing it any time soon (its a hard problem).

How many rust-lang projects are using rustfmt? Are we dogfooding it in rust-lang/rust ? servo ? how many rust-lang-nursery crates are using it to automatically format all code, and to check that all code is automatically formatted on CI?

Because if it doesn't work for rust-lang/rust, nor servo, nor the rust-lang-nursery crates. Why should it work for end users?

And it is not only that it doesn't work, it is getting a lot better but formatting some of the rust-lang-nursery crates with rustfmt does currently still break their build: https://github.com/rust-lang-nursery/rustfmt/blob/master/.travis.yml#L36

That is, your code compiles and passes all tests, rustfmt it, and it doesn't compile anymore and/or tests start to fail.

2 Likes
3

See Rustfmt stability by nrc · Pull Request #2437 · rust-lang/rfcs · GitHub

On all the details I will defer to @nrc.

4

That the API and formatting will be backwards compatible.

No.

There are some limitations, macros is one of them, that means you might need to fix up your code after formatting, but once you've done it once, you'll never have to do it again.

I intend for there to be a 2.0 and for it not to take too long (six months to one year) and macros is one of the things I want to focus on. However, we can't wait for Rustfmt to be perfect before making a 1.0 release, or we'd never have one. In particular, the stability of rustfmt (or lack thereof) is something that is stopping a lot of people using it on CI, and thus using it consistently. I believe it is not important for tools to stick to the '1.0 forever' policy of Rust itself.

I'm surprised by that, it certainly doesn't always happen. Could you report an issue please?

How many rust-lang projects are using rustfmt? Are we dogfooding it in rust-lang/rust ?

It's been used on Cargo, Rustup, the RLS and Rustfmt itself, plus many other not central projects. It has been used on parts of the Rust repo, but certainly not all of it.

to check that all code is automatically formatted on CI?

The trouble is this is a chicken and egg thing - if rustfmt isn't stable, people don't want to use it in CI.

rustfmt does currently still break their build

To be clear, the 1.0 label is a mark of stability, it is not saying that it is bug free (because it is software), but it saying, if your code formats without bugs then it will continue to do so in the exact same way.

And to be clear again, we're only announcing a 1.0 RC, if it turns out there are lots of bugs and poor formatings, then it can stay a release candidate for a long time (of course I'd rather it didn't.

4 Likes
5

This is not true: rustfmt just doesn't work on macros, so you have to manually format macros. That is, if you write a new macro, or you modify an existing one, you have to manually format it. rustfmt won't do it for you. A lot of widely used Rust projects contain a lot of macros (e.g. nom). Not being able to format macros is a pretty big omission.

And to be clear again, we’re only announcing a 1.0 RC, if it turns out there are lots of bugs and poor formatings, then it can stay a release candidate for a long time (of course I’d rather it didn’t.

I understand the chicken egg situation. But if this in an RC project then it should be possible to apply it to rust-lang/rust or any other big real world Rust project, and iterate on it till it works, and then do the 1.0 release for users.

I’m surprised by that, it certainly doesn’t always happen. Could you report an issue please?

Its been happening on rust-lang-nursery/stdsimd for 1.5 months: [stdsimd] cargo fmt --all succeeds but subsequent cargo fmt --all -- --check fails · Issue #2787 · rust-lang/rustfmt · GitHub As in, we have been trying to enable rustfmt on CI for a year. We'll keep trying and reporting issues and trying to help, but we are not there yet.

6

This is not true: rustfmt just doesn’t work on macros, so you have to manually format macros. That is, if you write a new macro, or you modify an existing one, you have to manually format it.

What I meant is that the formatting of macros is backwards compatible, so if you format a macro manually, then run rustfmt, then update rustfmt and format again, the formatting of the macro won't change. You are right that you have to continue to manually format if you change the macro or add a new one.

if this in an RC project then it should be possible to apply it to rust-lang/rust or any other big real world Rust project, and iterate on it till it works

The biggest problem with Rust has been reviewing and landing patches without breaking everyone or needing to endlessly rebase. We have been using it on a number of other large, real-world projects and it seems to be working pretty well.

Its been happening on rust-lang-nursery/stdsimd for 1.5 months: https://github.com/rust-lang-nursery/rustfmt/issues/2787

Ah, I didn't quite comprehend what was happening there, I'll take a look at fixing that ASAP.

7

Could you comment more on this? For example, servo has been one of the biggest testbeds for Rust features, but it doesn't use rustfmt unconditionally (and not in CI).

8

Looking at the issues, it really seems it is going to end up to look exactly like kickstart, which already does most of the features requested (including the things that will be needed later).

How come this is apparently part of Rust 2018 despite having had no mentions whatsoever in the pre-RFC thread? Is there another thread I missed?

1 Like
9

#[allow(clippy::foo)] now works.

@oli-obk Is this in nightly yet? I tried #[allow(clippy::redundant_closure)] but I'm still getting warnings about redundant closures.

> cargo clippy --version
0.0.212

> rustc --version
rustc 1.30.0-nightly (3edb355b7 2018-08-03)
10

Where can I find more info?

11

cc @ag_dubs

cc @killercup

12

@kbknapp told me last week that the remaining thing to be done is finish the move away from the stringly typed args. (Beyond that, there is of course a lot of testing to be done to make sure this release is stable -- it includes a huge bunch of stuff but still aims to be a very easy upgrade from clap v2 code.)

13

I'm very sorry if it feels to you like we are ignoring your project that is a more mature solution!

The current version of cargo-generate was started after talking to people of the domain WGs. Its aimed at delivering a very small set of functionality to support people by giving them an easy setup for an embedded crate or a CLI app. It is possible that we'll realize that we need exactly kickstart, but without asking people for what they need we didn't want to just jump to conclusions (I personally am not opposed to merging the projects).

I'm sorry, I haven't really kept track of this; I've been focussing on different things the last weeks. @ag_dubs, maybe you have time next week to chat about next steps for cargo-generate?

14

Nope, not in nightly yet. PR is here: https://github.com/rust-lang-nursery/rust-clippy/pull/2977

1 Like
15

super happy to collaborate, @Keats. it looks like your project was only published after cargo-generate was… and i, and the cargo team, core team, and cli team, had not heard of it until the thread on reddit about cargo-generate and kickstart happened (which, for what it’s worth, was a pretty unfriendly thread! hence my lack of reply there).

i appreciate that you have worked on your own solution for a while now, and i think it’d be great to collaborate, but i think it’s a bit in bad faith to accuse us of not using a solution that was not discoverable as such until after we had made an announcement about another tool! let’s keep the convo positive and avoid defensiveness and territoriality, and i’m sure we can work well together to find the best solution for the rust ecosystem!

16

I'm a bit surprised by the fact no one on the team heard about it to be honest... The first working release of kickstart was Feb 15 and cargo-generate Jul 17. Since this was a project about cargo templates, I assumed the pre-RFC Cargo Templates thread was the right place to post it (I also mentioned it a couple of times in Reddit in the what are you working on this week but those ones are easy to miss). Since you mentioned no one working on cargo-generate had heard of it before, I assume no one read that thread. What is the right way to publicize a MVP for a feature if a RFC thread is not?

17

I actually spent a lot of time reading that thread when I was working on writing up an RFC for the feature which I eventually opted to switch with a “crate-as-RFC”. I did not get to the last comment. And I’m sorry about that. Duplicated effort is never something I am aiming for.

There are always going to be forum comments that folks miss. There’s just so many of them and so few folks in leadership (who are Really Really Busy) We’re trying our best but it’s just going to be the case that we miss some things.

If you really want advice, I would say, the best way to get folks to see an MVP of a tool is to release the tool to the public, get folks using and talking about it. Or join the relevant team’s meetings and bring it up there.

In the long run though, rehashing why this happened isn’t going to help us move forward. Both @killercup and I have extended an offer to collaborate with you- but you continue to rehash how this situation came to be in the first place. I’m still down to collaborate, but I won’t be rehashing how this happened anymore.

5 Likes
18

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