2018 Edition End of Week Post (2018-07-20)

[Centril]

This is the weekly Edition Status Update; it contains the state of the content areas surveyed this week. This is the second post in this series. You can read the first post here. This week we’re happy to announce that we were able to get status updates from every group.

Each content area lists the blocking issues for the Preview 2 milestone described here, which is scheduled for 2018-08-02. 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!

NLL (@nikomatsakis)

• Focusing on:
  • ICEs and correctness problems
  • Edge cases for diagnostics
  • Edge cases for performance or memory usage
• Making progress on those items
  • Current list of issues is mostly assigned
  • There are some ICEs and things yet to be investigated
• News
  • Meeting is at 19:30 UTC on Tuesday(s), and you can check the internals thread where we post updates and in particular issues to tackle.
  • Thanks to lqd, pietroalbini and some others for crater run triage and assistance

Clippy (@oli-obk)

• Clippy is in rustup! So one issue down, just 2 left
• The RFC has been silent for a while, just needs a small patch and it should be ready.
• The other issue is #[allow(clippy::foo)], but someone is working on it, so we’ll get it in a few weeks
• PR https://github.com/rust-lang/rust/pull/52264 was merged

Edition Guide (@steveklabnik)

• Current resources sufficient
• Work will be split up between steveklabnik, Centril, and @mark_simulacrum
• If you’d like to help out, feel free to give us feedback on the issue tracker, in particular we’d love input on the readability of the guide.
• No important news this week

TRPL (steveklabnik)

• Preview 2 issues done
• RC issues blocked on stabilizations etc

Embedded (@japaric)

• Need eyes on FCP for https://github.com/rust-lang/rust/issues/44489#issuecomment-398965881
• Feedback on https://japaric.github.io/discovery/ is always welcome and can be submitted to the issue tracker
• More tips like “I do $foo in C; what should I do in Rust” for https://github.com/rust-lang-nursery/embedded-wg/issues/126 are welcome.
• libm ported to rust, not yet available in standard distribution (on crates.io: https://crates.io/crates/libm)

CLI (@killercup)

• Originally had 4 things killercup wanted WG CLI to work on to make writing CLIs in Rust a somewhat coherent experience:
  • Input (args, config files)
  • Output (colors, logs, human vs machine output)
  • Distribution (producing linux packages but also stuff like generating man pages)
  • Testing (assert_cli 1.0)
• A lot of progress has already been made and published:
  • Argument parsing (clap 3)
  • Packaging (various efforts)
  • Testing (@epage rewrote assert_cli)
• Other work has also happened, such as man page generation, but is not yet ready for use
• Two near-term strategies:
  • Double down on ongoing efforts and push them over the finish line (requires killercup to work on stuff but way more heavily depends other people to be motivated to work on the right issues)
  • Get prototypes going for the stuff we’ve only just designed
  • killercup is inclined towards the former.
• Deliverable: A rough draft for a “writing a CLI app in rust in 15min” guide that showcases most of what killercup has mentioned
• Will try to work with some folks and see if we can integrate more other docs in a prominent place, e.g. https://crate-ci.github.io/
• Once we have some stuff that works, killercup will make sure to open a huge bunch of easy issues!
  • clap and assert-rs already have a few easy issues

rustfix (killercup)

• Merging into Cargo
• Generally in good shape for Preview 2

Lints (acrichto)

• We need more testing!
• Migration lints should be reaching a pretty polished state

WASM (@fitzgen)

• Work on template stuff paused until cargo generate is available (which it now is).
• Labeled under “Rust 2018 Preview 2”
  • https://github.com/rustwasm/rust_wasm_template/issues/15
  • https://github.com/rustwasm/rust_wasm_template/issues/14
• Generally: a lot of stuff is dependent on wasm-pack, which is also a bit in flux
• Going to talk to the WG about concrete goals for Preview 2
  • Next wasm WG meeting: Thursday
• News Items:
  • The wasm-bindgen crate has been a bit unstable as of late due to features being stabilized in the compiler. By next week we should be on smooth sailing again with only one unstable feature gate remaining (use_extern_macros), thanks for your patience on nightly in the meantime!
  • We’re very close to publishing a js-sys crate, and help binding the remaining APIs would be greatly appreciated!
  • Have you ever wished cargo test would “just work” for wasm? We may have an answer for you! Early adopters and feedback on this would be greatly appreciated!
  • Work continues on a web-sys crate for all browser APIs defined on the web, and if you’re interested we’d love your help in implementing more APIs!
  • Our first RFC for type conversions is nearing FCP, if you’ve got thoughts about how to encode type hierarchies from JavaScript in Rust we’d love your thoughts!
  • The rust_wasm_template repository is now compatible with the newly-published cargo-generate, help us give it a spin!

Lang stabilizations (@aturon)

• aturon made a post about a roster of a few possible stabilizations for preview 2.
  • We aim to stabilize these features. Thus, this is an excellent and the last opportunity to test them out and give feedback, particularly if you did not care for the features from the get go.

Networking WG (aturon)

• Attempting to reboot the WG
• Main goals for Preview 2:
  • futures 0.3 alpha out — done!
  • async / await working with futures 0.3 — done!
  • WG actively meeting and setting goals for the Edition — next week

Marketing (aturon)

• No news this week

rustfmt (@nrc)

• Solid progress this week, on track for Preview 2
• RFCs waiting on updates from nrc

RLS (nrc)

• Down to just a single issue https://github.com/rust-lang-nursery/rls/issues/876
• In good shape for Preview 2
• A new version of the Rust (rls) plugin for VSCode has been released with some bugfixes.
• Testing requested:
  • The VSCode plugin
  • Clippy integration

Editors (nrc)

• No change from last week
• Nothing pressing for Preview 2

[dhardy]

Regarding the new module system and embedded (@japaric): can we have a cfg to enable the core lib in std builds? Motivation:

#![cfg_attr(feature="std", core_with_std)]
#![cfg_attr(not(feature="std"), no_std)]

/// works with and without std:
use core::mem::size_of;

Our current solution, extern crate std as core;, doesn’t work as well when having to prefix crate:: to crate paths (Rust 2018).

Alternatively Cargo may be able to handle this, except I don’t believe it’s possible to add a dependency on the core crate?

[SimonSapin]

Today you can always use extern crate core;, regardless of whether you also use #![no_std].

The module/path changes make extern crate unnecessary for dependencies declared in Cargo.toml, but it’s still necessary for standard library crates, right? For example extern crate proc_macro;.

[petrochenkov]

@dhardy
use core::mem::size_of; or let x = ::core::mem::size_of; already work regardless of no_std (in 2018 edition), because it can search crates not passed with --extern in library directories.

“Extern prelude” (i.e. mod m { let x = core::mem::size_of; }) has to be a bit more conservative, it only looks at crates passed with --extern and a very conservative list of “known” crates (it’s std for std builds and core for no-std builds). We can certainly add core to known crates in std builds too.

[dhardy]

@SimonSapin thanks; not sure why we didn’t do that already! Unfortunately it doesn’t help in Rust 2018 because it only binds core in the top-level crate namespace, so use core::mem; won’t work in sub-modules in Rust 2018 (though it does in 2015).

@petrochenkov doesn’t work for me. Perhaps core should be added to the list of known crates, yes, though maybe then we’ll have newbies asking "should I use core or std"?

[Nemo157]

@dhardy it appears to work in 2018 for me, can you show an example of what’s not working for you?

[vks]

@Nemo157 It doesn’t work outside of use statements.

[Nemo157]

@vks ok, but that’s just what @petrochenkov said earlier, the core crate is available in the “global” scope that use or absolute (::<path>) uses, but isn’t in the prelude injected into every module so you have to use an absolute path to it while you don’t for std. It sounds like it should be possible to add core to the prelude as well which would fix this:

“Extern prelude” (i.e. mod m { let x = core::mem::size_of; } ) has to be a bit more conservative, it only looks at crates passed with --extern and a very conservative list of “known” crates (it’s std for std builds and core for no-std builds). We can certainly add core to known crates in std builds too.

(although then what about alloc? ISTM that we’re a bit late to do anything major about it for 2018, but removing the prelude and having to explicitly add dependencies on the standard libraries to Cargo.toml seems like something to aim for in Rust 202X):

[SimonSapin]

Standard library crates today are:

• core
• alloc
• std
• proc_macro
• test

[dhardy]

@vks I suppose we can use this solution for now.

[system]

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