deriving cleanup #2810
Comments
|
|
|
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? |
|
Is this issue still relevant? There are still some |
|
I'm guessing these |
|
@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? |
|
triage: P-low I believe most cleanup here has been done and the leftover |
|
So I went through and looked at the They fall into several categories:
I believe we can remove the For the type parameters unfortunately there is a risk of collision: http://is.gd/QYdfx5 expanded Thoughts? |
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).
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).
cleanups and fixes for #[derive] This contains a bunch of little cleanups and fixes to `#[derive]`. There are more extensive comments on each individual commit. - hygiene cleanups - use `discriminant_value` instead of variant index in `#[derive(Hash)]` - ~~don't move out of borrowed content in `#[derive(PartialOrd, PartialEq)]`~~ - use `intrinsics::unreachable()` instead of `unreachable!()` I don't believe there are any breaking changes in here, but I do want some more eyes on that. Fixes rust-lang#2810 (!), I believe (we still assume that "std" or "core" is the standard library but so does the rest of rustc...). Fixes rust-lang#21714 (cc @apasel422). ~~Fixes~~ (postponed) rust-lang#24047 (cc @withoutboats @bluss). Fixes rust-lang#31714 (cc @alexcrichton @bluss). Fixes rust-lang#31886 (cc @oli-obk).
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).
cleanups and fixes for #[derive] This contains a bunch of little cleanups and fixes to `#[derive]`. There are more extensive comments on each individual commit. - hygiene cleanups - use `discriminant_value` instead of variant index in `#[derive(Hash)]` - ~~don't move out of borrowed content in `#[derive(PartialOrd, PartialEq)]`~~ - use `intrinsics::unreachable()` instead of `unreachable!()` I don't believe there are any breaking changes in here, but I do want some more eyes on that. Fixes #2810 (!), I believe (we still assume that "std" or "core" is the standard library but so does the rest of rustc...). Fixes #21714 (cc @apasel422). ~~Fixes~~ (postponed) #24047 (cc @withoutboats @bluss). Fixes #31714 (cc @alexcrichton @bluss). Fixes #31886 (cc @oli-obk).
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).
derive: clean up hygiene derive: clean up hygiene Fixes #2810. Spawned from #32139. r? @alexcrichton
When newline_style is set to Windows, an empty line inside of a macro results in `\r` being passed to the `fold()` in `MacroBranch::rewrite()`. `\r` is technically not an empty string, so we try to indent it, leaving trailing whitespaces behind, even though that was not intended (as far as I can see). This commit replaces the `!l.is_empty()` check with calling `is_empty_line()`, since trying to indent any whitespace-only string will probably result in problematic trailing whitespaces. Fixes: rust-lang#2810
Try to fix formatting failures on Windows (issue rust-lang#2810)
stdis the standard library(from a FIXME in
syntax::ext::deriving)The text was updated successfully, but these errors were encountered: