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

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

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

@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?

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.

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,
   }

@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.

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

@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.

Thanks, looks great!

bors r+

Build succeeded

• continuous-integration/travis-ci/push