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

[Tor Bug Tracker & Wiki]

#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:
                                                 |  0.3.3.1-alpha
 Severity:  Normal                               |     Resolution:
 Keywords:  rust, tor-test, 033-backport,        |  Actual Points:
  review-group-34                                |
Parent ID:                                       |         Points:  1
 Reviewer:  isis                                 |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by Hello71):

 Replying to [comment:8 isis]:
 > 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?)

 This is why I don't like Travis's method of putting the configuration
 inside the repository. Here, I specifically want the changes to only apply
 to this branch. I suppose I could move that to another branch, and base
 this one on that one, but that sounds like a huge pain.

 > 2. Nick's `make test-rust` target from #25071 has been broken, due to no
 longer finding the `test_rust.sh` script.

 I will investigate.

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

 Yes, I am aware, it doesn't work right with sanitizers. I discussed that
 with teor to some extent, but as I recall, I said "we should make a
 'libtor.so'", he said "no, that will cause more problems", and I thought
 "I don't see any better way of doing it. I'll come back to it later." and
 then forgot to come back to it. I think there might be a solution in
 `rustc -Csomething-or-other` though.

 > Locally, on my machine, building out-of-tree, it's mad about:
 >     {{{
 >     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).

 Ah, quite possible, I did not test this. I will investigate.

 Replying to [comment:9 isis]:
 > Oh, one more note:
 >
 > 4. This approach seems pretty sane, but one thing it won't allow is
 doing:
 >     {{{#!sh
 >     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.)

 This seems easy to rectify, just make `test_rust.sh` take a crate to test,
 or potentially check the current directory or something. In theory, we
 could do it in cargo too, but I don't know how to add libraries only
 during testing (or if such a thing exists).

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