Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Dec 4, 2025

  • Explore the codebase and understand the rename flow
  • Review TypeScript implementation
  • Implement simplified validation approach
  • Localize error messages properly
  • Fix format string bug in error creation
  • Resolve test regressions (awaiting feedback)

Current Status

Implemented validation in handleRename that returns a properly localized error when renaming invalid targets.

Changes:

  • Added nodeIsEligibleForRename() for basic node type validation
  • Updated ProvideSymbolsAndEntries() to check eligibility of adjusted nodes
  • Modified ProvideRenameFromSymbolAndEntries() to return localized error for ineligible renames
  • Fixed error message to use locale.FromContext(ctx) and .Localize() for proper localization
  • Fixed bug: Use errors.New() instead of fmt.Errorf() to avoid treating localized message as format string

Note:

Some fourslash tests are failing because they expect empty results (no changes) but now receive errors. Awaiting clarification on whether to:

  1. Keep error-based approach and update tests
  2. Revert to prepareRename for better UX (tooltip vs error notification)
Original prompt

This section details on the original issue you should resolve

<issue_title>Should not allow renaming keywords</issue_title>
<issue_description>TS-go will allow triggering rename anywhere in the file, including on parens and keywords. When you press enter it will then either try doing a rename or say no result

Instead we should fail the rename early. Here's what happens in TS 6

Image

I believe this warning comes from the prepareRename call</issue_description>

<agent_instructions>Look at the submodule's rename code to guide this; this should already have been implemented there.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@mjbvz In 6.0 we do allow triggering renames on `class` and similar keywords but this shifts the rename to the class name instead

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

Copilot AI self-assigned this Dec 4, 2025
Copilot AI and others added 2 commits December 4, 2025 22:23
- Add nodeIsEligibleForRename function to check if a node can be renamed
- Implement ProvidePrepareRename in language service
- Add handlePrepareRename handler in LSP server
- Update RenameProvider capability to indicate prepareProvider support
- Handle keyword adjustments and eligibility checks

Co-authored-by: jakebailey <[email protected]>
- Update ProvideSymbolsAndEntries to check node eligibility after adjustment
- Add test for prepareRename on keywords
- Format code

Co-authored-by: jakebailey <[email protected]>
Copilot AI changed the title [WIP] Fix issue with renaming keywords in TS-go Implement prepareRename to prevent renaming keywords Dec 4, 2025
Copilot AI requested a review from jakebailey December 4, 2025 22:34
Copilot finished work on behalf of jakebailey December 4, 2025 22:34

// ProvidePrepareRename provides information for rename preparation.
// This checks if the location is eligible for renaming and returns the range and placeholder.
func (l *LanguageService) ProvidePrepareRename(ctx context.Context, uri lsproto.DocumentUri, documentPosition lsproto.Position) (lsproto.PrepareRenameResponse, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@copilot

textDocument/prepareRename is an optional feature in the LSP.

Can we not just do this within handleRename by returning an error there?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue shows a tooltip that appears when hovering/triggering rename, which comes from prepareRename. If we return an error from handleRename instead, users would only see the error AFTER attempting the rename, not as an early warning.

However, I can simplify the implementation to avoid the test regressions. The current test failures suggest that the validation logic needs to match TypeScript's more closely, which is complex. Would you prefer:

  1. Keep prepareRename but simplify the validation logic
  2. Return errors from handleRename and accept the different UX (error notification vs tooltip)

Let me know your preference and I'll adjust accordingly.

Remove prepareRename implementation and return error from handleRename instead.
- Add nodeIsEligibleForRename function to check basic eligibility
- Update ProvideSymbolsAndEntries to validate adjusted node
- Return error from ProvideRenameFromSymbolAndEntries when no symbols found
- Remove prepareRename handler and test

Note: Awaiting feedback on approach - some tests need adjustment for the new validation logic.

Co-authored-by: jakebailey <[email protected]>
Copilot AI changed the title Implement prepareRename to prevent renaming keywords Prevent renaming keywords by validating in handleRename Dec 4, 2025
Copilot finished work on behalf of jakebailey December 4, 2025 23:33
Copilot AI requested a review from jakebailey December 4, 2025 23:33
// Check if ProvideSymbolsAndEntries returned ok=false or no symbols found
// Return an error to inform the user that rename is not available
if symbolsAndEntries == nil || len(symbolsAndEntries) == 0 {
return lsproto.WorkspaceEditOrNull{}, fmt.Errorf("%s", diagnostics.You_cannot_rename_this_element)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@copilot you need to localize this diagnostic, not just print it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in d8a16fb - now using diagnostics.You_cannot_rename_this_element.Localize(locale.FromContext(ctx)) to properly localize the error message.

Use locale.FromContext(ctx) and .Localize() to properly localize the "You cannot rename this element" error message instead of just converting to string.

Co-authored-by: jakebailey <[email protected]>
Copilot AI requested a review from jakebailey December 4, 2025 23:49
Copilot finished work on behalf of jakebailey December 4, 2025 23:49
// Return an error to inform the user that rename is not available
if symbolsAndEntries == nil || len(symbolsAndEntries) == 0 {
return lsproto.WorkspaceEditOrNull{}, fmt.Errorf("%s", diagnostics.You_cannot_rename_this_element)
return lsproto.WorkspaceEditOrNull{}, fmt.Errorf(diagnostics.You_cannot_rename_this_element.Localize(locale.FromContext(ctx)))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@copilot This is a bug; you are passing a message into the format string of a *f func

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 3b02540 - now using errors.New() instead of fmt.Errorf() to avoid treating the localized message as a format string.

Use errors.New() instead of fmt.Errorf() when creating error from localized message to avoid treating the message as a format string.

Co-authored-by: jakebailey <[email protected]>
Copilot AI requested a review from jakebailey December 5, 2025 00:09
Copilot finished work on behalf of jakebailey December 5, 2025 00:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Should not allow renaming keywords

2 participants