search

rust-lang / unsafe-code-guidelines

Forum for discussion about what unsafe code can and can't do
https://rust-lang.github.io/unsafe-code-guidelines
Apache License 2.0
666 stars 58 forks source link

Status of Unsafe Code Guidelines Reference #254

Open cdisselkoen opened 4 years ago

cdisselkoen commented 4 years ago

The README in this repository currently states:

The main goal for the WG in 2019 is to RFC parts of the guide into the language specification, and move those parts into the Rust Language Reference proper.

Similar language appears in the introduction to the Reference itself.

I'm curious about what progress has been made on this (it's now November 2020 at time of this writing). Should we just update this statement by changing "2019" to "2020" or "2021", or are there other updates to mention?

cdisselkoen commented 4 years ago

(Also please know that I'm not trying to be facetious with this if the answer is just that progress has been slow or gone a different direction. I'm genuinely curious about this project!)

digama0 commented 4 years ago

There was some recent discussion about this on Zulip. I think the current status is that progress is stalled, but we also have way too much for an RFC at this point so likely next steps would involve separating out chunks that we can bring to t-lang to start the stabilization process. I think lack of decision making power has also been a contributing factor; we all have elaborate theories but none of it is official and the larger the disconnect the harder it is to progress. (In other words, we've been "brainstorming" for two years and forgot what comes next.)

RalfJung commented 4 years ago

A discussion has been had with T-Lang about an RFC for layout guarantees at some point, and T-Lang asked that the documentation we gathered be supplemented with more motivation. But that never happened, the first thrust was already lost at that point and summarizing all the "why" spread across the many issues that lead to the current UCG document does not seem exciting enough that anyone stepped forward so far to do this.^^ I think it would take someone with an actual interest in getting more layout guarantees (I personally have few stakes in this particular discussion) to do that work.

We also started discussion about validity guarantees, but I don't think we were able to reach consensus on any of the types where there were open questions to begin with (mainly: https://github.com/rust-lang/unsafe-code-guidelines/issues/71, https://github.com/rust-lang/unsafe-code-guidelines/issues/77). We did learn quite a few new things and my own opinions solidified somewhat (and not always to what I started out as considering the best option), but reaching consensus on these things is hard as there are few objective guiding principles. Furthermore, reference validity is somewhat entangled with the aliasing model, which is a very hard thing to even specify precisely, let alone discuss -- I'd like to specify validity rules for reference that consider only their bit-level properties and their type (but not whatever the state of memory is), but this does not actually help unsafe code authors much as they need to additionally ensure that aliasing rules are respected. So what good would it even do to RFC that "any non-null well-aligned pointer is valid at reference type (where uninhabited pointee types make 'infinite alignment requirements', so no reference is valid)"? Some aliasing model questions might end up requiring some form of "references point to valid data" despite this rather lax validity requirement!

The main purpose of this project right now is to be a central place for people to discuss questions around the "tricky parts" of the Rust semantics, and to have an issue tracker dedicated only to those problems (that would otherwise drown in the main Rust issue tracker).