Code-generators should provide a way to "bundle" renaming

[rrousselGit]

Hello!
This is similar to #56518, but for another core IDE functionality: Renaming.

One way code-generators often work is by generating a new identifier, based on a user-defined identifier.
Like @example class UserDefined vs userDefinedGenerated, where the latter is generated based on a string transformation of the former.

The problem is, renaming renaming one of the two identifiers won't rename the other.

• Renaming @example class UserDefined will correctly update the generate code, but any existing reference to userDefinedGenerated will stay unchanged. Users will then have to modify those by hand ; which can be very tedious and error prone.
• Renaming userDefinedGenerated will not update UserDefined ; which means re-generating the code will revert our rename.

It would be great for the IDE to be able to rename both the generated and user-defined identifiers at once.

[dart-github-bot]

Summary: The current macro proposal doesn't address the issue of renaming generated identifiers. Renaming a user-defined identifier doesn't update the generated identifier, and vice versa, leading to inconsistent code and manual updates. The IDE should be able to rename both identifiers simultaneously for a seamless experience.

[rrousselGit]

Gentle bump :)
I think this is a pretty crutial logic in terms of User Experience.

The difference between fixing renaming and not fixing it would be huge.

[bwilkerson]

I agree; the rename operation, along with the rest of the tooling, needs to be made to work well with macros, and that if we do nothing they won't. The reason there's been no movement here is because we're busy working on the enhanced-parts and augmentations features, both of which are prerequisites for fully supporting macros.

I suspect that we'll solve the second half of the problem--renaming a generated declaration--by simply disallowing it. We don't generally support modifying generated code, and I don't see why a rename would be any different. If we had a way of associating the generated name with the name(s) from which is was derived, and a way of reversing that derivation, then maybe we could support something like this, but we don't, and it isn't clear that it would be an improvement to the DX.

I don't know what the best way is to solve the first half of the problem, but I'm happy to discuss possible solutions.

For example, what if, every time a rename operation is performed, we were to look to see whether there are any macros being applied in the enclosing library (I think that's the right scope, but I might be mistaken about that), and if there are take the following steps.

1. Produce a representation of the declarations in the macro generated part (those that are visible outside the library) prior to performing the refactoring.
2. Perform the rename refactoring as normal.
3. Produce a representation of the macro generated part after the refactoring.
4. Compute a diff between the previous and the new representations.
5. Perform a rename refactoring for all of the declarations whose name has changed.

That assumes that the order of the declarations is stable wrt the names of the declarations (that is, that nothing is sorting the declarations after they've been generated). Otherwise it won't be possible to produce a meaningful diff.

I think this would solve the problem, but I might be missing something. It's also possible that there's a better way to solve the problem. Evaluations and ideas welcome.

[keertip]

Closing, as we are no longer working on the macro feature.