Skip to content
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

derive: clean up hygiene #32251

Merged
merged 3 commits into from Mar 15, 2016
Merged

derive: clean up hygiene #32251

merged 3 commits into from Mar 15, 2016

Conversation

@durka
Copy link
Contributor

@durka durka commented Mar 14, 2016

derive: clean up hygiene

Fixes #2810.

Spawned from #32139.

r? @alexcrichton

durka added 2 commits Mar 7, 2016
This replaces some `if`s with `match`es. This was originally not possible
because using a global path in a match statement caused a "non-constant
path in constant expr" ICE. The issue is long since closed, though you still
hit it (as an error now, not an ICE) if you try to generate match patterns
using pat_lit(expr_path). But it works when constructing the patterns more
carefully.
This changes local variable names in all derives to remove leading
double-underscores. As far as I can tell, this doesn't break anything
because there is no user code in these generated functions except for
struct, field and type parameter names, and this doesn't cause shadowing
of those. But I am still a bit nervous.
When deriving Hash, RustcEncodable and RustcDecodable, the syntax extension
needs a type parameter to use in the inner method. They used to use __H, __S
and __D respectively. If this conflicts with a type parameter already declared
for the item, bad times result (see the test). There is no hygiene for type
parameters, but this commit introduces a better heuristic by concatenating the
names of all extant type parameters (and prepending __H).
@durka durka force-pushed the durka:derive-2810 branch from c59400c to 8355389 Mar 14, 2016
@alexcrichton
Copy link
Member

@alexcrichton alexcrichton commented Mar 14, 2016

@bors
Copy link
Contributor

@bors bors commented Mar 15, 2016

Testing commit 8355389 with merge 3f5db0e...

bors added a commit that referenced this pull request Mar 15, 2016
derive: clean up hygiene

derive: clean up hygiene

Fixes #2810.

Spawned from #32139.

r? @alexcrichton
@alexcrichton
Copy link
Member

@alexcrichton alexcrichton commented Mar 15, 2016

@bors: retry force clean

@bors
Copy link
Contributor

@bors bors commented Mar 15, 2016

Testing commit 8355389 with merge 1efa752...

bors added a commit that referenced this pull request Mar 15, 2016
derive: clean up hygiene

derive: clean up hygiene

Fixes #2810.

Spawned from #32139.

r? @alexcrichton
@bors bors merged commit 8355389 into rust-lang:master Mar 15, 2016
2 checks passed
2 checks passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
@Manishearth
Copy link
Member

@Manishearth Manishearth commented Mar 16, 2016

This broke warnings:

#![deny(warnings)]

#[derive(Hash)]
struct Foo;

fn main() {}

will now throw a warning/error about an unused argument. Please keep the __s in derive, they're there for a reason.

@durka
Copy link
Contributor Author

@durka durka commented Mar 16, 2016

Bleh, you're right. The reason was assumed to be hygiene, but it's also
unused arguments/variables. It would be more conventional to have one
underscore, I guess. I can make that change or we can just revert this.

On Wed, Mar 16, 2016 at 2:41 PM, Manish Goregaokar <notifications@github.com

wrote:

This broke warnings:

#![deny(warnings)]
#[derive(Hash)]struct Foo;
fn main() {}

will now throw a warning/error about an unused argument. Please keep the
__s in derive, they're there for a reason.


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#32251 (comment)

@Manishearth
Copy link
Member

@Manishearth Manishearth commented Mar 16, 2016

Yep. Double underscore is slightly better IMO since clippy uses that to distinguish between things that are silenced because they may be unused (e.g. when they come from a macro), and things which are known to be unused. But single underscore is also ok.

@Manishearth
Copy link
Member

@Manishearth Manishearth commented Mar 16, 2016

See #32292

@Manishearth
Copy link
Member

@Manishearth Manishearth commented Mar 16, 2016

Should the fix just re-add underscores to the idents introduced in this PR? I'm not entirely sure if that's all that needs to be done.

@durka
Copy link
Contributor Author

@durka durka commented Mar 16, 2016

Yeah, I should just re-add double underscores I think. The other improvements in this PR are turning an if-else into match (was a FIXME in the code) and making it harder for the derived type parameter to cause a collision, neither of which are critical.

@Manishearth
Copy link
Member

@Manishearth Manishearth commented Mar 16, 2016

Cool. I'm working on it.

@durka
Copy link
Contributor Author

@durka durka commented Mar 16, 2016

Oh okay, well thanks for cleaning up my mess :)

On Wed, Mar 16, 2016 at 2:51 PM, Manish Goregaokar <notifications@github.com

wrote:

Cool. I'm working on it.


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#32251 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants