#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs