-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Comments
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. |
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:
Actual output (of command ... I have tested with (latest)commit: 4be79d6 |
…=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
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
During a
make check
run, I see the following failures:.. 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)
The text was updated successfully, but these errors were encountered: