[tutorial] [cpu exceptions] code from the listing fails to compile

[dodikk]

Got a compiler error while trying out the code from listing.

error: use of deprecated item 'x86_64::structures::idt::Idt': type was renamed to `InterruptDescriptorTable`, the old name will removed in the next major version
  --> src/main.rs:56:31
   |
56 | use x86_64::structures::idt::{Idt, ExceptionStackFrame};
   |                               ^^^

The error is obvious to fix.
Still, it would be a better experience to have correct listings out of box.

P.S. My code has the x86_64 = "0.2.6" dependency as recommended in the previous articles.

Commented on the blog site :
#450 (comment)

[dodikk]

The question is why it's an error for you. Are you explicitly using deny(warnings) or something like that?

That's right. I've enforced that as I got inspired by your "testing" section.

The stricter compilation - the safer code.

Sorry for not checking if it was actually a "true error".

[dodikk]

Yeah, we released a new x86_64 version with this renaming a few days ago. I thought it's better to wait a bit before updating the post to avoid breakage for the users on older versions.

Not sure why cargo has picked up a more recent version for me.
Here is what I've specified in my Carho.toml

x86_64 = "0.2.6"

Any chance that some articles rely on a newer version of x86_64 than they actually should?
Meaning, "CPU Exceptions" chapter requires an older dependency than some other parts of the blog do.

[phil-opp]

Cargo considers versions that only differ in the last component of the version number as compatible to each other. To ensure that you always have the latest bugfixes, cargo automatically uses the latest compatible version when you add a dependency. So even though you chose version 0.2.6, cargo choses version 0.2.7 because they should be compatible.

This is only done for new dependencies, existing dependencies are locked down in the Cargo.lock file to ensure reproducible builds. They can be updated to the latest compatible version through cargo update. See the dependencies section of the cargo book for more information.

The question is now: What is considered compatible and what is not? The convention used by the Rust project and most libraries is that new warnings are allowed between compatible versions. So in this case everything was done correctly, because the deprecation of the old name only leads to a new warning. I didn't update the post yet because people that already implemented the previous posts are locked to version 0.2.6 (through the Cargo.lock), so using the new name would cause an error for them (because the new name does not exist in the old version). Therefore I decided to wait a bit before updating the posts to minimize breakage.

By using deny(warnings) you decided that your project should not allow warnings, which is a valid choice. However you must expect that newer versions might break your build then, so that you have to fix each warning immediately. (For this reason the usage of deny(warnings) is discouraged for libraries, because it might break your downstream users without reason.)

TLDR: Using deny(warnings) requires you to fix all warnings immediately, but introducing new warnings across compatible crate versions is allowed and cargo automatically chooses the latest compatible version. I will update the post to the new name soon, but for now we keep the warning to avoid breaking users of version 0.2.6. I hope this answers your questions!

[dodikk]

I hope this answers your questions!

It truly does.
Thanks a lot for explaining.