Discussions around the design and implementation of The Rust Programming Language| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
I'm sure we've all noticed that x.max(4) doesn't behave quite intuitively: at first glance it looks like "x, but no more than 4" when it's in fact the opposite. Same for .min, of course. So what would people think about a function with a little more evocative syntax? x.limit(y..) equal to x.max(y) x.limit(..=y) equal to x.min(y) x.limit(y..=z) equal to x.clamp(y, z) Could also go with range.limit(value), but the point of this function is to make function chains more convenient and intuitive, ...| Rust Internals - Latest posts
I am a newbi, and not sure if this is the place to ask for help. I want a encrypt/decrypt function, fn encrypt(a: &str) -> String fn decrypt(a: &str) -> String I want to use des, or aes ( not even sure what they mean), but it seems really difficult to create such functions, I asked AI, googled libraries, but they all seems supriingly complicated, and I can not make the compiler happy, simply because some type does not exist in some lib even AI said so. Any help with a complete example of encr...| Rust Internals - Latest posts
I've had enough experience with Rust that I rarely get stuck on borrow-checking issues, but there is one mistake I've made a couple of times that has had me confused for a long time before I eventually realized what was going on. The code below fails to compile: struct Wrapper<'a, T> { inner: &'a mut T, } impl<'a, T> Wrapper<'a, T> { fn new(inner: &'a mut T) -> Self { Self { inner } } fn reborrow(&mut self) -> Wrapper<'_, T> { Self { inner: self.inner } } } With an error like: error: lifetime...| Rust Internals - Latest posts
Right now Cargo checks that crate tarballs match the SHA256 in the index, which is good for integrity but doesn’t prove who published a crate. If crates.io or the index itself ever got compromised, Cargo wouldn’t notice as long as the checksum matched. There’s also some fragmentation around SBOMs (software bills of materials). Tools like cargo-auditable or cargo-cyclonedx exist, but there isn’t really a small, shared library that other tools can build on. The headache No way to prove ...| Rust Internals - Latest posts
There's a proposal for this:| Rust Internals - Latest posts
Currently crate releases appear immediately on crates.io. Users who don't have a lockfile get the release immediately. Users with lockfiles get it whenever they decide to update. That's generally good enough, but sometimes I'd like to have more control: As a crate author, sometimes I have bigger releases that could have bugs or compatibility issues. I publish -pre releases, but in practice very few users test them, so I hear about bugs when I make a "stable" release. In popular crates this br...| Rust Internals - Latest posts
There are a lot of proposals, rfcs, discussions, everything is really fragmented. Can we have a tracking issue that will track the progress and collect those (including links to useful threads from internals)?| Rust Internals - Latest posts
build-dependencies right now is quite special in that it neither supports feature gating, not does it treat targets the same way as the rest of the code. Specifically, when I have this in Cargo.toml: [target.'cfg(target_arch = "xyz")'.build-dependencies] It doesn't mean the crate is being compiled for xyz target, rather it means the build script will. And without support for features, there doesn't seem to be any way to include a dependency only when the crate is compiled for a specific targe...| Rust Internals - Latest posts
I don't think this is every something that would be appropriate for the main website to say. It's like how auditory crossing signals say "walk sign is on" not "safe to cross". (Other discoverability frontends being more opinionated is good, though, so there can be different ones with different metrics and they can all compete.) Big fan of showing other metrics that can help people spot something they do or don't want to trust, though. Things like "first uploaded recently" can help people go "...| Rust Internals - Latest posts
I can see the overlap, and yet at the same time... Logical Unit There's a strong argument for bundling library code with its benchmark, examples & tests. Logically speaking, this is a single logical unit, and the benchmarks, examples, & tests are "satellites" of the library. This single logical unit happens to be called a crate. Work Unit Similarly, after making changes on a library, it's quite natural to first ensure that the changes on this library are sound (in isolation) by running the te...| Rust Internals - Latest posts
I replied on the LLVM thread which I'll quote here: I think it would be great to have first-class support for something like this in LLVM. It has become commonplace for new cryptographic specifications to use a pseudocode “CMOV”-like function to describe where to apply this sort of predication. Achieving this sort of constant-time predication is something we currently implement today in RustCrypto in the cmov crate, which uses asm! to avoid e.g. LLVM rewriting CMOV* instructions as branch...| Rust Internals - Latest posts
struct Foo {} impl Foo { fn to_bar(&self, maybe: bool) -> Option> { maybe.then(|| Box::new(0usize)) } } impl Bar for usize {} trait Bar {} This is the kind of thing that I'd usually expect to work, but it fails: rror[E0308]: mismatched types --> src/lib.rs:5:9 | 4 | fn to_bar(&self, maybe: bool) -> Option> { | -------------------- expected `Option>` because of return type 5 | ...| Rust Internals
I was reading a topic on main forum, when I realised that neither Drain types in std nor drain functions that return them are marked as #[must_use]. This makes following code compile without warnings: fn main() { let mut s = "hi there".to_owned(); s.drain(2..6); println!("{s}"); } I'm quite surprised by this. It is of course perfectly fine to drop Drain type. Unless it is forgotten there is no memory leak, so the only consequence of dropping it is that drained items are dropped as ...| Rust Internals
(Most recent version on GitHub) Feature Name: abi_aarch64_indirect_return Start Date: 2025-08-24 RFC PR: rust-lang/rfcs#0000 Rust Issue: rust-lang/rust#0000 Summary Introduce a new target-specific calling convention aarch64-indirect-return, which will pass the first argument as if it was an indirect result location pointer (that is, through the x8 register). This would make it possible for Rust to interoperate with C++ functions that return non-trivial C++ objects on aarch64. Motivation Cur...| Rust Internals
there's a lot of arguments for and against this, but i think a lot of these don't matter, because many crates are already shipping prebuilt artifacts. ideally this could also be integrated with some sort of deterministic build system. the simplest implementation would be a per-crate (not per package) table that maps a target triple and a rust version (may be ignored for crates with a stable ABI or ones that are cli-only) to a hash and url for that crate's output. may need another layer of nes...| Rust Internals
The full proposal document is in our tag-std repository. It's too long to read in this post, considering there are more conversations going on. We are experimenting this feature on verify-rust-std, Rust for Linux, and Asterinas OS. Any idea and feedback is welcome! ❤ Summary This RFC proposes a DSL (domain-specific language)-based mechanism for specifying safety properties, aiming to standardize how safety descriptions are written in API documentation. On the one hand, it seeks to...| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
I’ve been posting a bunch of blog posts on dyn async in traits. I just realized I never made an internals thread to discuss them! Fixed. Part 1 Part 2 Part 3 Part 4 Part 5| Rust Internals
In my last post, I talked about the new “pinned references” which guarantee that the data at the memory it points to will not, ever, be moved elsewhere. I explained how they enable giving a safe API to code that could previously only be exposed with unsafe, and how one could go about proving such a thing. This post is about another application of pinned references—another API whose safety relies on the pinning guarantees: Intrusive collections. It turns out that pinned references can al...| Rust Internals
Recently, a new API for “pinned references” has landed as a new unstable feature in the standard library. The purpose of these references is to express that the data at the memory it points to will not, ever, be moved elsewhere. Others have written about why this is important in the context of async IO. The purpose of this post is to take a closer, more formal look at that API: We are going to take a stab at extending the RustBelt model of types with support for pinning. https://www.ralfj...| Rust Internals
RFC 2349 proposing a new set of APIs to deal with types that cannot be safely moved around - especially generators and async functions. You can read more details of the design in the RFC. This thread is a sidebar to discuss the names of these types. The names proposed in the RFC were arrived at ‘evolutionarily’ as several different previous APIs converged into the present one. So they’re not necessarily very good. The relationship between the three items (review of the RFC) The trait Mo...| Rust Internals
Secretly and behind the scenes more and more Rust code lives a life before main. What is life before main? It's code that executes before the rust runtime has been initialized in main. This is something that Rust does not support but because the world needs to support C++ static initializers and __attribute__((constructor)) in C, it's also possible to get Rust code to execute this way. The popular crate for this is ctor. Using it is probably not a great idea, but unfortunately there are lots ...| Rust Internals