quickcheck_macros does not work on stable (or beta)

[burntsushi]

quickcheck_macros does not work on stable (or beta)

[BurntSushi]

Compiler plugins can only be used on Rust nightlies. There are no immediate plans to change this. quickcheck_macros is a crate that defines a compiler plugin.

quickcheck_macros is an optional convenience. There is nothing useless about the main crate quickcheck. There are plenty of examples here: https://github.com/BurntSushi/quickcheck/tree/master/examples

[russel]

I disagree #[quickcheck] being an optional convenience: if you are mixing example-based and property-based tests in the same file the documentation makes it appear essential to use this annotation. All the examples you point at are of free standing executables not of inputs to the standard test runner, which seems to back up my argument.

Of course QuickCheck is not useless, but the integration of the current system with the standard Rust test runner does appear to be since it relies on running nightlies. Companies will not run nightlies, they are unlikely to run beta, they will be running stable.

From your comment the problem is with the main Rust team who do not allow compiler plugins to run on stable. If this is the case then clearly the problem is there and that is what needs to be addressed.

[BurntSushi]

Here is an example in my link:

extern crate quickcheck;

use quickcheck::{TestResult, quickcheck};

fn reverse<T: Clone>(xs: &[T]) -> Vec<T> {
    let mut rev = vec!();
    for x in xs {
        rev.insert(0, x.clone())
    }
    rev
}

fn main() {
    fn prop(xs: Vec<isize>) -> TestResult {
        if xs.len() != 1 {
            return TestResult::discard()
        }
        TestResult::from_bool(xs == reverse(&*xs))
    }
    quickcheck(prop as fn(Vec<isize>) -> TestResult);
}

Here is the same example, but using #[test]:

extern crate quickcheck;

use quickcheck::{TestResult, quickcheck};

fn reverse<T: Clone>(xs: &[T]) -> Vec<T> {
    let mut rev = vec!();
    for x in xs {
        rev.insert(0, x.clone())
    }
    rev
}

#[test]
fn prop_reverse() {
    fn prop(xs: Vec<isize>) -> TestResult {
        if xs.len() != 1 {
            return TestResult::discard()
        }
        TestResult::from_bool(xs == reverse(&*xs))
    }
    quickcheck(prop as fn(Vec<isize>) -> TestResult);
}

The #[quickcheck] annotation removes some boiler plate. That's it. The transformation is straight forward.

From your comment the problem is with the main Rust team who do not allow compiler plugins to run on stable. If this is the case then clearly the problem is there and that is what needs to be addressed.

It is being addressed. But it's going to take time and lots of work. It's still early days, but you can probably get a good idea of progress/current state from this thread: https://internals.rust-lang.org/t/the-future-of-syntax-extensions-and-macros/2889/34

[BurntSushi]

To be clear, I use quickcheck in almost every single one of my published crates. I don't think I've ever used the #[quickcheck] annotation because I want to run things on Rust stable.

[russel]

I was clearly overthinking – or maybe that should be underthinking – this. Apologies. This now puts me on the right road.

That thread is interesting. Benchmarking definitely is a topic for me.

I suspect an article on quickcheck in Rust would go down very well indeed in CVu or Overload (the journals of ACCU). http://accu.org

[FranklinChen]

I was sad to lose the macro annotation, but have made do, e.g., in https://github.com/FranklinChen/type-directed-tdd-rust

Eek, just noticed my README is rather out of date.

[russel]

I think I should (so will) take this one to the forum: all the example use a function as parameter, does this imply you cannot use a closure?

[BurntSushi]

@russel I'm hesitant to say "cannot," but I can say, "I haven't figured out how yet." The pertinent issue is #56. I used to think I couldn't do it because of this bug in rustc, but it seems that it's not actually a bug.

[russel]

@BurntSushi If you are having difficulties, I am unlikely to fair better. Doing some compile time code generation with macros looks like the only way to solve the closure thing for me. I posted on the forum, but it sounds as the answer is already known to be "not at the moment".

[BurntSushi]

@russel Possibly, although fresh eyes definitely couldn't hurt!