The #[start] attribute overrides the test runner implementation

[mstewartgallus]

Consider the code below. When compiled with rustc --test thetest.rs the test suite's code is not run, and the start function is run instead.

use std::rt;

// Compiled with --test it prints Oops!
#[start]
fn start(argc: int, argv: **u8, crate_map: *u8) -> int {
    do rt::start_on_main_thread(argc, argv, crate_map) {
        println("Oops!")
    }
}

[mstewartgallus]

I'm not sure this is precisely a bug. I think it makes some sort of sense. I think what is actually needed is the ability to invoke the test runner from within the start function. Here's some example code that illustrates what I mean where my_low_level_code, and my_main are defined elsewhere.

use std::rt;

#[cfg(test)]
#[start]
fn start(argc: int, argv: **u8, crate_map: *u8) -> int {
    my_low_level_code();
    do rt::start_on_main_thread(argc, argv, crate_map) {
        rt::start_test_runner(argc, argv, crate_map);
    }
}

#[cfg(not(test))]
#[start]
fn start(argc: int, argv: **u8, crate_map: *u8) -> int {
    my_low_level_code();
    do rt::start_on_main_thread(argc, argv, crate_map) {
         my_main();
    }
}

[alexcrichton]

Seems to be a dupe of #8542, but this one has a bit more information, so going to close the other one.

[alexcrichton]

Closing as working as intended. The testing infrastructure already does heavy modifications to the program, and I would expect my own custom start point to still get executed in a test environment if it's getting compiled in. That being said, I also wouldn't expect tests to begin running in my custom start point.