Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

quickcheck_macros does not work on stable (or beta) #112

Closed
russel opened this issue Dec 3, 2015 · 10 comments
Closed

quickcheck_macros does not work on stable (or beta) #112

russel opened this issue Dec 3, 2015 · 10 comments

Comments

@russel
Copy link

russel commented Dec 3, 2015

Using stable Rust trying to install quickcheck_macros gives:

Compiling quickcheck_macros v0.2.24
/home/users/russel/.cargo/registry/src/github.com-0a35038f75765ae4/quickcheck_macros-0.2.24/src/lib.rs:8:1: 8:45 error: #[feature] may not be used on the stable release channel
/home/users/russel/.cargo/registry/src/github.com-0a35038f75765ae4/quickcheck_macros-0.2.24/src/lib.rs:8 #![feature(plugin_registrar, rustc_private)]

which more or less makes this potentially wonderful testing tool useless. Or have I missed something?

@BurntSushi
Copy link
Owner

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
Copy link
Author

russel commented Dec 3, 2015

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
Copy link
Owner

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
Copy link
Owner

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
Copy link
Author

russel commented Dec 3, 2015

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
Copy link

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
Copy link
Author

russel commented Dec 3, 2015

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
Copy link
Owner

@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
Copy link
Author

russel commented Dec 3, 2015

@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
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants