Move unit tests into separate files unconfigured during normal build

[petrochenkov]

One of the most annoying parts of compiler refactorings is suddenly discovering that after a refactoring change some code in unit tests stops building.

Compiler unit tests are mostly old, many of them are not really "unit" and need to be migrated to regular ui testing or removed, but that's not the point of this issue.
The point of this issue is that after changing such test you have to restart the bootstrapping process from the crate that unit test belongs to (e.g. touched libsyntax -> rebuild everything).

How to fight this problem?
Exclude unit tests from the normal build!

Files included from under cfg(FALSE) are not considered crate dependencies from build system point of view (not included into dep files).
So, unit test modules included in the next way

#[cfg(test)]
mod tests;

won't cause rebuilds after changing code in them, they will be rebuilt only as a part of unit test run (so they won't participate in bootstrap).

Steps:

• Standardize on the test module naming (currently mod test - 31 instances, mod tests - 183 instances, excluding src/tools and src/test subdirectories).
• Outline test modules into separate files mod tests { ... } -> #[cfg(test)] mod tests;.
• Running unit tests for my_crate: ./x.py test --stage 0 src/my_crate.

[chansuke]

I'd like to work on this.

[petrochenkov]

Standardize on the test module naming (currently mod test - 31 instances, mod tests - 183 instances...

Test modules beside test/tests:

mod __test
mod boxed_test
mod test_json_encode_decode
mod unindent_tests
mod test_map
mod test_set
mod sync_tests
mod dynamic_tests
mod parser_testing
mod test_snippet

[hellow554]

I'd like to work on this.

You could do @rustbot claim to let everyone know that you have claimed the issue :)

[chansuke]

@hellow554 Thank you

[chansuke]

@petrochenkov Hi. I have a question:) I found pub mod tests in src/test/codegen/fastcall-inregs.rs.
Can I just touch src/test/codegen/tests.rs and just move them

    // CHECK: @f1(i32 inreg %arg0, i32 inreg %arg1, i32 %arg2)
    #[no_mangle]
    pub extern "fastcall" fn f1(_: i32, _: i32, _: i32) {}

    // CHECK: @f2(i32* inreg %arg0, i32* inreg %arg1, i32* %arg2)
    #[no_mangle]
    pub extern "fastcall" fn f2(_: *const i32, _: *const i32, _: *const i32) {}

    // CHECK: @f3(float %arg0, i32 inreg %arg1, i32 inreg %arg2, i32 %arg3)
    #[no_mangle]
    pub extern "fastcall" fn f3(_: f32, _: i32, _: i32, _: i32) {}

    // CHECK: @f4(i32 inreg %arg0, float %arg1, i32 inreg %arg2, i32 %arg3)
    #[no_mangle]
    pub extern "fastcall" fn f4(_: i32, _: f32, _: i32, _: i32) {}

    // CHECK: @f5(i64 %arg0, i32 %arg1)
    #[no_mangle]
    pub extern "fastcall" fn f5(_: i64, _: i32) {}

    // CHECK: @f6(i1 inreg zeroext %arg0, i32 inreg %arg1, i32 %arg2)
    #[no_mangle]
    pub extern "fastcall" fn f6(_: bool, _: i32, _: i32) {}

into that file(src/test/codegen/tests.rs)?

[petrochenkov]

@chansuke
Anything inside src/test can be left unchanged, that's a directory with integration tests and the rebuild problem doesn't apply to it.
(Also, git submodule directories in src/tools and src/doc are also out of scope.)

[chansuke]

@petrochenkov Thanks.

[Mark-Simulacrum]

It'd be great to add a tidy lint against mod test { as a simple heuristic that we don't accidentally re-introduce these into the compiler.

[Mark-Simulacrum]

Just noticed that we'll probably want to update tidy's pal lint to whatever name we standardize to:

rust/src/tools/tidy/src/pal.rs

Line 164 in 61d286e

if let Some(mod_tests_idx) = contents.find("mod tests") {

[petrochenkov]

@chansuke
Any news?
This is a relatively large work (~200 files), even if it's largely mechanical, so it's not necessary to do it in one PR, it can be landed in whatever quantities it's more convenient to implement.

[chansuke]

@petrochenkov Hey, sorry for the late reply. I've finished like half of the modules and still working on this issue. Yes, I will send [WIP] PR.

[petrochenkov]

The tidy check is implemented in #62996.

[petrochenkov]

The rest of the work is done in #63207.