There are quite a lot of issues queued up for 1.0 beta and 1.0. Hard decisions will be made. Increasingly during issue triage we’re seeing issues that would be nice to have but will not make the cut unless somebody is inspired to step up and implement them. Some are things that can’t be done ever after 1.0 because of the breakage, some are things that may not be possible the longer they go unfixed because of de-facto stability, others are just high priority.
If you are itching for important work to do to contribute to the greater glory of Rust, here are some ideas.
Silent demotion of lifetime in analysis causes confusing message
Summary: the compiler accepts a trait impl function returning a &'static str when the trait requires only &'a str, 'a being the life of the object, but then assumes the lifetime of the returned value is only &'a str despite direct call (not via trait).
If this isn’t fixed before 1.0 it won’t be.
rustdoc: Fn trait sugar output types are broken for inlined signatures
Rustdoc is formatting things wrongly.
Feature-gate #[no_std]
Easy to implement. The only stable configurations of Rust for 1.0 will be using the standard library. Important to do this early so crate authors understand the breakage.
Trait bounds on struct type params aren’t always enforced
Weird high-priority bug.
rustup.sh needs to be able to download from either nightly, beta, or
stable channels, using the manifest.
Audit lint passes
We have a huge number of lints, and all of their names are at least decisions we cannot change. We have a naming convention RFC which dictates what each lint should be called, and we need to audit all names as some may have slipped through the cracks (we have a few new ones since the RFC was accepted).
Back-compat risk: same label can be attached to distinct blocks in the same scope
Add a restriction to block labels for futureproofing.
align_of for small structs does not give the actual alignment of pointers
There’s an eternal question about what ‘align_of’ actually means. Figure it out and update the code.
Various malformed attributes are accepted
In many cases the compiler just checks whether an attribute just has the correct name, allowing garbage metadata to be attached. Making these checks more strict is good futureproofing.
Redefining built-in types does not work
Defining types with the name of primitives behaves weird.
We permit type parameters and so forth on builtin bounds
Bogus syntax accepted. Minor backcompat risk.
#[derive]'d PartialOrd and Ord use variant declaration order, not explicit discriminant values, for (partially) C-like enums
The derived order for enums with explicit discriminants is wrong in a way that presents a backcompat risk.
start / generated C main is the wrong type
There’s some questions about the types declared in the low-level entry-points. Can’t be ungated until resolved.
Fn item types should be zero-sized
Backcompat risk if people rely on the ABI.
Make ‘str’ a library type
Mostly just a fun project. Shouldn’t cause visible breakage.
#[repr©] and Drop causes undefined behavior in FFI code
Backcompat hazard with the Drop flag. Implement a lint to warn people about it.
