A list of high priority but borderline 1.0 bugs that need attention


#1

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.

Update rustup.sh for beta

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.


#2

I’ve got a lint for #18380, just fighting with the test suite to get it to work properly on Windows.


#3

This one, sadly, turned out to have more downside than upside. I’ve since closed the issue.


#4

Why is it even allowed? It looks like a universally bad idea. I know the names of built-in types can’t be reserved, because they are used for modules in std, but maybe their use in definitions can be prohibited for everything except for modules?


#5

I don’t know whether it’s better to allow it or deny it, but it should definitely do something reasonable, and not what happens today. On the pro side, shadowing usually works in Rust. Personally, I’d be fine with not allowing types with primitive names, but I’m sure others have opinions as well. If you are interested you might follow up on the issue tracker.