As by default, when executing tests with -C opt-level=n where "n"
is greater than 0, debug assertions are disabled, which removes the
panic!() this test is expecting.
With this tweak, tests no longer fail with any choice of -C opt-level,
and additionally, tests still execute correctly if these tests are
compiled with:
-C opt-level=3 -C debug-assertions=yes
Closes: https://github.com/seanmonstar/reqwest/issues/831
As ENV is process global, modifying it within a thread (as is normal
for all test targets in a rust libtest) results in a concurrency
data-race.
This patch fences the two known cases of needing to modify this by
locking all ENV modifications, and collection of data dependent on
said modifications, into a narrow path isolated by a Mutex lock, with
no test assert!()'s while the Mutex is held
( to avoid a Mutex Posioning ).
However, the code doesn't treat lock failure as a special circumstance,
and if the lock fails, then the pre-existing risk of conccurent ENV
modification returns, and these 2 tests can still randomly fail, but
_in that situation_.
And as mutexes can _only_ be poisoned by the 2 threads holding this
mutex, this regression can now only trip into concurrency issues when
either of these 2 tests are already failing from _non test_ assertions,
so this patch still improves the status quo substantially.
Closes: https://github.com/seanmonstar/reqwest/issues/829
This tweaks the tokio runtime checker (only used in debug mode) in
order to use a single thread.
Performing the CPUs auto-detection step on each check adds significant
syscall-tracing noise and runtime latency. This completely skips it.
The "socks" feature has been removed for a while now, the optional
dependency on the "socks" crate commented out.
The code for actually providing the socks feature was, however, still
mostly present, if a bit out of date.
This commit re-adds the socks feature using the tokio-socks (instead of
socks) crate.
Closes#620
