deriving cleanup

[catamorphism]

• Hygiene
• Search for "__" strings
• Don't assume std is the standard library

(from a FIXME in syntax::ext::deriving)

[sanxiyn]

auto_serialize changed to auto_encode which changed to deriving(Encodable). FIXME is still there. I updated the issue accordingly.

[alexcrichton]

auto_serialize and auto_encode have migrated to deriving(Encodable) and deriving(Decodable).

The third bullet on this list is the same issue as #8242.

The first and second bullets are pretty much the same thing, @jbclements I saw you doing some stuff related to hygiene recently. Do you know if that work will "magically fix" this issue of creating code that can't conflict with user's variable names?

[steveklabnik]

Is this issue still relevant? There are still some __ strings, but I'm not sure what should actually be done to fix them.

[jbclements]

I'm guessing these __ identifiers are module-level bindings, right? We don't yet have hygiene for module-level identifiers.

[pnkfelix]

@jbclements ah that is good to know. Am I right in assuming that we want to try to put in hygiene for module level identifiers, and we just have not put in the machinery yet?

[alexcrichton]

triage: P-low

I believe most cleanup here has been done and the leftover __ are either implementation details or either aspects of hygiene which haven't been implemented yet, so I no longer think this is a backwards-compatibility problem for libraries.

[durka]

So I went through and looked at the __ strings throughout src/libsyntax_ext/deriving.

They fall into several categories:

1. function arguments (functions like PartialEq::eq, PartialCmp::partial_cmp, etc)
2. local bindings, either variables or match pattern captures
3. type parameters (__H for #[derive(Hash)], __S for #[derive(RustcEncodable)], __D for #[derive(RustcDecodable)])

I believe we can remove the __ from 1 and 2. There is no user code in these functions except for struct and field names, and shadowing those doesn't seem to break things: http://is.gd/5KyXSL expanded (though it does cause non_shorthand_field_patterns warnings)

For the type parameters unfortunately there is a risk of collision: http://is.gd/QYdfx5 expanded
However, it seems to me we could be doing better here: we could actually scan the list of type parameters and make a new one that can't collide.

Thoughts?