New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

std::net: Ipv4Addr and Ipv6Addr improvements #56050

Open
wants to merge 11 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@little-dude
Contributor

little-dude commented Nov 18, 2018

I picked up my previous un-finished PR: #51832
Two tests are failing right now, but I'm working on it.

Ref: #27709

@rust-highfive

This comment has been minimized.

Collaborator

rust-highfive commented Nov 18, 2018

r? @TimNN

(rust_highfive has picked a reviewer for you, use r? to override)

@little-dude little-dude force-pushed the little-dude:ip branch 2 times, most recently from ac694a9 to ea87fb7 Nov 18, 2018

@rust-highfive

This comment has been minimized.

Collaborator

rust-highfive commented Nov 18, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:1f4d7e9e:start=1542570720324934632,finish=1542570721501581896,duration=1176647264
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-5.0
---

[00:03:46] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:03:47] tidy error: /checkout/src/libstd/net/ip.rs:519: line longer than 100 chars
[00:03:47] tidy error: /checkout/src/libstd/net/ip.rs:1219: line longer than 100 chars
[00:03:47] tidy error: /checkout/src/libstd/net/ip.rs:1271: line longer than 100 chars
[00:03:47] tidy error: /checkout/src/libstd/net/ip.rs:2031: line longer than 100 chars
[00:03:47] tidy error: /checkout/src/libstd/net/ip.rs:2033: line longer than 100 chars
[00:03:47] tidy error: /checkout/src/libstd/net/ip.rs:2052: line longer than 100 chars
[00:03:48] some tidy checks failed
[00:03:48] 
[00:03:48] 
[00:03:48] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:03:48] 
[00:03:48] 
[00:03:48] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:03:48] Build completed unsuccessfully in 0:00:50
[00:03:48] Build completed unsuccessfully in 0:00:50
[00:03:48] Makefile:79: recipe for target 'tidy' failed
[00:03:48] make: *** [tidy] Error 1
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:0bfbc8b8
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Sun Nov 18 19:55:59 UTC 2018
---
travis_time:end:1a72b9f5:start=1542570959526905974,finish=1542570959534549926,duration=7643952
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:00167052
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:09606000
travis_time:start:09606000
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:0a1b9a25
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@little-dude

This comment has been minimized.

Contributor

little-dude commented Nov 19, 2018

I have a few questions

How can I get stacktraces with all the line numbers?

I run:

RUST_BACKTRACE=full python x.py test src/libstd --stage 1

But the stacktrace is just:

  left: `true`,                                                                                         
 right: `false`', libstd/net/ip.rs:1946:13                                                              
stack backtrace:                                           
   0:     0x55d5563891cf - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h94bf54f902935668 
   1:     0x55d55635d9f7 - std::sys_common::backtrace::print::h29623c1aa060fc2f                         
   2:     0x55d5563f3e2f - std::panicking::default_hook::{{closure}}::h131049a1fc0672a2                 
   3:     0x55d5563f45ad - std::panicking::rust_panic_with_hook::h61610c5f8013cd16                      
   4:     0x55d5563f3fd0 - std::panicking::continue_panic_fmt::h721927dbbb0e40f5                        
   5:     0x55d5563f3f1e - std::panicking::begin_panic_fmt::h81505cc781e6dfe2                           
   6:     0x55d5563fb005 - std::net::ip::tests::ip_properties::check6::hf70d0d1be4e61588                
   7:     0x55d5563fa5af - std::net::ip::tests::ip_properties::h6be1fabe5a9bc980                        
   8:     0x7f281962949e - <F as alloc::boxed::FnBox<A>>::call_box::h94f7e1459d039765                   
   9:     0x7f2819583819 - __rust_maybe_catch_panic                                                     
  10:     0x7f281961797d - std::sys_common::backtrace::__rust_begin_short_backtrace::h4b5c31c858f402b8  
  11:     0x7f281960db84 - std::panicking::try::do_call::h2f9e4885c52d06ae
  12:     0x7f2819583819 - __rust_maybe_catch_panic                                                     
  13:     0x7f281960912c - <F as alloc::boxed::FnBox<A>>::call_box::h6396d3a5d65778c6                   
  14:     0x7f281954c0ad - std::sys_common::thread::start_thread::h8809e36f95be609f                     
  15:     0x7f2819578d85 - std::sys::unix::thread::Thread::new::thread_start::hda87df3389a6b90f
  16:     0x7f2819660a9c - start_thread
  17:     0x7f281940cb22 - clone
  18:                0x0 - <unknown>

What's the fastest way to run the tests?

It seems that many things get re-compiled with the above command, not just libstd. Someone on discord suggested --keep-stage 0 but that results in:

error[E0460]: found possibly newer version of crate `std` which `rand` depends on                                                                    [25/1841]
  --> libstd/tests/env.rs:11:1
   |
11 | extern crate rand;
   | ^^^^^^^^^^^^^^^^^^
   |
   = note: perhaps that crate needs to be recompiled?
   = note: the following crate versions were found:
           crate `std`: /home/corentih/rust/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-a5fba866ec21af50.rlib
           crate `std`: /home/corentih/rust/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps/libstd-a5fba866ec21af50.rlib
           crate `std`: /home/corentih/rust/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps/libstd-a5fba866ec21af50.so
           crate `std`: /home/corentih/rust/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-a5fba866ec21af50.so
           crate `rand`: /home/corentih/rust/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps/librand-f4e190f4f182b613.rlib

error: aborting due to previous error

I also tried --stage 0 but it seems to take just as much time as --stage 1.

How could the tests be refactored?

The ipv6 properties test in particular look like this:

check("fdff:ffff::", &[0xfd, 0xff, 0xff, 0xff, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
      false, false, true, false, false, false, false, false, None);

I'm planning to add a few more properties so this is starting to get really hard to read and debug. I first started to write everything explicitely for each ip:

let ip: Ipv6Addr = "ff01::".parse().unwrap();         
assert!(!ip.is_unspecified());                        
assert!(!ip.is_loopback());                           
assert!(!ip.is_unique_local());                       
assert!(!ip.is_global());                             
assert!(!ip.is_unicast_link_local());                 
assert!(!ip.is_unicast_link_local_strict());          
assert!(!ip.is_unicast_global());                     
assert!(!ip.is_documentation());                      
assert!(ip.is_multicast());                           
assert_eq!(ip.multicast_scope(), Some(InterfaceLocal))

It's nice because when something fails, I directly know which line failed, but it's getting really long. Each new test case adds a dozen of lines.

little-dude added some commits Nov 19, 2018

std::net: improve Ipv6Addr::is_unicast_site_local() doc
- quote the RFC
- add a link to the RFC
- fix markdown
std::net: add Ipv6Addr::is_unicast_link_local_strict()
RFC 4291 is a little unclear about what is a unicast link local address.
According to section 2.4, the entire fe80::/10 range is reserved for
these addresses, but section 2.5.3 defines a stricter format for such
addresses.

After a discussion[0] is has been decided to add a different method for
each definition, so this commit:

  - renames is_unicast_link_local() into is_unicast_link_local_strict()
  - relaxed the check in is_unicast_link_local()

[0]: #27709 (comment)
std::net: fix Ipv4Addr::is_global()
As per @therealbstern's comment[0]:

The implementation of Ipv4::is_global is not complete, according to the
IANA IPv4 Special-Purpose Address Registry.

        - It compares the address to 0.0.0.0, but anything in 0.0.0.0/8
          should not be considered global.
                - 0/8 is not global and is currently forbidden because
                  some systems used to treat it as the local network.
                - The implementation of Ipv4::is_unspecified is correct.
                  0.0.0.0 is the unspecified address.
        - It does not examine 100.64.0.0/10, which is "Shared Address
          Space" and not global.
        - Ditto 192.0.0.0/24 (IETF Protocol Assignments), except for
          192.0.0.9/32 and 192.0.0.10/32, which are carved out as
          globally reachable.
        - 198.18.0.0/15 is for "Benchmarking" and should not be globally
          reachable.
        - 240.0.0.0/4 is reserved and not currently reachable

@little-dude little-dude force-pushed the little-dude:ip branch from ea87fb7 to bf19000 Nov 19, 2018

@rust-highfive

This comment has been minimized.

Collaborator

rust-highfive commented Nov 19, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:34a3c89b:start=1542650783378931275,finish=1542650838005588580,duration=54626657305
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-5.0
---
[00:43:17] 
[00:43:17] warning: `[is_unicast_link_local]` cannot be resolved, ignoring it...
[00:43:17]     --> libstd/net/ip.rs:1196:5
[00:43:17]      |
[00:43:17] 1196 | /     /// Returns [`true`] if the address is a unicast link-local address (`fe80::/64`).
[00:43:17] 1197 | |     ///
[00:43:17] 1198 | |     /// A common mis-conception is to think that "unicast link-local addresses start with
[00:43:17] 1199 | |     /// `fe80::`", but the [IETF RFC 4291] actually defines a stricter format for these addresses:
[00:43:17] ...    |
[00:43:17] 1245 | |     /// [`is_unicast_link_local()`](#method.is_unicast_link_local)
[00:43:17]      | |_______^
[00:43:17]      |
[00:43:17]      = note: the link appears in this line:
[00:43:17]              
[00:43:17]              
[00:43:17]               If you need a less strict validation use [`is_unicast_link_local()`] instead.
[00:43:17]      = help: to escape `[` and `]` characters, just add '\' before them like `\[` or `\]`
[00:43:17] 
[00:43:17] 
[00:43:17] warning: `[is_unicast_link_local_strict]` cannot be resolved, ignoring it...
[00:43:17]      |
[00:43:17]      |
[00:43:17] 1254 | /     /// Returns [`true`] if the address is a unicast link-local address (`fe80::/10`).
[00:43:17] 1255 | |     ///
[00:43:17] 1256 | |     /// This method returns [`true`] for addresses in the range reserved by [RFC 4291 section 2.4],
[00:43:17] 1257 | |     /// i.e. addresses with the following format:
[00:43:17] ...    |
[00:43:17] 1304 | |     /// [`is_unicast_link_local_strict()`](#method.is_unicast_link_local_strict)
[00:43:17]      | |_______^
[00:43:17]      |
[00:43:17]      = note: the link appears in this line:
[00:43:17]              
[00:43:17]              
[00:43:17]               unicast link-local addresses, whereas [`is_unicast_link_local_strict()`] does not. If you
[00:43:17]      = help: to escape `[` and `]` characters, just add '\' before them like `\[` or `\]`
[00:43:17] 
[00:43:17] 
[00:43:17] warning: `[is_unicast_link_local_strict]` cannot be resolved, ignoring it...
[00:43:17]      |
[00:43:17]      |
[00:43:17] 1254 | /     /// Returns [`true`] if the address is a unicast link-local address (`fe80::/10`).
[00:43:17] 1255 | |     ///
[00:43:17] 1256 | |     /// This method returns [`true`] for addresses in the range reserved by [RFC 4291 section 2.4],
[00:43:17] 1257 | |     /// i.e. addresses with the following format:
[00:43:17] ...    |
[00:43:17] 1304 | |     /// [`is_unicast_link_local_strict()`](#method.is_unicast_link_local_strict)
[00:43:17]      | |_______^
[00:43:17]      |
[00:43:17]      = note: the link appears in this line:
[00:43:17]              
[00:43:17]              
[00:43:17]               [`is_unicast_link_local_strict()`].
[00:43:17]      = help: to escape `[` and `]` characters, just add '\' before them like `\[` or `\]`
[00:43:17] 
[00:43:17] warning: `[chunks]` cannot be resolved, ignoring it...
[00:43:17]    --> /checkout/src/libcore/slice/mod.rs:860:52
---
[00:47:38] .................................................................................................... 100/5040
[00:47:41] .................................................................................................... 200/5040
[00:47:43] .............................ii............................................ii...................ii.. 300/5040
[00:47:46] ..............................................................................................iii... 400/5040
[00:47:49] .....iiiiiiii.iii............................iii...........................................i........ 500/5040
[00:47:55] .................................................................................................... 700/5040
[00:48:01] ..................................................................................i...........i..... 800/5040
[00:48:04] .................................................................................................... 900/5040
[00:48:07] .iiiii..................ii.iiii..................................................................... 1000/5040
---
[00:48:41] .................................................................................................... 2200/5040
[00:48:45] .................................................................................................... 2300/5040
[00:48:48] .................................................................................................... 2400/5040
[00:48:52] .................................................................................................... 2500/5040
[00:48:55] .....................................................................................iiiiiiiii...... 2600/5040
[00:49:02] ...................................................ii............................................... 2800/5040
[00:49:04] .................................................................................................... 2900/5040
[00:49:08] .................................................................................................... 3000/5040
[00:49:11] ..............................................i..................................................... 3100/5040
---
travis_time:start:test_codegen
Check compiletest suite=codegen mode=codegen (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:02:20] 
[01:02:20] running 117 tests
[01:02:23] i..ii...iii..iiii.....i...i.........i..iii...........i.....i.....ii...i..i.ii..............i...ii..i 100/117
[01:02:23] i.i.....iiii.....
[01:02:23] 
[01:02:23]  finished in 3.401
[01:02:23] travis_fold:end:test_codegen

---
travis_time:start:test_debuginfo
Check compiletest suite=debuginfo mode=debuginfo-both (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:02:37] 
[01:02:37] running 118 tests
[01:03:00] .iiiii...i.....i..i...i..i.i..i.i..i.....i..i....i..........iiii.........i.i....i...i.......ii.i.i.i 100/118
[01:03:04] ......iii.i.....ii
[01:03:04] 
[01:03:04]  finished in 27.119
[01:03:04] travis_fold:end:test_debuginfo

---
[01:21:43] thread '<unnamed>' panicked at 'explicit panic', libstd/io/buffered.rs:1297:17
[01:21:43] thread '<unnamed>' panicked at 'explicit panic', libstd/io/stdio.rs:758:13
[01:21:43] .................................................................................................... 300/769
[01:21:43] thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
[01:21:43]   left: `true`,
[01:21:43]  right: `false`', libstd/net/ip.rs:1946:13
[01:21:43] thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
[01:21:43]   left: `true`,
[01:21:43]  right: `false`', libstd/net/ip.rs:2041:13
[01:21:43] ....................................F........F...................................................... 400/769
[01:21:44] .................................................................................................... 500/769
[01:21:44] thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', libcore/result.rs:1009:5
[01:21:44] thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', libcore/result.rs:1009:5
[01:21:44] thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', libcore/result.rs:1009:5
---
[01:21:46] dur: 107ns
_64-unknown-linux-gnu
136812 ./obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release
134664 ./obj/build/bootstrap/debug/incremental/bootstrap-zemjd6kcyh2u
134660 ./obj/build/bootstrap/debug/incremental/bootstrap-zemjd6kcyh2u/s-f6to2up8ey-1mxn0m2-2q1xp1m83q6vz
130760 ./obj/build/x86_64-unknown-linux-gnu/stage0-bootstrap-tools/x86_64-unknown-linux-gnu
130756 ./obj/build/x86_64-unknown-linux-gnu/stage0-bootstrap-tools/x86_64-unknown-linux-gnu/release
127624 ./obj/build/x86_64-unknown-linux-gnu/test/mir-opt
123684 ./obj/build/x86_64-unknown-linux-gnu/stage0-bootstrap-tools/x86_64-unknown-linux-gnu/release/deps
---
67092 ./obj/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu
67088 ./obj/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release
62416 ./obj/build/x86_64-unknown-linux-gnu/test/run-pass
56436 ./src/llvm/test/MC
56044 E" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@little-dude

This comment has been minimized.

Contributor

little-dude commented Nov 20, 2018

Building the doc or running the tests more than 30 minutes locally, it's really hard to test changes, even as simple as these. Am I doing something wrong? What's people workflow when they make changes to libstd?

@rust-highfive

This comment has been minimized.

Collaborator

rust-highfive commented Nov 20, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:00a5df66:start=1542674007214576155,finish=1542674063675825801,duration=56461249646
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-5.0
---
[00:49:00] .................................................................................................... 100/5040
[00:49:03] .................................................................................................... 200/5040
[00:49:05] .............................ii............................................ii...................ii.. 300/5040
[00:49:08] ..............................................................................................iii... 400/5040
[00:49:11] .....iiiiiiii.iii............................iii...........................................i........ 500/5040
[00:49:18] .................................................................................................... 700/5040
[00:49:24] ..................................................................................i...........i..... 800/5040
[00:49:27] .................................................................................................... 900/5040
[00:49:30] .iiiii..................ii.iiii..................................................................... 1000/5040
---
[00:50:05] .................................................................................................... 2200/5040
[00:50:09] .................................................................................................... 2300/5040
[00:50:12] .................................................................................................... 2400/5040
[00:50:16] .................................................................................................... 2500/5040
[00:50:19] .....................................................................................iiiiiiiii...... 2600/5040
[00:50:26] ...................................................ii............................................... 2800/5040
[00:50:29] .................................................................................................... 2900/5040
[00:50:33] .................................................................................................... 3000/5040
[00:50:36] ..............................................i..................................................... 3100/5040
---
travis_time:start:test_codegen
Check compiletest suite=codegen mode=codegen (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:04:06] 
[01:04:06] running 117 tests
[01:04:09] i..ii....iii.iiii.....i...i.........i..iii...........i.....i.....ii...i..i.ii..............i...ii..i 100/117
[01:04:09] i.i.....iiii.....
[01:04:09] 
[01:04:09]  finished in 3.319
[01:04:09] travis_fold:end:test_codegen

---
travis_time:start:test_debuginfo
Check compiletest suite=debuginfo mode=debuginfo-both (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:04:23] 
[01:04:23] running 118 tests
[01:04:45] .iiiii...i.....i..i...i..i.i..i.i..i.....i..i....i..........iiii.........i.i....i...i.......ii.i.i.i 100/118
[01:04:49] ......iii.i.....ii
[01:04:49] 
[01:04:49]  finished in 26.441
[01:04:49] travis_fold:end:test_debuginfo

---
[01:23:32] thread '<unnamed>' panicked at 'explicit panic', libstd/io/buffered.rs:1297:17
[01:23:33] thread '<unnamed>' panicked at 'explicit panic', libstd/io/stdio.rs:758:13
[01:23:33] .................................................................................................... 300/769
[01:23:33] thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
[01:23:33]   left: `true`,
[01:23:33]  right: `false`', libstd/net/ip.rs:1948:13
[01:23:33] thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
[01:23:33]   left: `true`,
[01:23:33]  right: `false`', libstd/net/ip.rs:2043:13
[01:23:33] ....................................F........F...................................................... 400/769
[01:23:34] .................................................................................................... 500/769
[01:23:34] thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', libcore/result.rs:1009:5
[01:23:34] thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', libcore/result.rs:1009:5
[01:23:34] thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', libcore/result.rs:1009:5

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@clarcharr

This comment has been minimized.

Contributor

clarcharr commented Nov 20, 2018

Question: if these were changed to slice matches, would the compiler generate more optimal code? It seems like the complexity in these methods would probably generate much more code than one would want but I'm curious if that's actually the case.

@little-dude

This comment has been minimized.

Contributor

little-dude commented Nov 27, 2018

@clarcharr I have no idea. We don't have benchmarks for these but this is something I could add.

To whoever will review this PR, I still have a few questions regarding the tests: how to run them quickly, and how to get full stacktraces. That would be really helpful to fix the existing tests and write new ones.

@TimNN

This comment has been minimized.

Contributor

TimNN commented Nov 27, 2018

How can I get stacktraces with all the line numbers?

I don't know what the correct config.toml settings are for this. As a workaround, maybe you could turn check() into a macro, which includes the line number? Or add the failing IP address to the assertion message in check()?

What's the fastest way to run the tests?

I don't know.

How could the tests be refactored?

Maybe have multiple check() functions, which each only take a limited number of arguments?

@Dylan-DPC

This comment has been minimized.

Member

Dylan-DPC commented Dec 10, 2018

ping from triage @TimNN @little-dude what's the update on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment