[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 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.

 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

 And we want to wrap comments as well.

 We could actually enforce formatting, which would be nice.

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