107 bugs marked as soundness issues

[rcseacord]

The Rust compiler is currently tracking 107 bugs marked as soundness issues. A typical Rust programmer is unlikely to encounter these. Encountering these bugs typically require poking at corner cases of the language that you’re unlikely to hit by accident. In contrast, a malicious programmer wanting to insert a supply-chain vulnerability into something that you consume has a rich set of tools.

The question is, do we need coding guidelines for these?

For C, we normally wouldn't write a rule for an implementation bug in a compiler. We would only have rules for flaws in the standard. But in Rust, the compiler preempts the standard?

Certainly we don't want to write rules for bugs that are transitory and will be fixed shortly. What sort of confidence do we have that these bugs will be fixed quickly?

[PLeVasseur]

For C, we normally wouldn't write a rule for an implementation bug in a compiler. We would only have rules for flaws in the standard. But in Rust, the compiler preempts the standard?

What standard? 😉

Certainly we don't want to write rules for bugs that are transitory and will be fixed shortly. What sort of confidence do we have that these bugs will be fixed quickly?

That's certainly a good metric to use. I suppose we could get in touch with the Compiler Team or Lang Team to get some of their thoughts on how these things trend. Could also look at the rate with which these are getting closed.

[felix91gr]

As I understand it, the labels of the form F-....... are for features that are still on nightly or are otherwise not on stable. They are shorthand for things like #![feature(min_specialization)]. Removing those from the list should show the unsoundness bugs that exist on stable. I'm going to try and figure out a query for that so that we can look at the list in the Issue tab

[felix91gr]

Okay, I figured out a query. Github's autocomplete saved my hands.

Under this filter, it's 87 bugs marked as soundness issues

Edit: 82 if we discount the ones that are marked to require nightly.

[felix91gr]

Stratified by priority:

• 0 are Critical Priority
• 36 are High Priority
• 29 are Medium Priority
• 6 are Low Priority
• 11 have not been assigned a priority

[felix91gr]

As I understand it, a lot of the bugs related to HRTBs are solved by the next trait solver, on which lcnr has been working for a while and is slated to land early next year. Only one such soundness bug has been classified as being fixed by the next trait solver, but if memory serves there were a good few others apart from that.

[felix91gr]

Okay, the links to soundness bugs I posted above should be a good place to start answering this question:

What sort of confidence do we have that these bugs will be fixed quickly?

The ones dependent on the next trait solver are a long-standing family of soundness issues. After the new solver is stabilized, which will happen soon ™️ (early next year), a good chunk of soundness bugs should be no more.

Regarding the rest, we'd have to ask around or examine the issues more closely.

---

Aside: if a nightly feature is found to introduce a soundness bug, it will be held in nightly until its soundness bug is fixed. So I wouldn't worry about the bugs that lie outside of stable.