⊕ This post is the first part in a planned series on linking Rust crates. My desire is to get informal feedback on these posts, and then turn it into more structured content suitable for the Rust reference, or maybe the Rustonomicon (or a book on its own.) Working on the Rust compiler, one topic that I come across from time to time is “what is supposed to happen when we use these particular features of my tools?” More specifically, Rust has various metaphorical knobs that allow fine-grained control of the object code generated by the compiler, several of which are related to the process of linking that code to other object code.

From Linkage chapter of the Rust Reference, we can see there are seven kinds of crates: bin, lib, dylib, staticlib, cdylib, rlib, and proc-macro.

⊕ I had originally intended to cover all seven, but the time got late and the post got long and I decided that proc-macro can be dealt with another day.

What this post is going to do is walk through the first six of the crate types listed above and demonstrate: how to build an example of such a crate, how to link to it, and how to run with that linked crate.

This is just a post where I’ll either be happy or sad, depending on whether Github pages manages to render the same content the way that I see it on my local system.

There is an adage in the business world that goes something like this:

⊕ This quote is attributed to Theodore Levitt, but there is significant evidence that the adage predated his use of it.

People don’t want to buy a quarter-inch drill, they want a quarter-inch hole.

It is a good line.

⊕ Some people I talk to make the leap from safety to another property: security. The two topics are related, since safety issues can sometimes be exploited and thus yield security issues. But you can theoretically achieve security atop an unsafe language; and safety alone does not ensure security. So it is a messy relationship at best.

The adage came to my mind recently in a discussion of Rust’s selling points. An oft-cited selling point, at least for a Programming Language enthusiast like myself, is that Rust offers safety.

I have been thinking about the Rust debugging experience, and I want to try tease apart what value a debugger provides to me.

This is part three in a series about the TurboWish performance analysis tool suite. In part one I described why our team selected this as a focus, and the goals for the tools. In part two I presented four narratives, each representing different idealized future customer experiences using the tools.

Now I want to show you the design document I developed, which digs more into how I thinkI cannot emphasize enough that nothing here is set in stone. These are ideas I am circulating with you precisely so that you can tell me what needs to change. the system should be architected.

It’s story-time!

As I walk, I think about a new way to walk

In my previous post, I described the observations that led us to select performance tooling as a focus, as well as the goals document I wrote to guide the next steps of the project. Now I want to show you the User Stories I wrote, to show what I think our customers want (and can reasonably expect) out of performance tools.

This is a post about some recent history. I want to tell the world about a project I am leading at Amazon Web Services, called “TurboWish.”

TurboWish, in a nutshell, is our umbrella term for a planned suite of tools for understanding your Rust program’s dynamic behavior. We want the tools to especially focus on providing insights into the performance characteristics of your program.

The problem

Driving deallocation of state via ref-counting under our current atomic API means that you cannot avoid having a &AtomicUsize variable at the same time that you are deallocating the block of memory that contains the referenced atomic usize state.

The proposal

The idea is simple.

Experienced Rustaceans know that in the general case, &T doesn’t actually mean immutable; it merely signals that unsynchronized mutation through aliases is disallowed. Interior mutability is still an option, via Cell or AtomicUsize.

All such sources of interior mutability are tracked in the type system. Namely, they all have an UnsafeCell<U> somewhere in the structure layout that tells the compiler that such mutation is permitted on the U inside the unsafe cell. Thus the compiler knows it cannot make optimizations that rely on that U remaining invariant.

So, here’s the suggested change: if code needs to allow for concurrent actors (or even aliasing accesses on the current thread) to mutate some state, that same code must allow that those accesses might deallocate that state.

⊕ This was originally a github comment that, due to my writing style (and desire to teach), spun a bit out of control (or at least, didn’t match the overall style we try to follow for comments on rust-lang/rust repository).

⊕ So now, this is a blog post instead, where I get to do fun things like have better control over formatting and whatnot. (Based on what feedback I get on the post, maybe I will next work to promote it to a chapter in the rustc dev guide.)

Issue #81658, “Invalid `field is never read: ` lint warning”, is a bug filed against rustc.

These are mentorship instructions for how to go about fixing the bug. They are also an overview of some steps I use to get started looking at a bug like this.

⊕ Update 19 November 2019: fixed miscellaneous typos and a bug in the invariance example pointed out by readers both privately and on reddit thread. I also added a section near the beginning to draw attention to techniques that are somewhat Rust-specific and may not be broadly known.

Hey there again!

I have been pretty busy with Rust compiler tasks, so no there has not been a blog post for a few months. But now, here we are!

While I was working some particularly nasty bugs recently, I put a lot of effort into bug minimization: the process of taking a large test case and finding ways to remove code from the test while preserving the test’s ability to expose the same bug.

As I worked, I realized that I was following a somewhat mechanical process. I was using regular patterns for code transformation. At some point, I said “you know, I’m not sure if everyone is aware of these patterns. I only remember some of them while I am in the middle of a bug minimization session.”

Since the Rust compiler team always wants to help newcomers learn ways they can contribute to the project, I realized this could be the ideal subject for a blog post.

And, to try to keep things concrete, I’m going to try to drive the presentation by showing an actual bug being minimized. (Or rather, I’m going to recreate the minimization that I already did. So if it seems like I am rather conveniently picking transformations that always seem to work: You’re right! I’m cheating and not telling you about all the false paths I went down during my first minimization odyssey on this bug.