Skip to content
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

'make check' fails on a machine with IPv6 disabled. #12734

Closed
trustin opened this issue Mar 6, 2014 · 2 comments
Closed

'make check' fails on a machine with IPv6 disabled. #12734

trustin opened this issue Mar 6, 2014 · 2 comments

Comments

@trustin
Copy link

trustin commented Mar 6, 2014

During a make check run, I see the following failures:

    io::net::tcp::test::multiple_connect_serial_ip6::green
    io::net::tcp::test::multiple_connect_serial_ip6::native
    io::net::tcp::test::read_eof_twice_ip6::green
    io::net::tcp::test::read_eof_twice_ip6::native
    io::net::tcp::test::smoke_test_ip6::green
    io::net::tcp::test::smoke_test_ip6::native
    io::net::tcp::test::socket_and_peer_name_ip6::green
    io::net::tcp::test::socket_and_peer_name_ip6::native
    io::net::tcp::test::tcp_clone_two_read::green
    io::net::tcp::test::tcp_clone_two_read::native
    io::net::tcp::test::write_close_ip6::green
    io::net::tcp::test::write_close_ip6::native
    io::net::udp::test::socket_name_ip6::green
    io::net::udp::test::socket_name_ip6::native
    io::net::udp::test::socket_smoke_test_ip6::green
    io::net::udp::test::socket_smoke_test_ip6::native
    io::net::udp::test::stream_smoke_test_ip6::green
    io::net::udp::test::stream_smoke_test_ip6::native

.. which seems obviously related with IPv6, which is disabled on my machine. Perhaps these tests could be ignored if the system has no IPv6.

(master, Arch Linux 64-bit 3.10.32-1-lts)

@alexcrichton
Copy link
Member

Detecting whether ipv6 is enabled/disabled on a machine is very platform specific, and likely not worth it. Disabling ipv6 support these days is likely manual, so I imagine that the test failures are fairly self-evident.

The tests properly fail and don't cause any badness with other parts of the system, so they're failing properly if you have ipv6 disabled. Closing because I think that handling this isn't quite worth it and everything is working as intended.

@ghost
Copy link

ghost commented Jan 24, 2015

tl;dr: ignore this; it's just to add more info so it's easier to find this issue.

Just in case someone else is searching for the text of the error(instead of ip6 or ipv6), I would like to add it here:

`Err` value: Address family not supported by protocol'

Actual output (of command time make check):

...
test rand::bench::rand_std ... ignored
test rand::bench::rand_xorshift ... ignored

failures:

---- io::net::tcp::test::clone_while_reading stdout ----
thread 'io::net::tcp::test::clone_while_reading' panicked at 'called `Result::unwrap()` on an `Err` value: Address family not supported by protocol', /home/emacs/build/rust/src/libcore/result.rs:742


---- io::net::tcp::test::connect_ip6_loopback stdout ----
thread 'io::net::tcp::test::connect_ip6_loopback' panicked at 'called `Result::unwrap()` on an `Err` value: Address family not supported by protocol', /home/emacs/build/rust/src/libcore/result.rs:742


---- io::net::tcp::test::multiple_connect_serial_ip6 stdout ----
thread 'io::net::tcp::test::multiple_connect_serial_ip6' panicked at 'called `Result::unwrap()` on an `Err` value: Address family not supported by protocol', /home/emacs/build/rust/src/libcore/result.rs:742


---- io::net::tcp::test::read_timeouts stdout ----
thread 'io::net::tcp::test::read_timeouts' panicked at 'called `Result::unwrap()` on an `Err` value: Address family not supported by protocol', /home/emacs/build/rust/src/libcore/result.rs:742


---- io::net::tcp::test::readwrite_timeouts stdout ----
thread 'io::net::tcp::test::readwrite_timeouts' panicked at 'called `Result::unwrap()` on an `Err` value: Address family not supported by protocol', /home/emacs/build/rust/src/libcore/result.rs:742


---- io::net::tcp::test::socket_and_peer_name_ip6 stdout ----
thread 'io::net::tcp::test::socket_and_peer_name_ip6' panicked at 'called `Result::unwrap()` on an `Err` value: Address family not supported by protocol', /home/emacs/build/rust/src/libcore/result.rs:742


---- io::net::tcp::test::smoke_test_ip6 stdout ----
thread 'io::net::tcp::test::smoke_test_ip6' panicked at 'called `Result::unwrap()` on an `Err` value: Address family not supported by protocol', /home/emacs/build/rust/src/libcore/result.rs:742


---- io::net::tcp::test::tcp_clone_two_read stdout ----
thread 'io::net::tcp::test::tcp_clone_two_read' panicked at 'called `Result::unwrap()` on an `Err` value: Address family not supported by protocol', /home/emacs/build/rust/src/libcore/result.rs:742


---- io::net::tcp::test::timeout_concurrent_read stdout ----
thread 'io::net::tcp::test::timeout_concurrent_read' panicked at 'called `Result::unwrap()` on an `Err` value: Address family not supported by protocol', /home/emacs/build/rust/src/libcore/result.rs:742


---- io::net::tcp::test::write_timeouts stdout ----
thread 'io::net::tcp::test::write_timeouts' panicked at 'called `Result::unwrap()` on an `Err` value: Address family not supported by protocol', /home/emacs/build/rust/src/libcore/result.rs:742



failures:
io::net::tcp::test::clone_while_reading
io::net::tcp::test::connect_ip6_loopback
io::net::tcp::test::multiple_connect_serial_ip6
io::net::tcp::test::read_eof_twice_ip6
io::net::tcp::test::read_timeouts
io::net::tcp::test::readwrite_timeouts
io::net::tcp::test::smoke_test_ip6
io::net::tcp::test::socket_and_peer_name_ip6
io::net::tcp::test::tcp_clone_two_read
io::net::tcp::test::timeout_concurrent_read
io::net::tcp::test::write_close_ip6
io::net::tcp::test::write_timeouts
io::net::udp::test::socket_name_ip6
io::net::udp::test::socket_smoke_test_ip6

test result: FAILED. 744 passed; 14 failed; 62 ignored; 0 measured

thread '' panicked at 'Some tests failed', /home/emacs/build/rust/src/libtest/lib.rs:251
/home/emacs/build/rust/mk/tests.mk:457: recipe for target 'tmp/check-stage2-T-x86_64-unknown-linux-gnu-H-x86_64-unknown-linux-gnu-std.ok' failed
make: *** [tmp/check-stage2-T-x86_64-unknown-linux-gnu-H-x86_64-unknown-linux-gnu-std.ok] Error 101

real 29m30.325s
user 43m22.983s
sys 3m56.053s

I have ipv6.disable=1 on kernel cmdline and also ipv6 is disabled at compilation time of the kernel.

tested with (latest)commit: 4be79d6

bors added a commit to rust-lang-ci/rust that referenced this issue Jun 5, 2023
…=Veykril

Introduce macro sub-namespaces and `macro_use` prelude

This PR implements two mechanisms needed for correct macro name resolution: macro sub-namespace and `macro_use` prelude.

- [macro sub-namespaces][subns-ref]

  Macros have two sub-namespaces: one for function-like macro and the other for those in attributes (including custom derive macros). When we're resolving a macro name for function-like macro, we should ignore non-function-like macros, and vice versa.

  This helps resolve single-segment macro names because we can (and should, as rustc does) fallback to names in preludes when the name in the current module scope is in different sub-namespace.

- [`macro_use` prelude][prelude-ref]

  `#[macro_use]`'d extern crate declarations (including the standard library) bring their macros into scope, but they should not be prioritized over local macros (those defined in place and those explicitly imported).

  We have been bringing them into legacy (textual) macro scope, which has the highest precedence in name resolution. This PR introduces the `macro_use` prelude in crate-level `DefMap`s, whose precedence is lower than local macros but higher than the standard library prelude.

The first 3 commits are drive-by fixes/refactors.

Fixes rust-lang#8828 (prelude)
Fixes rust-lang#12505 (prelude)
Fixes rust-lang#12734 (prelude)
Fixes rust-lang#13683 (prelude)
Fixes rust-lang#13821 (prelude)
Fixes rust-lang#13974 (prelude)
Fixes rust-lang#14254 (namespace)

[subns-ref]: https://doc.rust-lang.org/reference/names/namespaces.html#sub-namespaces
[prelude-ref]: https://doc.rust-lang.org/reference/names/preludes.html#macro_use-prelude
flip1995 pushed a commit to flip1995/rust that referenced this issue May 2, 2024
suppress `readonly_write_lock` for underscore-prefixed bindings

Fixes rust-lang#12733

Unsure if there's a better way to prevent this kind of false positive but this is the one that made most sense to me.
In my experience, prefixing bindings with an underscore is the usual way to name variables that aren't used and that exist purely for executing drop code at the end of the scope.

-------

changelog: suppress [`readonly_write_lock`] for underscore-prefixed bindings
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants