#24765 closed task (implemented)

What version of Rust does Tor require for 0.3.2?

Reported by: teor Owned by: nickm
Priority: Medium Milestone: Tor: 0.3.3.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: rust, doc
Cc: Actual Points: 0.1
Parent ID: Points: 0.1
Reviewer: Sponsor:

Description (last modified by teor)

On #24761, Sebastian says that we require Rust 1.14, but I can't see that documented anywhere.

We should document it:

And point to it from:

And document the nightly/feature thing in our coding standards:

Child Tickets

TicketStatusOwnerSummaryComponent
#25379closedDetermine the lowest rustc version we will compile withCore Tor/Tor

Change History (11)

comment:1 Changed 21 months ago by teor

Description: modified (diff)

We actually require Rust 1.18 for HashSet retain in protover.rs.

comment:2 Changed 21 months ago by Sebastian

When we started out we wanted to require 1.14 because that is available in Debian. I guess we never documented it properly, and thus it got broken. But if our CI can build with newer Rust then we should probably just use that

comment:3 Changed 21 months ago by nickm

I am in favor of requiring the most recent rust that we can "get away with" requiring.

comment:4 Changed 19 months ago by teor

Milestone: Tor: 0.3.2.x-finalTor: 0.3.3.x-final

These bugfix tickets have no patches. The earliest they will get done is 0.3.3.

comment:5 Changed 19 months ago by isis

Closed #25379 as a duplicate of this.

comment:6 in reply to:  3 Changed 18 months ago by isis

Replying to nickm:

I am in favor of requiring the most recent rust that we can "get away with" requiring.


We can probably get away with the whatever the current nightly is? and then cease and track it to stable when we hear of a major distro that we care about has a new release including it, since Rust releases are quite rapid (6 weeks) and distros are generally quite slow to stabilise. One negative implication of this is we won't be able to use any #[feature]s, ever, or we'll likely have a bad time later trying to ask Rust devs for our features to be stabilised super fast into whichever version we're using that will become stable.

Probably we should at least change configure.ac to check for 1.18, given the HashSet problem that teor noted above.

comment:7 Changed 18 months ago by isis

Keywords: rust added; tor-rust removed

Consolidating the tags

comment:8 Changed 18 months ago by nickm

"Latest nightly" makes me pretty nervous, but I think "latest stable" isn't too bad.

In Rome I talked to Ximin about Debian's Rust packaging, and learned that Debian is apparently tracking latest stable too, so we probably won't get forced to freeze a rust version until the next Debian release starts to freeze.

comment:9 Changed 18 months ago by nickm

Owner: set to nickm
Status: newaccepted

comment:10 Changed 18 months ago by nickm

We didn't mention a version in the RustInTor wiki pake earlier, so I'm not adding one there. I'll write a patch for the other stuff though.

comment:11 Changed 18 months ago by nickm

Resolution: implemented
Status: acceptedclosed

I've done a minimal version of this in 74c767af29e793749e697eba8a206850b156521e, and merged it (since it's docs-only) to 0.3.3 and forward.

Note: See TracTickets for help on using tickets.