[tor-bugs] #25639 [Core Tor/Tor]: think about Rust crate boundaries

[Tor Bug Tracker & Wiki]

#25639: think about Rust crate boundaries
--------------------------+----------------------------------
 Reporter:  Hello71       |          Owner:  Hello71
     Type:  enhancement   |         Status:  assigned
 Priority:  High          |      Milestone:
Component:  Core Tor/Tor  |        Version:  Tor: unspecified
 Severity:  Normal        |     Resolution:
 Keywords:  rust          |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+----------------------------------

Comment (by Hello71):

 yeah, I found https://github.com/rust-lang/rfcs/pull/2318. I haven't gone
 through the comments yet, but:

 I have heard that Rust people want it to be really easy to use both Rust
 and C together in the same project, at least during a (potentially
 extended) migration. For projects that actually test though (hopefully all
 of them!), interlanguage testing needs to be really solid. In particular,
 the majority of C projects (i.e. the ones that are medium-sized like Tor
 and not huge like Gecko) have semantic rather than strictly-defined module
 separation. Tor is certainly modular, but (as far as I know) they have
 many cyclic dependencies that get worked out by the magic of static
 archives. This doesn't work in the following case though (AFAIK): suppose
 there are Rust crates A and B and C blob C. A and B don't depend on each
 other, but C depends on both. We want to test A. If we just add C to link,
 it doesn't work, because C has a hidden dependency on B. But if we add our
 Rust blob (we call it `tor_rust`), then we get multiple definition errors.
 Maybe I'm doing it wrong, but I think this is a key use case for Rust
 (gradual migration from full-C/C++ projects), so I feel like this should
 be really easy and not require that I re-architect all my C module
 boundaries or give up and just write tests in C.

 > Applying this to Tor, the way to make it work would be to have a single
 toplevel crate, which optionally includes some testing crates which export
 test symbols that get called from a C test file for whatever framework
 y'all use. This isn't great; I'm hoping in the future cargo test will be
 better at this (we're working on custom test frameworks which should make
 this easier).

 I considered doing this; I assume this involves some sort of custom macro
 or (minor) boilerplate though, and either way we'd have to write or find a
 non-"standard" test framework, when we really just want to link in a few
 extra libraries. Really I was hoping that I could just do `rustc --crate-
 type staticlib --test` and have it actually work (the output would have a
 `main` or `_start` or whatever Rust does), and just link that normally.
 That would require `--print native-static-libs` to work through Cargo
 though.

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