chalk VS unsafe-code-guidelines

The Rust compiler uses a Prolog-like query language internally for type checking generic requirements and traits: https://github.com/rust-lang/chalk

rust-analyzer already uses chalk (https://github.com/rust-lang/chalk) which should replace the current trait resolver.

Well it's quite easy to come to that conclusion: The code compiles with rustc, which is currently the reference implementation. If rust-analyzer does not match rustc's behavior it's an issue in their implementation. That written it's not that easy to fix as it's related to how rust-analyzer resolves types/traits. rust-analyzer uses chalk for this, which is known to be incomplete/diverging from the RFC'ed behavior. Now one could argue that we can simplify diesel to the point where it works will with rust-analyzer/chalk, but that would result in basically removing core diesel features that exist way longer than rust-analyzer.

> Not all of those things work well in the real world. E.g. logic programming (prolog) is cool but ultimately never really caught on.

It does have its niches though. For example, there is a trait solver for Rust called Chalk that uses a Prolog-inspired language because trait bounds basically define a logic:

https://github.com/rust-lang/chalk

Maybe something in the prolog/datalog direction could be useful? Notably Rust has Chalk to help with trait resolution ("Chalk is a library that implements the Rust trait system, based on Prolog-ish logic rules.")

There has been work to implement part of the Rust typing logic in the Chalk Engine which uses a prolog-ish syntax to describe its rules.

That's something Chalk is trying to tackle.

We probably will see all of them at some point -- polonius is a current effort to make the borrow checker accept more valid programs, in a way that also simplifies the logic and is probably a bit faster than the current NLL system, chalk is an attempt to do a similar thing for the trait system, and cranelift is a project that seeks to replace the LLVM codegen backend. But obviously, these are very large and complex projects that are gonna take some time.

Do Rust developers realize that? Oh, yes, absolutely, that's why we have this:

For me an attempt to write where HashMap: FromIterator and then use new and insert was totally bizzare because currently rustc is pretty primitive and doesn't do super-complex machinery needed to do what you want. Chalk may fix that one day, but it's nowhere near to being ready for inclusion into rustc thus I wouldn't even attempt to do what you tried to do… but that's not something you are supposed to know before reading this book!

Useful context on the Rust side is this issue [1]. It sounds like some of the author's concerns are addressed already.

[1]: https://github.com/rust-lang/unsafe-code-guidelines/issues/4...

Is this captured by one of the known soundness conflicts? If not then should consider adding it to the list.

There are some competing proposals for different memory models. Stacked borrows is the current proposal, but there are more work in the approproate WG.

Thank you /u/RalfJung for bringing formal methods to Rust, both through models like Stacked Borrows, by developing miri, and by working on unsafe-code-guidelines which aims to specify exactly what is and isn't allowed in unsafe code (surprisingly, it's an open question as 2023!)

You could imagine some way to make this safe for example automatically convert &'short &'long mut T to &'short &'short T, but it's non-trivial to prove they are safe at all, not to mention ensuring this is correctly implemented in the compiler. If you're interested there's also a discussion on whether the opposite (& & T to & &mut T) is sound here.

Agreed! MIRI is so good, it still feels like magic to me. It also comforts me that the Rust team takes improving unsafe semantics seriously, with the past Unsafe Code Guidelines WG and today's operational semantics team (t-opsem).

I think there are some aspects of this rule that are still undecided. See for example:

- https://github.com/rust-lang/unsafe-code-guidelines/issues/8...

- https://github.com/rust-lang/miri/issues/2732

C is much better specified than unsafe Rust. Some things are just not worked out yet in Rust. This may sometimes even bite very experienced devs, such as this issue with Box's aliasing semantics, which tripped up the author of left-right.