[tor-bugs] #22106 [Core Tor/Tor]: Initial Rust support

[Tor Bug Tracker & Wiki]

#22106: Initial Rust support
--------------------------+------------------------------------
 Reporter:  Sebastian     |          Owner:
     Type:  defect        |         Status:  needs_revision
 Priority:  Medium        |      Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------

Comment (by Sebastian):

 Replying to [comment:10 teor]:
 > Replying to [comment:9 Sebastian]:
 > > Replying to [comment:8 teor]:
 > > > Replying to [comment:7 Sebastian]:
 > > > > > I think it's ok to expect people to install rust's libc: we
 already do this with libevent and {open,libre,*}SSL. They'll have to
 install rust, so installing libc is a reasonable ask.
 > > > >
 > > > > I don't know what you mean with install rust'c libc. It's a crate
 that needs to be available during building, not a dynamic library you can
 link to or something. The crate provides bindings for different host libc
 implementations.
 > > >
 > > > Oh, ok, then yes, a local crates mirror seems sensible.
 > > > And a make target to set it up. I can't quite work out how to do it!
 > >
 > > There's a subcommand for cargo called vendor (not installed
 automatically) that can do that. I can add a make target for it once we
 decided which of the options for mirroring we're taking.
 >
 > When I ran the rust build without the crates, it failed halfway through
 make.
 > Can we check at configure time instead?
 > That's when we fail if we don't have other dependencies installed.

 Of course we will do that, but since different mechanisms are required for
 the different potential solutions I outlined above, none of them are
 implemented right now. See the note about it failing unless dependencies
 are in Cargo's cache, in the first post here. This seems unrelated to
 making vendoring easier.

 > Then we would need the rust dependencies to be a shell script (or a line
 in the rust install doc), not a make target.
 >
 > > ...
 > > > Is there a linter (?) or style checker (make check-spaces) that we
 might want to run?
 > >
 > > There's both, clippy (a linter, requires Rust nightly) and rustfmt.
 Not yet sure how to best integrate them. Both are rapidly evolving.
 >
 > My experience with rustfmt is that it wraps to 100 characters by
 default. We probably want 79 to match our C standards:
 >
 https://gitweb.torproject.org/tor.git/tree/doc/HACKING/CodingStandards.md#n125

 We already do that via a config file. I forgot to add it to the commits
 here, but it's added now.

 > And we want to wrap comments as well.
 >
 > We could actually enforce formatting, which would be nice.

 This is harder to do than it appears, because it requires everyone to be
 in sync with rustfmt versions. Since a tool exist that can reformat, I
 would like to not require it at first except at the review stage, and then
 explore our options.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22106#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online