Rust 1.27.0 is out!


#1

See the blog post for more information: https://blog.rust-lang.org/2018/06/21/Rust-1.27.html.


#2

I just tried 1.27 on two current projects.
Both compile and pass all the same unit tests as before.
However, there are now quite a few warnings where there were none before.

On the Linux project I had several warnings like this:

warning: lint unused_doc_comment has been renamed to unused_doc_comments
  --> src/main.rs:14:5
   |
14 | /     error_chain!{
15 | |         foreign_links {
16 | |             Io(::std::io::Error);
17 | |             Regex(::regex::Error);
18 | |         }
19 | |     }
   | |_____^
   |
   = note: #[warn(renamed_and_removed_lints)] on by default
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

And on several Windows projects I had similar looking warnings (but lots of them because of a bigger code base):

warning: lint unused_doc_comment has been renamed to unused_doc_comments
  --> common\src\lib.rs:12:5
   |
12 | /     error_chain!{
13 | |         foreign_links {
14 | |             Int(::std::num::ParseIntError);
15 | |             Real(::std::num::ParseFloatError);
16 | |         }
17 | |     }
   | |_____^
   |
   = note: #[warn(renamed_and_removed_lints)] on by default
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

So, I thought I’d mention it since it is a change which I hadn’t expected.


#3

I’m personally a bit sad that yet another “match ergonomics” soundness bug slipped through :frowning:. I understand things like this happen, but this goes back to “for what” - that feature doesn’t carry its weight, especially with the unsoundness tail it’s wagging. Maybe this will be a good “lesson” for how to evaluate such class of features in the future.

Ok, sorry for the small rant :slight_smile:.


#4

From what I understand, all of the bugs we’ve found in match ergonomics don’t exist on MIR borrowck. I believe that we intend to add more checks/tests soon to hopefully find all/most of the problems we can before 1.27.1 which is likely to happen early next week.


#5

Yes, that is a known problem with error-chain, which needs to be updated. I don’t recall if the crate needs to be published though or if the necessary fix has been landed in its master.


#6

Mark, bugs will happen - I’m not really sad about that, per say. But having back to back releases with soundness bugs, of all things, related to a feature that has questionable value (I fully realize this is subjective, so just my $.02) is the sad part. I don’t think it really matters whether the bugs were due to legacy vs MIR borrowck - there’s always some reason for any bug.


#7

To be clear, the soundness bugs discovered with the bindings were not introduced during the 1.27 development cycle; these existed at implementation time. I think though we largely agree – this is unfortunate, but unavoidable. It has little to do with the match ergonomics feature specifically, rather, it received less testing than was likely warranted.


#8

Do you have a link for that? I haven’t seen anything about it.


#9

It’s mentioned at the beginning of the release notes for 1.27. But it’s this:


#10

Yes, but it seems that this bug was from 1.26.x and was not discovered until late in the 1.27 release. It seems like this bug is not a new bug introduced by 1.27, but, a bug introduced by 1.26 that was only just discovered. I wouldn’t think it is fair to characterize it as two releases with new bugs for Match Ergonomics. Just my $0.02. That being said, I agree with your point that something that is just for Ergonomics, and isn’t really extending the capabilities, needs to have much stricter testing and a higher bar for acceptance.

Also, I don’t think it is reasonable to expect there to never be soundness bugs in the compiler. What is reasonable to expect is that the theoretical basis for the compiler is sound and that any bugs that are discovered are corrected as soon as possible and that nothing is covered up. I think Rust is doing great at that. It’s also reasonable to expect that every reasonable engineering effort is made to avoid soundness bugs.

Do you have any ideas as to a process change that may have helped to uncover these bugs before they were released? What could’ve been done differently?


#11

Yeah, I understand - that’s why I’m referring to it as a bug tail.

Well, the unsoundness bugs are all related to the feature, aren’t they? Meaning, using the feature opens the user up to potentially hitting unsoundness. If the bugs were lurking in old borrowck but not exposed in any way, then in some sense it’s as good as them not existing (particularly since the old borrowck is being phased out).

To reiterate, my point is that this feature wasn’t worth it. Sure, nobody knew this a priori. But this risk is always there when changing code. As such, I hope this risk can be weighed in the future, as an additional consideration during proposed feature evaluation. Needless to say, it’s not a good look for Rust when 2 stable releases in a row have soundness holes (again, regardless of when the initial problem occurred). Now someone can ask the reasonable question of: how long is this tail? Are we going to uncover another one?

Ok sorry, that’s my last rant-y comment (modulo replying to anything).


#12

Yeah, I think I clarified what I meant in my previous reply. Consider the optics of this from a casual Rust observer (e.g. your manager at work to whom you’re pitching Rust). 1.26 comes out - 2 point releases, unsoundness in a lang feature. 1.27 comes out, another instance of unsoundness. The fact it’s lingering from something introduced in 1.26 is a technical detail. Then you consider that the feature in question is intended to improve ergonomics and beginner-friendliness, yet beginners are the ones most likely to inadvertently write something that will trip over this. Then you consider that this feature’s utility was fairly highly contested in the first place.

That’s essentially the thrust of my point. I’m hoping this will serve as a concrete example to strengthen that thinking. That’s not to say the core team (and the rest of the community, for that matter) doesn’t already think hard about these things. But, we have a couple of real examples to look at now and learn some lessons.

By the way, to be super clear, I’m not suggesting to not touch code at all. But as we all know, from our own experience, touching code always risks bugs. So we mentally weigh the cost/benefit of this. The scrutiny is also elevated if you’re touching something that you already know is brittle, or at the core of your system, where the cost of a bug will be more severe. So proposed changes go through this triaging exercise, and they aren’t all measured by the same stick.

Certainly, and I agree with all of that, including Rust doing a great job on this front. But, I’ll tell you why I personally find this case particularly troublesome.

We’re all told (and rely on) to “trust the compiler” - it will fail to compile unsound code. Bugs happen, yes. But, here’s where things get “interesting” - in canonical Rust code, it’s very hard to mentally parse all the involved types and their interactions/coercions/etc due to heavy type inference usage. So you’re doing a code review. You’ll almost certainly assume that if it compiles, and there’s no unsafe code, then it’s sound. This is where Rust is somewhat unique; if you’re looking at, say, C++ code, you’re likely not going to sleep on it because you know the compiler ain’t doing much to detect soundness problems. C++ also doesn’t have the type inference engine that Rust does, nor do people use unascribed types as much.

So I feel that rustc has the extra burden of being airtight. Yes, bugs will happen. It just sucks to waste the “bug budget” on things like match ergonomics.


#13

I’ve added an issue for the error chain crate: error-chain issue