rustc: gensym the module names for --test to avoid introducing names.

[huonw]

This requires avoiding quote_...! for constructing the parts of the
__test module, since that stringifies and reinterns the idents, losing
the special gensym'd nature of them. (#15962.)

[sfackler]

Ah, that's what the problem was! (Also this doesn't compile: https://travis-ci.org/rust-lang/rust/jobs/30801909)

[huonw]

Err, yes, I always compile the patch I actually commit. always

(Will fix tonight.)

[huonw]

@alexcrichton this is failing due to two test using the __test module directly:

---- [run-pass] run-pass/core-run-destroy.rs stdout ----

    error: compilation failed!
    status: exit code: 101
    command: x86_64-apple-darwin/stage2/bin/rustc /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/test/run-pass/core-run-destroy.rs -L x86_64-apple-darwin/test/run-pass --target=x86_64-apple-darwin -L x86_64-apple-darwin/test/run-pass/core-run-destroy.stage2-x86_64-apple-darwin.libaux -C prefer-dynamic -o x86_64-apple-darwin/test/run-pass/core-run-destroy.stage2-x86_64-apple-darwin --cfg rtopt --cfg debug -O -L x86_64-apple-darwin/rt --test
    stdout:
    ------------------------------------------

    ------------------------------------------
    stderr:
    ------------------------------------------
    /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/test/run-pass/core-run-destroy.rs:58:50: 58:62 error: failed to resolve. Use of undeclared module `__test`
    /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/test/run-pass/core-run-destroy.rs:58     green::start(argc, argv, rustuv::event_loop, __test::main)
                                                                                                                                                             ^~~~~~~~~~~~
    /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/test/run-pass/core-run-destroy.rs:58:50: 58:62 error: unresolved name `__test::main`.
    /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/test/run-pass/core-run-destroy.rs:58     green::start(argc, argv, rustuv::event_loop, __test::main)
                                                                                                                                                             ^~~~~~~~~~~~
    error: aborting due to 2 previous errors

    ------------------------------------------

    task '[run-pass] run-pass/core-run-destroy.rs' failed at 'explicit failure', /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/compiletest/runtest.rs:1321


---- [run-pass] run-pass/tcp-connect-timeouts.rs stdout ----

    error: compilation failed!
    status: exit code: 101
    command: x86_64-apple-darwin/stage2/bin/rustc /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/test/run-pass/tcp-connect-timeouts.rs -L x86_64-apple-darwin/test/run-pass --target=x86_64-apple-darwin -L x86_64-apple-darwin/test/run-pass/tcp-connect-timeouts.stage2-x86_64-apple-darwin.libaux -C prefer-dynamic -o x86_64-apple-darwin/test/run-pass/tcp-connect-timeouts.stage2-x86_64-apple-darwin --cfg rtopt --cfg debug -O -L x86_64-apple-darwin/rt --test
    stdout:
    ------------------------------------------

    ------------------------------------------
    stderr:
    ------------------------------------------
    /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/test/run-pass/tcp-connect-timeouts.rs:28:50: 28:62 error: failed to resolve. Use of undeclared module `__test`
    /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/test/run-pass/tcp-connect-timeouts.rs:28     green::start(argc, argv, rustuv::event_loop, __test::main)
                                                                                                                                                                 ^~~~~~~~~~~~
    /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/test/run-pass/tcp-connect-timeouts.rs:28:50: 28:62 error: unresolved name `__test::main`.
    /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/test/run-pass/tcp-connect-timeouts.rs:28     green::start(argc, argv, rustuv::event_loop, __test::main)
                                                                                                                                                                 ^~~~~~~~~~~~
    error: aborting due to 2 previous errors

    ------------------------------------------

    task '[run-pass] run-pass/tcp-connect-timeouts.rs' failed at 'explicit failure', /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/compiletest/runtest.rs:1321

Thoughts? (I take it these tests are explicitly designed to be run under the green scheduler?)

[alexcrichton]

Hm, that's interesting! The stdtest binary is also intended to run under the green scheduler by default (and rustuv I think).

That being said, the way all these binaries run the test harness under libgreen is a gross hack (as you're discovering).

Other possibilities might include:

• #![please_test_my_crate_with_librustuv]
  • This could tweak injecting extern crate native vs extern crate green.
  • This could pass a boolean flag to the main function of the test runner whether it should be native or green. The test runner would then spin up its own green pool.
• PLEASE_TEST_MY_CRATE_WITH_LIBRUSTUV=1 ./my-test-binary
  • This would work by the test runner spinning up its own green pool.
• ./my-test-binary --please-test-my-crate-with-librustuv
• #[call_top_level_function_with_relevant_test_arguments(my_main)]
  • Basically instead of calling test::test_main_static, the function __test::main would call my_main with the os arguments and TESTS static.
• #![disable_test_hygiene]
  • The hacks today would continue to work as-is.
• #![no_inner_test_mod]
  • This would inject the TESTS variable at the top level of a crate instead of in a hidden module. That way custom setup could be done before it's passed off to the test runner.

I'm not a fan of an environment variable or a command line flag because stdtest cannot succeed unless it's run with librustuv as the backend. This is kinda just a smattering of ideas, none of them make me feel comfortable really. I suppose the "sanest" one is #![disable_test_hygiene], but that is quite unfortunate!

[huonw]

I implemented a variation on #[disable_test_hygiene]: #![reexport_test_harness_main = "test_main"] will create a use test_main = __test::main (with the right gensyms) at the top of the crate, so one has access to the entrypoint via test_main (or whatever other symbol one choice).

r?

[alexcrichton]

linting may require that this need a license