-
Notifications
You must be signed in to change notification settings - Fork 13k
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
macro imports don't work when there are _two_ imported attributes #52525
Labels
A-macros
Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)
A-macros-1.2
Area: Declarative macros 1.2
C-bug
Category: This is a bug.
Comments
Manishearth
added
A-macros
Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)
C-bug
Category: This is a bug.
labels
Jul 19, 2018
Confirmed, this behavior is broken. Possibly related to #52226. @petrochenkov |
As a workaround specific to serde_derive, we allow multiple elements within one #[derive(Deserialize)]
#[serde(rename_all = "kebab-case", deny_unknown_fields)]
enum Foo {
A(u8)
} |
yeah, that's what I ended up doing
…-Manish Goregaokar
On Thu, Jul 19, 2018 at 12:17 AM David Tolnay ***@***.***> wrote:
As a workaround specific to serde_derive, we allow multiple elements
within one #[serde(...)] attribute.
#[derive(Deserialize)]
#[serde(rename_all = "kebab-case", deny_unknown_fields)]enum Foo {
A(u8)
}
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#52525 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABivSF1JPzq8S2-yOddn4qtf11a0DgvGks5uIDJ0gaJpZM4VV3H->
.
|
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Jul 19, 2018
This commit fixes an issue where multiple custom attributes could not be fed into a custom derive in some situations with the `use_extern_macros` feature enabled. The problem was that the macro expander didn't consider that it was making progress when we were deducing that attributes should be lumped in with custom derive invocations. The fix applied here was to track in the expander if our attribute is changing (getting stashed away elsewhere and replaced with a new invocation). If it is swapped then it's considered progress, otherwise behavior should remain the same. Closes rust-lang#52525
This should be fixed in #52539 |
kennytm
added a commit
to kennytm/rust
that referenced
this issue
Jul 20, 2018
rustc: Fix two custom attributes with custom derive This commit fixes an issue where multiple custom attributes could not be fed into a custom derive in some situations with the `use_extern_macros` feature enabled. The problem was that the macro expander didn't consider that it was making progress when we were deducing that attributes should be lumped in with custom derive invocations. The fix applied here was to track in the expander if our attribute is changing (getting stashed away elsewhere and replaced with a new invocation). If it is swapped then it's considered progress, otherwise behavior should remain the same. Closes rust-lang#52525
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-macros
Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)
A-macros-1.2
Area: Declarative macros 1.2
C-bug
Category: This is a bug.
This is the code you are supposed to use according to the
macro_use_extern_crate
lint.It fails to compile, with
It compiles fine if you use just one of the two attributes. Swapping attribute order makes it complain about the last non-derive attribute.
This seems broken?
cc @dtolnay @alexcrichton
The text was updated successfully, but these errors were encountered: