[tor-bugs] #25386 [Core Tor/Tor]: fix rust tests

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Mar 14 01:50:56 UTC 2018

#25386: fix rust tests
 Reporter:  Hello71                              |          Owner:  (none)
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  High                                 |      Milestone:  Tor:
                                                 |  0.3.4.x-final
Component:  Core Tor/Tor                         |        Version:  Tor:
 Severity:  Normal                               |     Resolution:
 Keywords:  rust, tor-test, 033-backport,        |  Actual Points:
  review-group-34                                |
Parent ID:                                       |         Points:  1
 Reviewer:  isis                                 |        Sponsor:

Comment (by isis):

 Replying to [comment:8 isis]:
 > Hello Hello71! (hah) Thanks a whole bunch for looking into this and for
 the patches! This looks much better than the attempts I was making going
 through cargo and rust `#[cfg]` linker directives.
 > Some notes on a couple issues:
 > 1. I reverted `350f76d3` and `8748ddac` in my `bug25386`
 [https://gitweb.torproject.org/user/isis/tor.git/log/?h=bug25386 branch],
 as they both affected the TravisCI builds to enable OSX (which takes
 ''forever'', hence why it's disabled by default) and also to (mostly?)
 disable clang (not sure why this was done? We like testing our C with
 different compilers, and clang's LeakSanitizer has
 [https://trac.torproject.org/projects/tor/ticket/25127 caught leaks] where
 GCC has not). Generally, in your personal repo, if you'd like to enable
 OSX builds for a branch, the way to do so is to make another branch off of
 it with the commits to enable the OSX builds, so that they don't
 accidentally get merged and make everyone's builds suddenly slow. (Also
 the changes seem to have [https://travis-
 ci.org/isislovecruft/tor/builds/353137303 resulted] in building with GCC
 and `--enable-cargo-online-mode` twice somehow?)
 > 2. Nick's `make test-rust` target from #25071 has been broken, due to no
 longer finding the `test_rust.sh` script.
 > 3. `make check` [https://travis-
 ci.org/isislovecruft/tor/builds/353137303 fails]. (That Travis build is
 just a copy of your branch that I prefixed with `testing/hello71/` to keep
 it out of my branch namespace.) It looks like it's pretty angry about
 missing symbols. Locally, on my machine, building out-of-tree, it's mad
 >     {{{
 >     FAIL: src/test/test_rust.sh
 >     ===========================
 >     error: could not find `Cargo.toml` in `/home/isis/code/torproject
 /tor-build/src/rust` or any parent directory`
 >     }}}
 >     (My `tor/` directory is at `/home/isis/code/torproject/tor`.) This
 will [https://jenkins.torproject.org/ break our Jenkins builds].
 > I think once we're able to get these things fixed, then we can start on
 the UBSan/other sanitiser issues (possibly merging in-between).

 Oh, one more note:

 4. This approach seems pretty sane, but one thing it won't allow is doing:
     cd src/rust/protover
     cargo test
     and getting a positive result.  I'm not sure how much we should care
 about that, especially if—as a team—we're going to eventually agree that
 things will simply be rewritten in Rust, as opposed to maintained in both
 languages. (I.e. it's only a problem while we maintain both, and maintain
 the FFI boundary for both.)

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

More information about the tor-bugs mailing list