The Most Common Rust Compiler Errors as Encountered in RustRover: Part 2

Vitaly Bragilevsky

Read this post in other languages:

• Français
,
• 日本語
,
• 한국어
,
• 简体中文

In Part 1 of this blog series, we dug into our list of the top 10 most common Rust compiler errors according to RustRover’s usage data, and we made it halfway through the list. In this part, we’ll explore the top five most frequently occurring errors and then make some more general observations regarding the aspects of the Rust programming language that have the biggest tendency to put developers “at odds” with the compiler.

Common error #5: E0433 (An undeclared crate, module, or type was used)

This error is similar to E0432 (An import was unresolved), which we discussed in the previous part. The only difference is that a path with a problematic component is used directly in a name, without the use clause. 17.5% of RustRover users encountered this error. For example, in the code below, the compiler is unable to figure out what we actually mean (a crate or a module) and complains:

This is an example of why the Rust compiler is widely praised for its error messaging. Even without reading the message, the fix is obvious: verify the names, add the required dependencies to Cargo.toml if needed, or introduce proper imports.

RustRover is also helpful. It can give us a choice of imported names. 

Using code completion while writing code lets us avoid this error altogether. 

Common error #4: E0425 (An unresolved name was used)

Let’s continue exploring the unknown with yet another “unresolved” error. 20.5% of RustRover users have been in a situation where they were using an unresolved name that was syntactically not a crate or module name. Here’s what pops up when this error occurs.:

Of course, when this happens to you, chances are it won’t be as clear-cut as in the image above.

Sadly, even the glorious Rust compiler can’t help much with this error. There are a few approaches you can take: revise the name, provide a definition, or introduce proper imports.

Common error #3: E0599 (A method is used on a type which doesn’t implement it)

At the risk of spoiling the surprise: it’s nothing but type-checking errors from here on out! That’s right – all three top spots were taken by errors relating to incorrect type usage. The specific error here is that 27.5% of RustRover users tried to call a method on a value of a type that doesn’t implement that method. Let’s look at the following example:

fn main() {
   let numbers: Vec<usize> = vec![4, 11, 15, 12];
   let sum: usize = numbers.sum();
   println!("Answer = {sum}");
}

Seems legit, except there’s no sum method to Vec. Here’s what the error message looks like specifically:

error[E0599]: `Vec<usize>` is not an iterator

The fix in this case is to call an iter method first and then use sum on the resulting iterator. 

By the way, RustRover has a feature that prevents errors like this one. It’s called chained completion. To see the benefits in action, look no further than the following example:

When the completion suggestion is taken,  both iter and sum methods are added to the call chain, fixing the code immediately.

In general, code completion helps you avoid getting an E0599 message. If you’re not seeing a suggestion for the method call you need, the real issue might be an incorrect callee type.

There’s another aspect of this error worth mentioning: in many contexts, you have control over your own type declarations. One option is to call a method first and then ask RustRover to scaffold its implementation by pressing Alt-Enter (⌥Option–Return) and executing the action suggested:

As a result of that action, RustRover generates the method implementation template, taking into account all the context information regarding types:

impl Info {
   pub(crate) fn summary(&self) -> String {
       todo!()
   }
}

Running this code results in a runtime error, but at least the compiler doesn’t complain anymore.

Common error #2: E0308 (Expected type did not match the received type)

Imagine this scenario: You’re using an expression of type A in a context where a value of type B is expected. “Context” here can mean a function’s parameter at a call site, a variable declaration, a control-flow statement/expression, etc. If you’ve dealt with this, then you’re in the same boat as 30% of RustRover users.

Conceptually, we have two choices in this case: tweak a value or tweak the context. Tweaking a value may involve casting a type, referencing/dereferencing, calling a transforming method on it, or replacing it with something else. Tweaking the context is not always possible, but sometimes we can change an expected type to match a received one.

RustRover supports both modes of operating by providing a choice of quick-fixes, for example:

Note the second suggestion in the list: In this case, RustRover has come up with quite a sophisticated transformation of a value that suits the compiler. Following the first suggestion would instead fix the context, namely the function definition. 

Common error #1: E0277 (You tried to use a type which doesn’t implement some trait in a place which expected that trait)

Finally, we’ve reached the summit! The most common Rust compiler error as encountered in RustRover is E0277. 32% of RustRover users have experienced this types-and-traits-themed nightmare for developers. The official explanation does a good job of providing examples and explaining possible fixes, as usual. Let’s focus on RustRover’s behavior instead.

Here’s my favorite RustRover feature dealing with this sort of error: 

The compiler complains as follows:

error[E0277]: `Info` doesn't implement `std::fmt::Display`

Of course, implementing the Display trait is one of the options, and RustRover is happy to scaffold an implementation. But in this case, I’d prefer to apply the first suggestion, which involves two simultaneous steps:

• Deriving an implementation for the Debug trait.
• Changing the format string to invoke the Debug trait’s formatting facilities.

Unfortunately, in many other cases, RustRover isn’t able to discover and highlight this error by itself. As I’ve already mentioned in the previous part, its type-checking functionality is not that powerful yet, but we’re working on it. As the most commonly encountered error message, E0277 is certainly on our radar.

Observing Rust errors in general

Let’s look at the bigger picture. Last week, we asked the X (formerly known as Twitter) community what aspect of the Rust programming language is the primary source of errors in code. Here’s what we got in response:

To compare the community’s answers with what we see from our data, we’ve looked at the top 25 most common Rust compiler errors and roughly categorized them into five different categories:

• Types and traits
• Ownership and lifetimes
• Macros
• Unresolved names or nonexistent elements
• Other

The results are as follows (in ascending order of error code number):

Unfortunately, the data we have doesn’t say much about macros. We are neither able to reliably detect macro-expanding issues nor identify other errors that originated in successfully expanded macros. Maybe this is a sign that we should introduce more fine-grained categorization into the data we collect. 

Ignoring macros, it seems that we have no clear winner among the top 25 common errors, meaning that we love all Rust parts without exception:

• Types and traits – 7 errors
• Ownership and lifetimes – 8 errors
• Unresolved names or nonexistent elements – 7 errors
• Other – 3 errors

Summary

In this part of the series, we’ve looked at the five most common Rust compiler errors as encountered in RustRover. Three of them were related to types and traits, suggesting that this category of errors is somewhat critical to get Rust code right. We’ve concluded by observing more general data regarding the 25 most common errors and realized that other aspects of Rust also contribute to errors we often encounter.

Subscribe to Rust Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!