Fix renaming enum variants starting with digits #2905
Conversation
| "__EmptyString".to_string() | ||
| } else if v.chars().next().map(char::is_numeric).unwrap_or(false) { | ||
| if v.chars().any(|c| !c.is_numeric() && !c.is_alphabetic() && c != '_' && c != '-' && c != ' ') { | ||
| "".to_string() |
There was a problem hiding this comment.
I think this should be moved to __EmptyString and update the warning message.
There was a problem hiding this comment.
Thanks for the review! Yeah this is a confusing case. to_upper_camel_case removes invalid chars, so a field like "/" is remapped to "". In order to preserve existing behavior for variants starting with a digit, we have to strip chars manually if they are not valid.
Empty strings are then converted to UTF-8 encoding in the next block. So, "0/" is remapped to "U0030U002F". I agree that the flow is pretty hard to follow now though.
We could replace this check with format!("_{}", v.to_upper_camel_case()). However, this would map 0A-B-C to _0aBC instead of _0ABC.
There was a problem hiding this comment.
Oh, that's really confusing. Could you refactor this to make the control flow clearer?
There was a problem hiding this comment.
Or add a comment explaining that Unicode characters will be handled below.
There was a problem hiding this comment.
I've refactored the control flow, hopefully it's easier to follow now
Signed-off-by: Agni <a@a4n1.com>
a4n1
force-pushed
the
push-utssrpnwlyox
branch
from
6181288 to
a9cb7c8
Compare
Signed-off-by: Agni <a@a4n1.com>
a4n1
force-pushed
the
push-utssrpnwlyox
branch
from
f73d402 to
7cbf791
Compare
|
|
||
| if v | ||
| .chars() | ||
| .any(|c| !c.is_alphanumeric() && c != '_' && c != '-' && c != ' ') { |
2 participants
PR Info
Bug Fixes