Unsafe identifier renames

[j4k0xb]

Minifiers only rename variable/function/parameter bindings and not any other identifier like properties because it's almost impossible to guarantee the program still works then.

Example input file:

class A {
  get() {
    return document.querySelector("#foo");
  }
}

humanify output:

class MyClass {
  getElementById() {
    return dom.findElement("#foo");
  }
}

I think thats the only change necessary but it needs some testing:

humanify/src/openai/rename-variables-and-functions.ts

Line 16 in 4dfe05e

Identifier: (path) => {

- Identifier: (path) => { 
+ BindingIdentifier: (path) => { 

Or how about renaming all variables to something unique so it doesn't mix up minified ones and then supplying a list of binding names it is allowed to change in the prompt?

Also it can happen that a variable gets renamed but another one with the same name already exists in the scope, or the code gets split up in such a way that not all references are renamed.
Maybe use babel's scope-aware rename that also handles these conflicts (have to find a way of getting rid of the _ prefix): https://astexplorer.net/#/gist/7283141e13dab314521744603a95e9b7/05b11370db8d5ef257550b2916b87d6e72e4eb1d

[0xdevalias]

Or how about renaming all variables to something unique so it doesn't mix up minified ones and then supplying a list of binding names it is allowed to change in the prompt?

I've laid out some of my thoughts on this concept in general, in the following issues/comments:

• rename short identifiers j4k0xb/webcrack#21 (comment) (and my later comments)
• support un-mangle identifiers pionxzh/wakaru#34 (comment) (and my later comments)

Also it can happen that a variable gets renamed but another one with the same name already exists in the scope, or the code gets split up in such a way that not all references are renamed.

Off the top of my head, if it's not easily solved via tweaking the prompt, you could potentially have it do a 'refinement/feedback round' where you provide feedback to the LLM + get it to correct the issues (which could be repeated up to X times) eg.

The following variables were already defined in the scope, so we can't use the names you chose. Please choose a new name for them so that they don't clash:

• X
• Y
• Z

[j4k0xb]

copilot now has a similar feature: https://code.visualstudio.com/updates/v1_87#_rename-suggestions
worth looking into how they've done it

[0xdevalias]

Release detailed here:

• https://github.com/microsoft/vscode/releases/tag/1.87.0
  • microsoft/vscode@1.87.0...1.86.2

Couldn't see any overly relevant commits in that range, but did find the following searching the issue manually:

• Rename suggestions UX overhaul microsoft/vscode#206335
• Rename suggestions not work !  microsoft/vscode#206498

Which lead me to this label:

• https://github.com/microsoft/vscode/issues?q=is%3Aopen+label%3Arename+sort%3Aupdated-desc

And these issues, which sound like there are 'rename providers' used by the feature:

• No way to ensure an extension is prioritized as a rename provider in a language microsoft/vscode#115354
• Rename providers of several extensions conflict and there is no way to know WHAT it being renamed microsoft/vscode#183075

More docs about rename providers here:

• https://code.visualstudio.com/docs/editor/editingevolved#_rename-symbol
• https://code.visualstudio.com/api/references/vscode-api#:~:text=registerRenameProvider(
• https://code.visualstudio.com/api/references/vscode-api#RenameProvider

  • RenameProvider
    The rename provider interface defines the contract between extensions and the rename-feature.

  • prepareRename
    Optional function for resolving and validating a position before running rename. The result can be a range or a range and a placeholder text. The placeholder text should be the identifier of the symbol which is being renamed - when omitted the text in the returned range is used.

  • provideRenameEdits
    Provide an edit that describes changes that have to be made to one or many resources to rename a symbol to a different name.

• https://code.visualstudio.com/api/language-extensions/programmatic-language-features
  • https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_prepareRename

    • Prepare Rename Request (:leftwards_arrow_with_hook:)
      The prepare rename request is sent from the client to the server to setup and test the validity of a rename operation at a given location.

  • https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_rename

  • Rename Request
    The rename request is sent from the client to the server to ask the server to compute a workspace change so that the client can perform a workspace-wide rename of a symbol.

• https://vshaxe.github.io/vscode-extern/vscode/RenameProvider.html
• https://github.com/vshaxe/vscode-extern/blob/master/src/vscode/RenameProvider.hx

Based on the above, and the release notes explicitly mentioning copilot, I suspect the implementation will be in the Copilot extension itself (which isn't open-source):

• https://marketplace.visualstudio.com/items?itemName=GitHub.copilot
  Downloading that gives GitHub.copilot-1.168.741.vsix, which seems to just be a .zip file:

⇒ file GitHub.copilot-1.168.741.vsix

GitHub.copilot-1.168.741.vsix: Zip archive data, at least v2.0 to extract, compression method=deflate

Though unzipping that and searching for provideRename didn't seem to turn up anything useful unfortunately; so not sure if that means it's not implemented in the copilot extension, it doesn't use VSCode's 'rename provider' API, or I just wasn't looking right.

[isidorn]

Hi VS Code PM here,

A team member pointed me to this issue because it links to one of our VS Code issues.

I wanted to share that reverse engineering GitHub copilot is violating the general terms of the use agreement https://github.com/customer-terms/general-terms

Feel free to reach out to me if I can help with the general terms clarification [email protected]

Thank you
Isidor

[0xdevalias]

@isidorn It's less about "reverse engineering GitHub copilot" and more about "trying to figure out where the 'rename suggestions' change mentioned in the VSCode release notes was actually implemented; and what mechanism 'integrates' it into VSCode'".

The above is assumptions + an attempt to figure that out; but if you're able to point me to the actual issue/commit on the VSCode side (assuming it was implemented there), or confirm whether it's implemented on the closed source GitHub Copilot extension side of things (if it was implemented there), that would be really helpful.

If it was implemented on the GitHub Copilot extension side of things, then confirming whether the VSCode extension 'rename provider' is the right part of the VSCode extension API to look at to implement a similar feature would be awesome.

[ulugbekna]

Thank you for taking interest in this API. The rename suggestions feature is powered by a proposed API defined here. Extensions provide the suggestions, while the vscode shows them in the rename widget.

[0xdevalias]

@ulugbekna Awesome; thanks for pointing that out! Shall have a closer read :)

Edit: See also:

• https://github.com/search?q=repo%3Amicrosoft%2Fvscode%20NewSymbolNamesProvider&type=code

[sagarika-fynd]

I renamed all variables to unique names, and then ran the unminify code, most of the stuff was unminified, but i still had some random code, which wasnts, so i added a check to only rename variables which are in the pattern of my naming convention, and instructed the same to GPT, had to run this a few times, but it made sure sancity of previous naming convention was maintained

[0xdevalias]

Also it can happen that a variable gets renamed but another one with the same name already exists in the scope, or the code gets split up in such a way that not all references are renamed.

See also:

• Expand reserved Keywords list for renaming variables or functions #20
• Error while renaming a variable. (TypeError: Duplicate declaration) #67

---

Semi-related:

• More deterministic renames across different versions of the same code #97

[0xdevalias]

Also it can happen that a variable gets renamed but another one with the same name already exists in the scope, or the code gets split up in such a way that not all references are renamed.

Off the top of my head, if it's not easily solved via tweaking the prompt, you could potentially have it do a 'refinement/feedback round' where you provide feedback to the LLM + get it to correct the issues (which could be repeated up to X times) eg.

The following variables were already defined in the scope, so we can't use the names you chose. Please choose a new name for them so that they don't clash:

• X
• Y
• Z

Just made a similar suggestion for this pattern while debugging another issue, referencing it here for continuity:

The proper fix would be to use toIdentifier from @babel/types

@j4k0xb @jehna From a 2sec search I couldn't find rendered docs, but here's the relevant source for each:

• isValidIdentifier: https://github.com/babel/babel/blob/a2025d7d695b0f3b0506f66225d6b15bcfa1cf6a/packages/babel-types/src/validators/isValidIdentifier.ts#L7-L25
• toIdentifier: https://github.com/babel/babel/blob/a2025d7d695b0f3b0506f66225d6b15bcfa1cf6a/packages/babel-types/src/converters/toIdentifier.ts#L4-L26

toIdentifier definitely seems like a more robust approach than the current 'prefix with _' approach for sure.

Though I wonder if a 'proper fix' should also involve tweaking how we prompt for/filter the suggestions coming back from the LLM itself as well. Like instead of just forcing an invalid suggestion to be valid (with toIdentifier), we could detect that it's invalid (with isValidIdentifier) and then provide that feedback to the LLM, asking it to give a new suggestion; probably with some max retry limit; after which we could fall back to using the invalid suggestion run through toIdentifier, or log a warning and leave it un-renamed or similar.

Originally posted by @0xdevalias in #117 (comment)

[jehna]

Using BindingIdentifier instead of Identifier now, thanks for reporting this! Closing for now, should be fixed