parse doc comments and visibiliy specifier

[colin-kiegel]

implementation according to #13 (comment)

@killercup Seems to work just fine, but it's a delicate / complex macro. At leas a review seems adequate - and we haven't really decided yet.

[colin-kiegel]

PS: current behaviour is 'unexpected token', which could be classified as a bug and is fixed by this PR.

[killercup]

Sorry, I'm a bit out of the loop on this—disregard anything that's totally
obvious once I properly look at this.

What are you aiming for with this? Where do you want to skip doc/vis? Can
you add some tests for this change? (Did we add macro-compile tests yet to
compare the expanded tokens? If not, we should probably do that. Should be
possible with static-cond.)

Colin Kiegel notifications@github.com schrieb am So., 7. Aug. 2016 um
23:27 Uhr:

PS: current behaviour is 'unexpected token', which could be classified as
a bug and is fixed by this PR.

—
You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub
#14 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABOX-cX8AvO6xVm4wnClMvpw-h_8eNpks5qdk2ygaJpZM4Jek33
.

[colin-kiegel]

this allows public and/or annotated struct fields, by just skipping over
these tokens. The current parser errors with unexpected token in these
cases.

will add a test for this and I might try to combine these matchers to save
iterations. :-)

PS: I was thinking about testing expanded tokens too.

Pascal Hertleif notifications@github.com schrieb am Fr., 12. Aug. 2016,
14:56:

Sorry, I'm a bit out of the loop on this—disregard anything that's totally
obvious once I properly look at this.

What are you aiming for with this? Where do you want to skip doc/vis? Can
you add some tests for this change? (Did we add macro-compile tests yet to
compare the expanded tokens? If not, we should probably do that. Should be
possible with static-cond.)

Colin Kiegel notifications@github.com schrieb am So., 7. Aug. 2016 um
23:27 Uhr:

PS: current behaviour is 'unexpected token', which could be classified as
a bug and is fixed by this PR.

—
You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub
<
#14 (comment)
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AABOX-cX8AvO6xVm4wnClMvpw-h_8eNpks5qdk2ygaJpZM4Jek33

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#14 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHVbslB5UPPGYtoOUB5NRuEyZIfghbE9ks5qfG2VgaJpZM4Jek33
.

[colin-kiegel]

Ok, I did this:

• rebased to master
• some additional refactoring / simplification
• and last but not least a new feature: all field attributes now map to setter functions

Still work in progress (obviously)

• Travis is failing on stable + beta (I tested only with nightly). Will have a look.
• I am still thinking we should start with whitelisting specific attributes, to be on the safe side (IF that is possible).

PS: I splitted my changes into a history of rather small commits.

[colin-kiegel]

I introduced whitelisting of attributes, only these will be added to setter-fns

• #[doc = ...]
• #[cfg(...)]
• #[allow(...)]

If there is demand, we could add these in the future, but I guess they probably make little sense in these positions

• #[deny(...)]
• #[forbid(...)]
• #[warn(...)]

All current attributes are listed here. IMO the rest of them doesn't make sense for setter-fns.
https://doc.rust-lang.org/reference.html#attributes

[colin-kiegel]

PS: I also re-ordered most of the arguments to introduce @foo as first tokens in recursive calls (where foo = current_state_of_macro, e.g. @parse).

[colin-kiegel]

PPS: If we go along this road, next thing might be to parse and filter the struct-attributes and transfer them to the impl too (candidates again doc+allow, but cfg probably not needed). However I wonder if parsing struct-attributes would survive a possible transition to procedural macros 1.1. Therefore we might wait until then before we do it.

[colin-kiegel]

@killercup undid the rebase which caused the trouble - ready for review