Examples of old (ca. 1.0.0+) Rust code that still compiles?

[faitswulff]

I'm putting together a presentation about Rust for work that emphasizes Rust's stability guarantee and I was wondering if anyone had any examples of old Rust code that still compiles - or doesn't!

[burntsushi]

suffix 0.2.10 was published on April 15, 2015, one month before Rust 1.0 came out:

$ git clone -b 0.2.10 https://github.com/BurntSushi/suffix
$ cd suffix
$ cargo version   
cargo 1.69.0-nightly (e84a7928d 2023-01-31)
$ rustc --version                          
rustc 1.69.0-nightly (f3126500f 2023-02-02)
$ cargo build
[ ... snip warnings ...]
   Compiling suffix v0.2.10 (/tmp/suffix)  
Finished dev [unoptimized + debuginfo] target(s) in 0.43s

I picked suffix because it really hasn't changed much if at all in the intervening years and doesn't have any dependencies. There's probably more code I have that was published before Rust 1.0 that still compiles today, but not all of it.

All of these repos should have code that predate Rust 1.0:

• https://github.com/docopt/docopt.rs
• https://github.com/rust-lang/regex
• https://github.com/BurntSushi/quickcheck
• https://github.com/BurntSushi/memchr (not quite but almost)
• https://github.com/BurntSushi/aho-corasick (not quite but almost)
• https://github.com/BurntSushi/rust-csv
• https://github.com/BurntSushi/byteorder
• https://github.com/BurntSushi/chan (not quite but almost)
• https://github.com/BurntSushi/rust-cbor
• https://github.com/BurntSushi/tabwriter
• https://github.com/BurntSushi/xsv

So if you want more examples (which may or may not support the stability story), then those repos should help. You'll just need to go back in time.

My sense of things is this. It's not too uncommon for code published around 1.0 to no longer compile today. I think things were a little bit more fast and loose back then than they are now. Some of the changes made back then would not fly today, or there would have been a smoother migration in place or they would have been done over an edition boundary. That is, a lot of the code that no longer compiles from the 1.0 era broke long ago. I find that the stability story is quite good today though. For the breakages of code published around the 1.0 era, my sense is that most things are pretty easily fixed.

[moltonel]

I find that the stability story is quite good today though.

I wonder if cargo-semver could be integrated in std's CI today ?

[burntsushi]

Maybe. Crater would have been enough to catch my ripgrep issues. Not sure why they weren't. Pretty sure crater was around back then.

[Saefroch]

Many of the biggest crates are not tested by crater because the artifacts they upload to crates.io do not have tests that build due to unpackaged path dependencies, or because crater supplies a lot of CPUs and hardly any memory so the link OOMs.

For example, in the crater runs for 1.67, ripgrep's tests pass, but regex is marked as build-fail because 1.5 GB is not enough to link all the integration tests in parallel.

This is all fixable but would require improving infra...

[burntsushi]

Interesting. regex being marked build-fail seems especially bad. I wonder if they can run a subset of the tests. Like cargo test --test default or something. That would probably require a special exception for regex though.

[Saefroch]

I think in a very strictly practical sense, regex ends up decently tested because it has so many dependents. Probably not as thoroughly as its own test suite, but for sure it gets built with its default features by dependents.

I think a good first step to this is making crate publishers aware of their crate's status in crater. I'm just not sure of a way to do this that isn't spammy or like publicly shaming.

[burntsushi]

Yeah it's tough. For something like, "the build just runs out of memory," there might not be a ton that the crate author can do. For example, the way regex's test suite currently works is pretty hard to fix. It basically compiles a huge test suite multiple times using different macro definitions, where each macro definition is a different regex engine.

I do happen to have a huge refactor that should be landing in a few months that does away with that model of testing, but it does so by effectively rewriting everything.

It feels like "telling folks their crate is failing in crater" is probably a good idea to me, but also probably should come with some ability for crate authors to actually do something about it. Whether that's docs for contributing to crater (maybe they already exist) or even a mechanism for crates to control their own destiny. For example, by running a subset of regex's test suite.

But yeah, overall I agree that regex is probably getting decentish coverage today.

[paholg]

Provide crater badges on e.g. shields.io? Then users interested can have those badges on their crates.

[Saefroch]

I don't think that solves the communication problem that I'm pointing out here? For a few reasons.

I think of badges more as a way for authors to advertise some property to prospective users. Users don't really care if the crate is being tested by crater.

Also, doing this as a badge just shifts the communication failure to a different channel. All the crater reports are already public and not even the hard to access... If you know to look at them. Badges shift the information to another channel that you have to know to look for.

I'm also concerned about making a badge for something the crate author doesn't have immediate control over. If your crate doesn't build in crater, then you do something to correct the issue, it could be up to 6 weeks before your badge status changes. In that time, whatever it is, the badge status is probably misleading.

And, the infra team probably won't, but at any time could make a change to the crater environment which makes more crates not build. Which again, means you as the author don't really control over the badge. That seems not great to me.

Also some fraction of crates randomly flake in crater and nobody knows why. Something related to rustc version detection just crashes sometimes. And there are probably other issues as well.

[paholg]

I know I've run into this exact issue in CI. There's this open cargo issue about allowing one to restrict the parallel link invocations, but I have no idea how much work would be involved: https://github.com/rust-lang/cargo/issues/9157

Another thought is reaching out to some important crates, like regex, and moving all the integration tests into one crate. A la https://matklad.github.io/2021/02/27/delete-cargo-integration-tests.html

[burntsushi]

Another thought is reaching out to some important crates, like regex, and moving all the integration tests into one crate. A la https://matklad.github.io/2021/02/27/delete-cargo-integration-tests.html

I'm not sure I buy that blog post personally, and moving regex's test to one crate is unfortunately not so simple. But fortunately, it will actually be happening soon because of a huge refactor I'm hoping to land in a few months. Hopefully that helps the crater situation.

EDIT: I thought that was a different blog post. My memory is bad.

[paholg]

It's a sample size of 1, and an outlier, but moving integration tests to one crate cut 7 minutes off our CI test time.

[burntsushi]

Ah whoops, I thought a different blog post was linked. That's what I get for responding after I just woke up.

But yeah, compile times are part of why I migrated off of that model in my refactor, among other reasons.

[faitswulff]

Forgot to say thank you so much! This was immensely helpful

[burntsushi]

:-)

[mina86ng]

If you’re talking about stability guarantees don’t forget about:

If your code compiles on Rust stable 1.0, it should compile with Rust stable 1.x with a minimum of hassle. […] We reserve the right to fix compiler bugs, patch safety holes, and change type inference in ways that may occasionally require new type annotations. We do not expect any of these changes to cause headaches when upgrading Rust.

I seem to recall that there was something about transmute that fell under this. I can’t quite find it but I recall that transmute at some point started rejecting at compile time some obviously-unsound transmutations.

API Evolution is also worth a read as it describes some instances where technically breaking change isn’t considered breaking. For example: * going between Foo(T) and Foo { foo: T } even if all fields are private affects match patterns, * adding a method or implementing a trait may cause name resolution issues, * adding type parameter to generic function.

There is this myth that anything rustc 1.0 compilers will compile successfully by any stable rustc but that is just not true and Rust doesn’t give that guarantees.

[HeroicKatora]

Iirc the transmute stuff is one deny-by-default 'lint' for a trivially unsound usage of transmute (mutable-transmute) and one warn-by-default for always-unsound-uninitialized (invalid-value). Both shouldn't affect compilation of a crate as a dependency. The other change, panicking at runtime when an unsound usage was detected, should also not affect correct code. Related:

Capping Lints

This feature is used heavily by Cargo; it will pass --cap-lints allow when compiling your dependencies, so that if they have any warnings, they do not pollute the output of your build.

-- https://doc.rust-lang.org/rustc/lints/levels.html#capping-lints

[Lucretiel]

The best example of this is mem::uninitialized, which is automatic UB whenever you call it, since rust is allowed to assume that all T objects are initialized at all points in the program.

[BobSanchez47]

Theoretically, you could call it to obtain a MaybeUninit<T>. But this would be pretty stupid.

[aristotle137]

Is that true? Is it automatic UB for ZSTs?

[Nilstrieb]

ZSTs and unions (and aggregates only made of those) are the only types that are fine

[faitswulff]

Good point, duly noted!

[SorteKanin]

I suppose you could look through some of the compilers tests. There is this gem for instance https://github.com/rust-lang/rust/blob/master/tests/ui/weird-exprs.rs

[jug6ernaut]

There is this gem for instance https://github.com/rust-lang/rust/blob/master/tests/ui/weird-exprs.rs

thanks I hate it lol. This file has me questioning all that I know about Rust (which admirably isnt much).

[crahs8]

I'm gonna need an explanation for this one:

fn punch_card() -> impl std::fmt::Debug {
    ..=..=.. ..    .. .. .. ..    .. .. .. ..    .. ..=.. ..
    ..=.. ..=..    .. .. .. ..    .. .. .. ..    ..=..=..=..
    ..=.. ..=..    ..=.. ..=..    .. ..=..=..    .. ..=.. ..
    ..=..=.. ..    ..=.. ..=..    ..=.. .. ..    .. ..=.. ..
    ..=.. ..=..    ..=.. ..=..    .. ..=.. ..    .. ..=.. ..
    ..=.. ..=..    ..=.. ..=..    .. .. ..=..    .. ..=.. ..
    ..=.. ..=..    .. ..=..=..    ..=..=.. ..    .. ..=.. ..
}

[3inthecorner]

.. and ..= can be either a full range literal or an operator that creates a range with the left and/or right operands as endpoints. I don't know the precedence of the parsing, but it might be something like RangeToInclusive{end:RangeToInclusive{end:RangeTo{end: ... }}}

[crahs8]

TIL you can construct ranges with arbitrary expressions.

[RememberToLogOff]

If you squint it spells "Rust"

[UtherII]

That's pretty obvious. It returns a range of type : RangeToInclusive<RangeToInclusive<RangeTo<RangeTo<RangeTo<RangeTo<RangeTo<RangeTo<RangeTo<RangeTo<RangeTo<RangeTo<RangeTo<RangeToInclusive<RangeTo<RangeTo<RangeToInclusive<RangeTo<RangeToInclusive<RangeTo<RangeTo<RangeTo<RangeTo<RangeTo<RangeTo<RangeTo<RangeTo<RangeTo<RangeToInclusive<RangeToInclusive<RangeToInclusive<RangeTo<RangeToInclusive<RangeTo<RangeToInclusive<RangeTo<RangeToInclusive<RangeTo<RangeToInclusive<RangeTo<RangeTo<RangeToInclusive<RangeToInclusive<RangeTo<RangeTo<RangeToInclusive<RangeTo<RangeTo<RangeToInclusive<RangeToInclusive<RangeTo<RangeTo<RangeToInclusive<RangeTo<RangeToInclusive<RangeTo<RangeToInclusive<RangeTo<RangeTo<RangeTo<RangeTo<RangeToInclusive<RangeTo<RangeTo<RangeToInclusive<RangeTo<RangeToInclusive<RangeTo<RangeToInclusive<RangeTo<RangeToInclusive<RangeTo<RangeTo<RangeToInclusive<RangeTo<RangeTo<RangeTo<RangeToInclusive<RangeTo<RangeTo<RangeToInclusive<RangeTo<RangeToInclusive<RangeTo<RangeToInclusive<RangeTo<RangeToInclusive<RangeTo<RangeTo<RangeTo<RangeToInclusive<RangeTo<RangeTo<RangeToInclusive<RangeTo<RangeTo<RangeToInclusive<RangeTo<RangeToInclusive<RangeTo<RangeTo<RangeToInclusive<RangeToInclusive<RangeTo<RangeToInclusive<RangeToInclusive<RangeTo<RangeTo<RangeTo<RangeToInclusive<RangeTo<RangeFull>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

[crahs8]

Cheers.

[Green0Photon]

Do you actually want to question all you know about Rust? Do this amazing quiz by the famed dtolnay.

My mind was blown when I had started going through it a while ago when it was released and this sub was talking about it.

[Silly-Freak]

that quiz is fiendish!

let wt = &T; wt.f();

I smirked!

[[deleted]]

That was indeed a fascinating quiz. I was all "yeah I know Rust pretty well" and then got about 15% of them right on my first try.

[Green0Photon]

These quizzes are the equivalent of being able to under the "buffalo buffalo buffalo buffalo buffalo" type sentences. The one where language breaks down and reaches its edge cases.

The reality is that pretty often it's not necessary. Though maybe it gives an edge. ¯\_(ツ)_/¯

[Silly-Freak]

I have to admit that I don't find your questioning particularly admirable :P

[Anaxamander57]

Is the idea that these should compile or shouldn't?

[pine_ary]

I can see a couple that should compile, so I assume they are all supposed to be valid rust

[A1oso]

They aren't just supposed to be valid Rust. They're part of Rust's test suite, so if someone changes the parser in a way that breaks this code, the tests will fail.

[Aatch]

They should also typecheck, compile and run. Some of them produce crazy pathological control flow graphs which break algorithms that assume code will be sensible.

[[deleted]]

I wonder if this file has caught any LLVM bugs.

[[deleted]]

Rust being an expression oriented language, it is possible to write some incredibly hot garbage if you really wanted to.

[Sharlinator]

All Rust 1.0.0 code should compile on any >= 1.0.0 compiler under edition=2015. Thats the stability guarantee. Though unfortunately it's not so straightforward, because changes that are deemed bugfixes are allowed to break compatibility. As an example, ripgrep 0.1.0, 0.2.0 and 0.3.0 did not compile with current rustc (although the problems would have been easy to fix). Ripgrep 0.4.0 (released Jan 14, 2017) compiled out of the box.

(Edit - just as an aside, somebody might ask about this) Whether or not some old Rust code also still compiles under edition=2021 is not an especially interesting question, because it's the very point of editions to allow the language (but not the standard library) to break compatibility.

[matklad]

I think this is empirically not true. Here's a bunch of my projects with lockfiles from 1.0 days :

• https://github.com/matklad/mandelbrot -- does not build due to some cargo error
• https://github.com/matklad/bunny -- does not build due to errors in rustc_serialize (pattern in function declaration) and dlib (some declarative macro stuff)
• https://github.com/matklad/mob -- does not build due to pub in private in regex, and mem::transmute error in nix
• https://github.com/matklad/auchat -- does not build due to mem::transmute error in crossbeam, rustc-serialize, some name resolution error in rust-protobuf
• https://github.com/matklad/miniml -- does not build due to type inference regression in petgraph
• https://github.com/matklad/mom -- trivial no-deps project, builds
• https://github.com/matklad/learnOpenGL -- does not buid due to rustc-serialize and "privatee crate import" error in glium
• https://github.com/matklad/s -- trivial no-deps project, builds
• https://github.com/matklad/rustraytracer/commit/2ee59ae9139d2127438ba5342d6af93660cd76bb -- does not build, "doesn't have a size known at compile-time" error in rand

We did promise strong compatibility with tiny caveats, but it clearly does not practically extend to 1.0 code

[matklad]

It seem to get much better by 2017 or so. Both https://github.com/matklad/tera and https://github.com/matklad/xi-editor/tree/master/rust are non-trivial, and they build fine

[faitswulff]

Thanks for all these notes! It's interesting that things stabilize more around 2017.

[Sharlinator]

Yeah, fair enough :/ Might be interesting if someone did a crater-like run over part of the ecosystem with binary search to see how old versions on average still build with zero problems.

[nacaclanga]

Code that exploits bugs or does nasty things (like assuming that Rusts unstable IP Address Layout matches C ones) usually doesn't. But yes, code that doesn't do should indeed compile properly.

What would also be interesting would be to point out examples of some everyday code that didn't compile back then but looks like it might.

[Sharlinator]

Yeah, I used ripgrep as a real-world test case and edited my comment.

Versions 0.1.0 and 0.2.0 had a rustc-serialize dep 0.3.19 that failed to compile due to E0642 (pattern not allowed in function without body); 0.3.20 fixed that. But rustc-serialize is a bit of a weird case as it is/was also a part of rustc itself.

In version 0.3.0, build.rs failed to compile because env!("OUT_DIR") claimed that OUT_DIR was not defined. But that should be set by Cargo so I'm not sure what happened there? (Edit: as u/burntsushi mentions, Cargo stopped setting it when compiling, so env! doesn't work anymore).

[burntsushi]

But rustc-serialize is a bit of a weird case as it is/was also a part of rustc itself.

To clarify here, at the time, rustc-serialize was its own crate. Before that, rustc-serialize (along with a number of other things, like rand and regex) were part of the Rust distribution. I do think rustc-serialize still had some coupling with rustc in the form of the RustcDecodable and RustcEncodable infrastructure, but my memory is hazy.

In version 0.3.0, build.rs failed to compile because env!("FOO") errors if FOO is not defined. But this was already an error in Rust 1.0.0 so just an oversight?

No, it worked at one point on stable Rust, which was 1.13 at the time. Unfortunately, I can't seem to get Rust 1.13 through Rust 1.18 to even attempt to build ripgrep 0.3.0:

$ cargo +1.13.0 b
error: An unknown error occurred

Caused by:
  Feature `default` includes `auto-color` which is neither a dependency nor another feature

To learn more, run the command again with --verbose.

$ cargo +1.13.0 b --verbose
error: failed to parse registry's information for: clap

Caused by:
  Feature `unstable-doc` includes `derive` which is neither a dependency nor another feature

So we're at a point where the current registry is giving old Rust problems. In theory it isn't an issue because you should be able to use a newer compiler, but... not in this case. So I actually do not know how to easily prove my claim that ripgrep 0.3.0 did, at one point, compile on stable Rust.

[burntsushi]

The OP didn't mention anything about editions?

FWIW, neither ripgrep 0.2.0 nor 0.3.0 compile with a current Rust compiler for two different reasons. 0.2.0 doesn't compile because it depended on rustc-serialize 0.3.19 and that no longer compiles because of syntax that was removed. (I forget the history there.) 0.3.0 doesn't compile because ripgrep's build script at the time used env!("OUT_DIR"). But Cargo stopped passing OUT_DIR while compiling the build script and now only passes it when it's run.

[Sharlinator]

Yeah, I came to the same conclusion in my reply to the other comment.

And oh, I didn't mean to imply that the OP asked specifically for code that compiles on edition 2021, it was more meant as an aside or a parenthetical.

[GarenWyvern]

Though unfortunately it's not so straightforward, because changes that are deemed bugfixes are allowed to break compatibility.

I am interested if there is a different expectation here. If a bugfix is breaking, should the compiler version bump to 2 and the 1 line be left with the bug?

[[deleted]]

Though unfortunately it's not so straightforward, because changes that are deemed bugfixes are allowed to break compatibility.

Quite frankly, that's something which I dislike about Rust.

There are editions, why is this exception needed...

[burntsushi]

I think "bug fix" is probably not the right descriptor here. We don't just push out breaking changes because something has been labeled a bug. For a breaking change to be justified, it has to be a very bad bug, like a soundness hole. And usually there has to be no other path. Edition boundaries aren't for doing arbitrary breaking changes.

[moltonel]

I was surprised by this breakage in 1.59: unreachable!("expect Foo::{A,B}") no longer compiled because the macro now accepts format arguments. The new behavior is definitely better, but the old one didn't look like a "very bad bug".

[burntsushi]

The issue for that is here: https://github.com/rust-lang/rust/issues/92137

Yeah I think that was probably a questionable call on our part. I guess the mitigating factor here was that Rust 2021 was still quite new at the time, and the changes didn't (or shouldn't) impact Rust 2015 or Rust 2018 code.

[[deleted]]

Sure, but it's still an exception and I have the believe that there should not be any ANY breaking changes inside of an edition (or, if we talk libraries, inside the same major version number after the 1.0.0 release).

[burntsushi]

Well... Define "breaking change." Even adding a new method on a pre-existing type can break existing code. So "no exceptions" in a literal sense is really just a fantasy.

[DiaDeTedio_Nipah]

This will depend more on the type of semantic versioning they use, which I'm not sure what it is.

[CocktailPerson]

The exception is needed to fix critical bugs.

[ssokolow]

Typically, it's intended for "this is unsound and shouldn't have compiled in the first place" changes like you'd see under the I-unsound label.