Update 'use auto property' to respect user options around this. for property access.#79405
Conversation
| Return Renamer.RenameSymbolAsync( | ||
| solution, symbol, renameTo, renameOptions, | ||
| nonConflictSymbolKeys:=Nothing, CancellationToken.None).GetAwaiter().GetResult() | ||
| solution, symbol, renameTo, renameOptions, CancellationToken.None).GetAwaiter().GetResult() |
There was a problem hiding this comment.
As part of this, use-auto-prop is no longer going through the 'rename' codepaths itself. That is because the space of what is needs to rename is so narrow that there isn't much benefit here, and because we used to have to hack up the rename engine itself to support the somewhat strange scenario that Use-Auto-Prop is following. Specifically, 'use auto prop' renames a field (with name 'f') to match the name of a property 'P'. This is, definitionally, a conflict. So we hacked up the rename engine to let the caller tell it to ignore that.
We no longer need this capability, so all that threading through of these values is gone.
| CancellationToken cancellationToken) | ||
| { | ||
| var solutionEditor = new SolutionEditor(solution); | ||
|
|
There was a problem hiding this comment.
use-auto-prop now owns its rewriting strategy. so it can tweak it as appropriate. In this case, this all revolves around if it will have or not have this. when updating a simple name F to P.
5a5cbf9 to
f75dade
Compare
|
/azp run roslyn-CI |
|
Azure Pipelines successfully started running 1 pipeline(s). |
No description provided.