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]
https://github.com/rust-lang/rust/issues/21833
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
https://github.com/rust-lang/rust/issues/21837
Weird high-priority bug.
Update rustup.sh for beta
https://github.com/rust-lang/rust/issues/21149
rustup.sh needs to be able to download from either nightly, beta, or stable channels, using the manifest.
Audit lint passes
https://github.com/rust-lang/rust/issues/21761
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
https://github.com/rust-lang/rust/issues/21611
There's an eternal question about what 'align_of' actually means. Figure it out and update the code.
Various malformed attributes are accepted
https://github.com/rust-lang/rust/issues/21435
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
https://github.com/rust-lang/rust/issues/20427
Defining types with the name of primitives behaves weird.
We permit type parameters and so forth on builtin bounds
https://github.com/rust-lang/rust/issues/20302
Bogus syntax accepted. Minor backcompat risk.
#[derive]'d PartialOrd and Ord use variant declaration order, not explicit discriminant values, for (partially) C-like enums
https://github.com/rust-lang/rust/issues/15523
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
https://github.com/rust-lang/rust/issues/20064
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
https://github.com/rust-lang/rust/issues/19925
Backcompat risk if people rely on the ABI.
Make 'str' a library type
https://github.com/rust-lang/rust/issues/19036
Mostly just a fun project. Shouldn't cause visible breakage.
#[repr(C)] and Drop causes undefined behavior in FFI code
https://github.com/rust-lang/rust/issues/18380
Backcompat hazard with the Drop flag. Implement a lint to warn people about it.