Organizing benching code

[behnam]

In unic-bidi (and going back to the source unicode-bidi crate), I had added bench_it feature to not run benching on every single test run.

In travis.yml, benching is only run once and on the nightly rustc.

I think we did this because #[bench] was not stable yet. I think it's got stabilized now. Is that so?

Also, it is common to have simple data-less benches inside the modules, like unit tests, and not as an integration thing. Should we do this, or not?

[CAD97]

For code in the benches folder, the bench_it feature is pointless because it's only compiled and run when you use cargo bench.

Benchmarks are unstable (rust-lang/rust#29553) because extern crate test requires a feature gate.

Without another gating feature, you cannot test on stable if you have #![cfg_attr(test, feature(test))].

(Somewhat surprisingly, #[cfg(bench)] doesn't complain. But it also doesn't enable when you do cargo bench like #[cfg(test)] does when you do cargo bench. Something to propose if stdlib benchmarks start moving towards stabilization.)

Personally, I feel #[bench] tests should be confined to just being run with cargo bench. But definitely, if benchmarks are only run with cargo bench (which only looks in the benches/ directory), the feature is not needed.

[behnam]

As you said, I believe there's no plan to have cfg(bench), and benches are considered part of cfg(test).

And, along the same line, I think all files under benches/ are built and run with cargo test, as well. I believe that was the reason I had to gate my benches with a feature, to only run on nightly, otherwise they would break a stable cargo test.

[CAD97]

Well, if it was before, it's not anymore. unic-char-range has a benches directory with benchmarks and no benchmarking feature.

[behnam]

Cool! If it works fine in rustc:1.17.0, we can drop the branch. I'll take care of it soon.