Uh oh!
There was an error while loading. Please reload this page.
Deprecate no_debug and custom_derive - #37128
Conversation
nrc
commented
Oct 12, 2016
bors
commented
Oct 13, 2016
☔ The latest upstream changes (presumably #37118) made this pull request unmergeable. Please resolve the merge conflicts. |
nikomatsakis
left a comment
There was a problem hiding this comment.
Looks good; left a few suggestions for improvement.
There was a problem hiding this comment.
Nit: probably we want:
"use of deprecated attribute: `{}`"// ^ ^ note ticksright?
There was a problem hiding this comment.
Also, let's link the deprecation to a tracking issue
There was a problem hiding this comment.
This follows the format for deprecated items. That probably should have back ticks too (added), but we don't have the tracking issue number anywhere so we can't link to it very easily.
There was a problem hiding this comment.
Well for deprecated items we give a reason, right? I imagined adding the issue number (or maybe just a string) to the Deprecated variant of Stability, in any case.
There was a problem hiding this comment.
Nit: this seems mega-inefficient...but probably it doesn't matter as there aren't that many attributes, and that table ain't that long, I guess?
There was a problem hiding this comment.
At minimum we could filter out the list of deprecations once rather than per attribute =)
There was a problem hiding this comment.
why exclude Stability from the Debug printout?
nrc
commented
Oct 18, 2016
@nikomatsakis changes made |
nrc
commented
Oct 18, 2016
More changes for review |
bors
commented
Oct 19, 2016
☔ The latest upstream changes (presumably #37269) made this pull request unmergeable. Please resolve the merge conflicts. |
nrc
commented
Oct 19, 2016
rebased |
nikomatsakis
commented
Oct 19, 2016
tidy errors: |
nikomatsakis
commented
Oct 19, 2016
r=me once tidy is fixed; thanks |
nrc
commented
Oct 19, 2016
@bors: r=nikomatsakis |
bors
commented
Oct 19, 2016
📌 Commit f6e0b3a has been approved by |
bors
commented
Oct 20, 2016
⌛ Testing commit f6e0b3a with merge 5694dd1... |
bors
commented
Oct 20, 2016
💔 Test failed - auto-win-gnu-32-opt-rustbuild |
nikomatsakis
commented
Oct 24, 2016
|
nrc
commented
Oct 25, 2016
bors
commented
Oct 25, 2016
📌 Commit 38f993f has been approved by |
bors
commented
Oct 25, 2016
Deprecate no_debug and custom_derive r? @nikomatsakis
bors
commented
Oct 25, 2016
💔 Test failed - auto-win-gnu-32-opt-rustbuild |
Ok that failure corresponds to a failure to free on Windows. That's terrifying! @bors: retry |
bors
commented
Oct 25, 2016
⌛ Testing commit 38f993f with merge 3c4de7f... |
bors
commented
Oct 25, 2016
💔 Test failed - auto-mac-64-opt |
alexcrichton
commented
Oct 25, 2016
@bors: retry |
nikomatsakis
commented
Oct 25, 2016
I'm inclined not to backport at this point. Not because it's harmful per se but just because we can just push deprecation back one cycle, so why not? What do you think @nrc? |
nrc
commented
Oct 25, 2016
@nikomatsakis yeah, it is getting kind of late into the cycle for a backport. |
nikomatsakis
commented
Oct 25, 2016
Removed beta-nominated tag: decided against backport. |
bors
commented
Oct 26, 2016
⌛ Testing commit 38f993f with merge 918bc3a... |
bors
commented
Oct 26, 2016
💔 Test failed - auto-linux-64-opt |
alexcrichton
commented
Oct 26, 2016
Hm that's two segfaults at the same location on two different platforms, maybe a legitimate segfault? |
nrc
commented
Oct 26, 2016
Dammit, Rust is not meant to segfault |
Has a custom deprecation since deprecating features is not supported and is a pain to implement
nrc
commented
Oct 27, 2016
bors
commented
Oct 27, 2016
📌 Commit 8c4a39c has been approved by |
bors
commented
Oct 27, 2016
Deprecate no_debug and custom_derive r? @nikomatsakis
bors
commented
Oct 27, 2016
nrc
commented
Oct 27, 2016
FTR r was nikomatsakis, not alexcrichton |
SergioBenitez
commented
Dec 11, 2016
I'd like to request that this deprecation be reverted, and I plan on submitting a PR to do so. This deprecation penalizes developers that write multiple types of syntax extensions instead of only custom derives, and it seems unnecessary while macros 2.0 are still some time away. At present, it is possible to have a single #![feature(plugin, custom_derive)]#![plugin(codegen_crate)]With this deprecation, however, this is no longer possible. The alternative, of course, is to use macros 1.1. But custom derives via macros 1.1 must be implemented in a separate crate of type #![feature(plugin)]#![plugin(codegen_crate)]#[macro_use]externcrate derive_crate;I believe this will lead to user confusion: syntax extensions are now coming from two different crates, and they must be imported via completely different mechanisms. While before a single declaration brought in all syntax extensions, now two different declarations are used to bring in syntax extensions. This is also significantly more unergonomic for the developer. This is because it is no longer feasible to easily share code between custom derives and other syntax extensions. The work-arounds are to have one create depend on the other, pushing logic to one "master" crate, or to create a third crate that contains the shared logic. Clearly, neither are as ergonomic as the existing implementation. All of this issues will likely be ameliorated by the unification macros 2.0 promises to bring. But macros 2.0 won't land in a nightly release any time soon, and they won't be stabilized until quite some time after that. So why deprecate this unnecessarily early? It penalizes developers that write multiple types of syntax extensions. We should keep this around until macros 2.0 are within reach of stabilization. |
r? @nikomatsakis