Ghidra: Ghidra fails to decompile after renaming a type

[Washi1337]

Describe the bug
When renaming an (auto generated) type of a parameter, the decompiler of Ghidra seems not to be aware of the refactoring that took place. Instead, it produces a low level error stating it cannot resolve the type with the original name anymore.

To Reproduce

1. Open a subroutine with at least one parameter.
2. Right click on the parameter and click "Auto Create Structure"
3. Right click again on the parameter and click "Edit Data Type"
4. In the window that pops up, change the name of the data type and press "Apply editor changes".
5. Observe how the decompiler now fails to decompile the subroutine.

Expected behavior
Expected behaviour is that Ghidra refactors the code properly and uses the new name in the decompiled source code.

Screenshots
Step 3:

Step 4:

Step 5:

GIFv of the entire process:
https://i.imgur.com/s8h6ZWC.gifv

Environment (please complete the following information):

• OS: Windows 10
• Java Version: 11.0.2
• Ghidra Version: 9.0.2

EDIT:
* Additional information *
It seems this does not always happen, but it fails usually on the "this" parameter of a __thiscall subroutine.

[saruman9]

You should to change class name (Symbol Tree → Classes) also or to edit prototype of function (should check Use Custom Storage for changing datatype of this parameter).