2020 roadmap post

Centril · October 30, 2019, 11:27pm

The blocker here is design work. There was a Pre-RFC about inline asm a while back, but there was still some discussion to be had and somebody needs to champion and implement the ideas.

Two points:

Given the huge number of bugs inline ASM has and the difficulty of calling such a thing stable, I think it would be a huge project to stabilize inline assembly. I think that isn't compatible with another year of maturity.
The blocker is not just design work, but also agreement that we should have inline assembly on stable at all. For example, here are some notable objections to it:
- Inline Assembly. · Issue #1041 · bytecodealliance/wasmtime · GitHub
- In particular, I wouldn't want inline assembly on stable without having it implemented in Cranelift and the text above suggests that is not reasonable.
- Tracking issue for `asm` (inline assembly) · Issue #29722 · rust-lang/rust · GitHub
- specifiability
With these in mind I would actually prefer to remove asm! from nightly but I suspect that won't happen either.

Also, why is inline assembly a blocker for kernel development? Can't you link in assembly blobs?

Another approach would be Cargo-side improvements, e.g. asm_dir = "foo" and asm = "cc" in Cargo.toml which would result in taking the files in foo, feeding them to cc, and linking in the object files (credit due to @oli-obk for the idea).

Technical Debt and Measurable Progress

@mark-i-m Remember how I was arguing that maturity / sustainability isn't necessary? I take it all back. Despite having had a "year of maturity", there's still loads of things to finish. I do think we should continue next year with "Implement all the things; Be extremely conservative with accepting new RFCs if we don't have people lined up to implement and review them and if we don't think they are readily implementable."

It seems clear that a lot of good work was done by a lot of people.

Here's some more:

github.com

rust-lang/rust/blob/c553e8e8812c19809e70523064989e66c5cfd3f1/src/libsyntax/feature_gate/accepted.rs#L201-L253


      
          (accepted, macro_literal_matcher, "1.32.0", Some(35625), None),
          /// Allows use of `?` as the Kleene "at most one" operator in macros.
          (accepted, macro_at_most_once_rep, "1.32.0", Some(48075), None),
          /// Allows `Self` struct constructor (RFC 2302).
          (accepted, self_struct_ctor, "1.32.0", Some(51994), None),
          /// Allows `Self` in type definitions (RFC 2300).
          (accepted, self_in_typedefs, "1.32.0", Some(49303), None),
          /// Allows `use x::y;` to search `x` in the current scope.
          (accepted, uniform_paths, "1.32.0", Some(53130), None),
          /// Allows integer match exhaustiveness checking (RFC 2591).
          (accepted, exhaustive_integer_patterns, "1.33.0", Some(50907), None),
          /// Allows `use path as _;` and `extern crate c as _;`.
          (accepted, underscore_imports, "1.33.0", Some(48216), None),
          /// Allows `#[repr(packed(N))]` attribute on structs.
          (accepted, repr_packed, "1.33.0", Some(33158), None),
          /// Allows irrefutable patterns in `if let` and `while let` statements (RFC 2086).
          (accepted, irrefutable_let_patterns, "1.33.0", Some(44495), None),
          /// Allows calling `const unsafe fn` inside `unsafe` blocks in `const fn` functions.
          (accepted, min_const_unsafe_fn, "1.33.0", Some(55607), None),
          /// Allows let bindings, assignments and destructuring in `const` functions and constants.

This file has been truncated. show original

We should pick a few milestones and put active focus on achieving them. This applies even to technical debt work: we should explicitly choose certain technical debt items, make a big list, and actively work through it in a measurable way.

I think we can reasonably maintain a list of high level goals, but I think we should also avoid micro-management. At the end of the day, Rust is an open source project, not a company. I wouldn't want to feel like an employee.

Making a new edition just because it has been 3 years doesn't make sense to me. Indeed, I think we should make a new edition only when needed to reduce churn and overhead on the users.

I agree with this punchline.

We could collect things we want to change, perhaps even eagerly gate them under a new edition_next feature gate and then one day, when we think there's enough things in there we can RFC a proposal to stabilize set editions and its contents.

Topic		Replies	Views
Stabilization path for asm!()? language design	11	3309	March 25, 2019
Should we ever stabilize inline assembly? language design	149	9424	March 15, 2020
2019 Roadmap Progress? internals	14	15481	February 23, 2020
[Pre-RFC]: Inline assembly language design	70	14010	March 25, 2019
WebAssembly roadmap updates (help wanted)	3	1755	March 25, 2019

2020 roadmap post

Related Topics