Remove cfg(test) from library/core

[saethlin]

The diff here is very small with the ignore whitespace option.

core doesn't/can't have unit tests. All of its tests are just modules under tests/, so it has no use for cfg(test), because the entire contents of library/core/src are only ever compiled with that cfg off, and the entire contents of library/core/tests are only ever compiled with that cfg on.

You can tell this is what's happening because we had #[cfg(test)] on a module declaration that has no source file.

I also deleted the extra mod tests { layer of nesting; there's no need to mention again in the module path that this is a module of tests. This exposes a name collision between the u128 module of tests and core::u128. Fixed that by using <u128>::MAX like is done in the check! macro, which is what avoids this name ambiguity for the other types.

[rustbot]

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[saethlin]

CI passed. Phew. I was afraid these were somehow used for some complicated setup CI uses.

[tgross35]

Why is this change needed?

[saethlin]

The last paragraph of the PR description was my attempt at a short summary. Here's a bigger one.

Without this part of the PR, removing the mod tests { wrapper module generates this error:

error[E0603]: constant import `MAX` is private
   --> core/tests/num/mod.rs:181:25
    |
181 |         let num = u128::MAX as u128;
    |                         ^^^ private constant import
    |
note: the constant import `MAX` is defined here...
   --> core/tests/num/uint_macros.rs:4:13
    |
1   | / macro_rules! uint_module {
2   | |     ($T:ident) => {
3   | |         use core::ops::{BitAnd, BitOr, BitXor, Not, Shl, Shr};
4   | |         use core::$T::*;
    | |             ^^^^^^^^^^^
...   |
316 | |     };
317 | | }
    | |_- in this expansion of `uint_module!`
    |
   ::: core/tests/num/u128.rs:1:1
    |
1   |   uint_module!(u128);
    |   ------------------ in this macro invocation
note: ...and refers to the constant `MAX` which is defined here
   --> /home/ben/rust/library/core/src/num/shells/int_macros.rs:44:9
    |
3   | / macro_rules! int_module {
4   | |     ($T:ident) => (int_module!($T, #[stable(feature = "rust1", since = "1.0.0")]););
5   | |     ($T:ident, #[$attr:meta]) => (
6   | |         #[doc = concat!(
...   |
44  | |         pub const MAX: $T = $T::MAX;
    | |         ^^^^^^^^^^^^^^^^^ you could import this directly
45  | |     )
46  | | }
    | |_- in this expansion of `int_module!`
    |
   ::: /home/ben/rust/library/core/src/num/shells/u128.rs:11:1
    |
11  |   int_module! { u128, #[stable(feature = "i128", since="1.26.0")] }
    |   ----------------------------------------------------------------- in this macro invocation
help: consider importing this constant instead
    |
181 |         let num = std::u128::MAX as u128;
    |                   ~~~~~~~~~~~~~~

Before this PR, name resolution must be concluding that u128::MAX cannot refer to the local u128 module because it doesn't contain an item called MAX. But with the other changes in this PR the local u128 module does contain an item MAX (which was previously at the path u128::tests::MAX)... except that the item is private. And name resolution doesn't recover from that state and try the other u128::MAX possibility?

[tgross35]

Oh duh yeah I should read better

[tgross35]

checks "hide whitespace" in the GH diff view lgtm. r=me with one comment

You can tell this is what's happening because we had #[cfg(test)] on a module declaration that has no source file.

I thought I noticed that yesterday when trying to figure out https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Unit.20tests.20in.20core. I wonder if we could have check-cfg explicitly forbid test

[saethlin]

Ah! Yes your Zulip thread is exactly why I was thinking about this.

[tgross35]

@bors r+

[bors]

📌 Commit 69acb67 has been approved by tgross35

It is now in the queue for this repository.

[saethlin]

Little race condition. While re-reading the code I realized why the macro above doesn't need special treatment: It does <$ty>. So I just imitated that in the u128 code. I prefer that better for the symmetry.

[saethlin]

@bors r=tgross35

[bors]

📌 Commit 4f3ef2a has been approved by tgross35

It is now in the queue for this repository.