Fields aren't renamed by default

[Gaming32]

This can produce some very invalid code.

test.jar

[Gaming32]

I don't think they should be renamed to field_n though, but rather made to be valid. So for example, `jEk@4|i_#Fk?(8x)AV_-my variable would become _jEk_4_i__Fk__8x_AV__my_variable and then that could be deduplicated somehow.

[l-Luna]

or perhaps replacing e.g. @ with $at$? it'd be verbose, but unique assuming the source doesn't contain dollar signs; and those can be expanded to $$ or similar anyways

[Gaming32]

There's a lot more than just @ that's invalid in a Java identifier here though.

[l-Luna]

you can do the same thing for other invalid tokens, e.g. $backtick$, $hash$... hence the "e.g."

[Geolykt]

I'd avoid the usage of dollar signs because they tend to be used for synthetic members. But then there aren't that many other characters the JLS considers as valid that would be sensical for this usage

[Gaming32]

QF already uses underscores exactly like how I described for method names btw.

[Gaming32]

For example:

public int h_1S_h_YQ_xTiT_oj_od/* $QF was: h`1S)h_YQ_xTiT^oj,od*/(int var1) {
    ScratchABI.say(this, "Hello, world!");
    return -1;
}

If fields and classes are made to use escapes like $backtick$, then methods should get the same treatment.

[SilverAndro]

Im not sure the dollar sign option is a good idea, you could pretty easily craft a method thats just, unreadably long when renamed

Something like \\\\\\\\\\\\ would become $backslash$$backslash$$backslash$$backslash$$backslash$$backslash$$backslash$$backslash$$backslash$$backslash$$backslash$$backslash$ (assuming I counted right)

[l-Luna]

if you're trying to make a long method name, there's nothing stopping your from writing a long method name. underscoring characters is even worse given malicious input, since they could name every method some single special character and cause a lot of conflicts (assuming we don't take further steps to ensure uniqueness). it's the difference between _1, _2, __... and $slash$, $backslash$, $colon$$colon$... (the last of which is a real scala stdlib type iirc?)

[lenrik1589]

I want to expand on this issue: any unicode name is not handled correctly, as such

abstract class `wonder full`(val `поле`){
  open fun `… in unicode???`()
}

compiled from kotlin will produce valid bytecode and will run just fine, however quiltflower does not check names in many places and for example all calls to … in unicode??? will have literally … in unicode??? as the identifier in java, which is syntactically invalid