#[test] items are not being configured out in a non-test build

[marijnh]

They probably should. They could refer to things configured with #[cfg(test)], and will cause resolve errors when those are configured out.

[brson]

It's probably intuitive to do this, but there are two reasons I didn't implement it.

1. There's already a mechanism for this (cfg attributes)
2. I can imagine a situation where you would want to both compile in the tests and not compile the crate as a test-runner. For example, an application might want to be able to run its own tests for diagnostic purposes.

[marijnh]

Right, but writing #[test]#[cfg(test)] seems awkwardly redundant. For 2), which seems rare to me, it would be trivial to factor the tests into a non-#[test] function and call them both from a #[test] function and from some other part of the program.

[brson]

This is why all of the tests in rustc live in #[cfg(test) mod test { ... }. As it stands, for 2 you can just grab the vector of tests and call std::test::run_tests, no extra work required.

Furthermore, I hope to build more sophisticated test frameworks on top of this one and you'll want to be able to build the test without building the test runner (then use reflection to dig out the tests).

But we can cross that bridge when it comes, and I'm not opposed to #[test] implying #[cfg(test)].

[marijnh]

Well, seems you've thought this through. I don't think this is that important -- I just thought it looked like an oversight. Closing this issue.

[brson]

I'd like to leave it open. It's a worthy idea and it might yet be the right behavior.

[brson]

Finally changed my mind. Implemented in c2c497f.