Regression in fxsm, Rust 1.17

[brson]

https://github.com/vityafx/fxsm

brian@ip-10-145-43-250:~/dev/fxsm⟫ git log -1
commit 9e51313cddea3172527ca90abd2bab71cc5ad537
Author: Victor Polevoy <vityatheboss@gmail.com>
Date:   Wed Mar 1 18:30:31 2017 +0400

    Update README.md

brian@ip-10-145-43-250:/mnt2/dev⟫ rustc +beta -Vv
rustc 1.17.0-beta.1 (408d49e60 2017-03-14)
binary: rustc
commit-hash: 408d49e6087f87371e96277c5ff428fa22cb84e6
commit-date: 2017-03-14
host: x86_64-unknown-linux-gnu
release: 1.17.0-beta.1
LLVM version: 3.9

101 brian@ip-10-145-43-250:~/dev/fxsm⟫ cargo +beta test
   Compiling unicode-xid v0.0.4
   Compiling quote v0.3.14
   Compiling fxsm v0.2.0 (file:///mnt2/dev/fxsm/fxsm)
   Compiling synom v0.11.2
   Compiling syn v0.11.8
   Compiling fxsm-derive v0.2.0 (file:///mnt2/dev/fxsm/fxsm-derive)
   Compiling fxsm-test v0.1.0 (file:///mnt2/dev/fxsm)
error: proc-macro derive panicked
 --> examples/game_cup.rs:6:24
  |
6 | #[derive(Clone, Debug, StateMachine)]
  |                        ^^^^^^^^^^^^
  |
  = help: message: How were you able to call me without derive!?!?

error: Could not compile `fxsm-test`.
Build failed, waiting for other jobs to finish...
error: build failed

cc @vityafx

[iddm]

Yes, I know that. Thank you very much for highlighting me, I appreciate it! You guys do very nice work testing the beta on crates! I will fix it soon. Is there anything I should do in this issue?

[brson]

@vityafx Nope! Just making you aware. If you determine this is our bug, please let us know the details.

[nikomatsakis]

Glancing briefly at the code, the error arises because the code fails to find a #[derive] attribute on the enum to which it is applied. It is trying to peek and see that Copy and Clone are also derived.

cc @jseyfried -- do you know of any changes we made in this area, i.e., in terms of what tokens we supply to derive implementations?

@vityafx -- another way to enforce this, though UI will suffer, would be to generate code that requires Copy and Clone, at worst by artificially calling something like

fn require_copy_and_clone<T: Copy+Clone>(t: &T) { }

[iddm]

@nikomatsakis yes, I know that too. There was a change which makes impossible to see what does the enum/struct derive but fxsm relies on this for determination of what code to produce - one which uses Copy or one which uses Clone. I have totally forgot about what Copy and Clone are, so after some discussion in rust issues page, I have been told to provide only implementation for a Clone because Copy is just a marker. So this may simply be rewritten correctly. I just have not been able to find the time for this yet unfortunately.

[jseyfried]

This was intentionally caused by #39572. See #40574 (comment) and #40574 (comment) for rationale; #39572 (comment) is an alternative.

cc @rust-lang/lang

[nikomatsakis]

@jseyfried interesting; I'll have to catch up in more depth. It seems like it is common to want to "peek" at what other derives are present, so that you can generate somewhat better/different derives for your own trait. It's not perfect, though, since of course there could be manual impls...

[nikomatsakis]

@vityafx ok I agree that the current thing in your particular case is to generate code that uses foo.clone().

[pnkfelix]

discussed at compiler meeting. Consensus is that if there is a bug here, it is in fact a feature request for the procedural macro system (the feature being having a way to peek at the other derives), and that would be the balliwick of the lang team to address.

So, removing T-compiler label. (And also suggesting that the lang team close after reviewing it.)