We spent the first half of the day with kickoff talks (my slides are above; Niko also gave a talk), introductions, and more. In the second half we had our first round of meetings. Here’s a summary of what got done:
Compiler clients
Agreed on kinds of info that different clients need and the layers of stability involved
Overall interface to rustc from external tools
Should enable composable plugins (e.g. combining clippy with another static analysis)
Builds on incremental query arch
WG: CLI
Reviewed survey results
Discussed overall WG strategy:
Focus on improving existing crates and making them discoverable
Based on the survey, this primarily means documentation + testing
Work backwards from the “CLI Guide” we plan to deliver for Rust 2018
Picked a few focus areas: input/output libs (color, logging, etc), testing, getting started guide for CLI tools
Community
Mozilla Activate page — ready to ship tomorrow
Macros 2.0
Selected a subset of “macros 2.0” to stabilize in Rust 2018
Called “macros 1.2” — custom attributes applied to items and proc-macro-!-macros in item position
No hygiene (coming later)
Follow-up work for API details on proc macros
Stabilize import of macros through the module system
Verification
Bringing together testing and verification work — what’s needed here, how can we coordinate?
I wish I was there, if only to be a fly on the wall. Sounds like a lot of fun!
This might be the wrong place to ask, but…
Some folks might have seen my half-kidding tweet earlier, but I actually would like to know what the plans are for being able to return an impl Trait type from a trait method (RFC 2071). Is the plan for that to be included as part of the 2018 era? I’m hearing conflicting information about it being postponed into the distant future which is disappointing and somewhat surprising to me, as the main project I’d want impl Trait for needs it in traits!
impl Trait in traits is very high priority, but it’s not feasible to ship in the main 2018 edition release (targeted for September). We will certainly see it implemented in 2018, and possibly stabilized this year as well.
Allow crate authors to label deps as private, which enables a lint
Change resolution heuristics to favor fewer duplicates where possible
Build system integration
Analyzed RLS needs
Let’s add a minimal notion of build plans, even if they just provide rustc invocations with command-line arguments. We can iterate later about how to provide higher-level metadata rather than just rustc command lines.
Let’s add a minimal implementation of metabuild, and we can iterate later on how to implement the individual build crates in the ecosystem (e.g. parsing Cargo.toml or finding native libraries), as well as on better interfaces to those build crates.
WG: wasm
How to reduce code size bloat around panics
Worked through a bunch of wild ideas
Ended up working through a simple case
Started at 44k, just to panic
Now: 350 bytes
wasm-bindgen now works with commonjs (i.e. in node)
Unsafe code guidelines
Made a plan to draft a reference about the questions around unsafe code, and what is known and unknown about their answers
thread::abort
Places where we’re not sure yet — you shouldn’t do them, but others might
Will help organize future investigations as well
Statics, consts, and Sync
Came up with a bug fix that may be needed for soundness
Drilled down into a potential model for aliasing
Then Ralf and Julian holed themselves away for hours and hopefully Thought Deep Thoughts
Focused mainly on valgrind integration
WG: net
Five things we plan to do:
Hasty: small blocking web server, intended for learning when you’re new to Rust
Tyger: stable API over hyper providing the interfaces we need; want to reach 1.0 for the 2018 edition
Build middleware based on Tower’s interfaces
Improve debugging for futures based on a combination of backtraces (for async/await) and explicit bread crumbs
Looks like it’s meant to fit the “intermediate documentation” use case – here is a dogfooded documentation site for doxidize. Wait…AND it has functionality that rustdoc has? I’m not sure even AFTER looking. It seems like it wants to subsume rustdoc and more…
I believe we had a chat about this a few months ago with you and Carl -- the basic idea is that hyper, over time, has been increasingly targeting the lowest-level cases and providing the greatest flexibility. The networking WG is interested in a higher level crate that pulls together a few best practices to provide a simple, ergonomic async http story (building in TLS, configuration, and a few other concerns). Hyper would be taken as a private dependency, actually providing the implementation, while provided API surface would be narrower and something we could hope to reach 1.0 on relatively quickly.
