Update deps and derivation algorithm

[hcpl]

Fixes #2.

An updated version of rust-num/num#353 which includes suggestions outlined here and here:

• Update quote and syn to parse new Rust syntax;
• Update compiletest_rs to solve "every suggestion should have at least one span" Manishearth/compiletest-rs#86;
• Add support for arbitrary constant expressions as enum discriminants;
• Remove the need to extern crate num just for deriving.

Some notes:

• #[derive(FromPrimitive)] now uses if-else to do its job because non-literal expressions are not allowed for pattern matching.
• I added tests for self-containment of #[derive] alongside the code testing derivation functionality to keep the tests small. Would it be better to separate concerns?
• with_custom_value should have all three tests like trivial.

[hcpl]

compiletest_rs fails in current nightly: FnBox passed to TestFn::DynTestFn now takes no arguments.

Upstream PR to fix that: Manishearth/compiletest-rs#93.

[cuviper]

syn 0.12 and quote 0.4 were just released, which appear to be significant refactors.
https://users.rust-lang.org/t/syn-0-12-complete-redesign-for-all-your-macros-1-1-and-2-0-needs/14917

[hcpl]

@cuviper thanks! I've adapted the code to use new syn and quote versions.

I have a concern about using the "full" feature for syn though: it is now required to parse the Color enum from with_custom_values.rs (code breakage during syn 0.11 -> 0.12 migration with default features is discussed here), but increases the compilation time. Is being able to parse more complex expressions as enum values worth it?

[cuviper]

I have a concern about using the "full" feature for syn though: it is now required [...], but increases the compilation time.

Can you give me some numbers?

Is being able to parse more complex expressions as enum values worth it?

Unless it's extreme, then yes, I would lean in favor of functionality and accept the compilation time.

[dtolnay]

The "full" feature should not be enabled in num-derive because nothing in num-derive depends on it. If a downstream library wants to use Alpha = (-3 - (-5isize)) - 10 they can enable "full" and have it work without num-derive knowing about that.

Ordinarily I would expect libraries that are not already using "full" for other reasons will factor out the expression into a constant instead of paying in compile time.

+ const ALPHA: isize = (-3 - (-5isize)) - 10;

+ #[derive(ToPrimitive)]
  enum Color {
      Red,
      Blue = 5,
      Green,
-     Alpha = (-3 - (-5isize)) - 10,
+     Alpha = ALPHA,
   }

[cuviper]

@dtolnay

If a downstream library wants to use Alpha = (-3 - (-5isize)) - 10 they can enable "full" and have it work without num-derive knowing about that.

Wouldn't that suggestion make syn effectively a public dependency? If we later update to syn 0.13, such a downstream library would be broken until they update in kind.

I suppose num-derive could have its own feature which enables syn/full though.

[dtolnay]

Yeah you're right. An optional feature would work.

[hcpl]

@dtolnay

Can you give me some numbers?

In num-derive working directory:

• Without "full":

  $ time cargo build
     Compiling syn v0.12.7
     Compiling num-derive v0.1.41 (...)
      Finished dev [unoptimized + debuginfo] target(s) in 19.91 secs
  
  real	0m20.513s
  user	0m34.116s
  sys	0m1.532s
  

• With "full":

  $ time cargo build
     Compiling syn v0.12.7
     Compiling num-derive v0.1.41 (...)
      Finished dev [unoptimized + debuginfo] target(s) in 36.57 secs
  
  real	0m37.172s
  user	0m59.300s
  sys	0m2.200s
  

I suppose num-derive could have its own feature which enables syn/full though.

Good idea. I'll implement it under "full-syntax" name which is short and descriptive enough to me.

[cuviper]

Thanks, looks great!

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push

[cuviper]

Hmm, actually, cargo package doesn't allow any path declarations like this.