Why did you remove UAST classes without deprecation and ScheduledForRemoval annotation?
Answered
Hi!
We use UAST in our plugin. Last three or two releases you break UAST API without warning. How long are you going to do that?
We used class UastLiteralReferenceProvider and you removed it in 2019.2 EAP.
Please sign in to leave a comment.
Sorry that broke your plugin. Is your plugin published on plugins.jetbrains.com or not?
I've filed https://youtrack.jetbrains.com/issue/IDEA-216927
Fixed for 2019.2
> Last three or two releases you break UAST API without warning
Hello, could you please tell more about previous breakings? just classes or method names if possible. It will let us understand if we can avoid such breakings in future.
Consider Idea versions 183.4284.148 and 191.7479.19.
In first we have `UElementPattern#callParameter`. In the 191 the method was moved to child class `UExpressionPattern`. As I understood, it leads to bytecode incompatibility, and we need to recompile the code under the 191 version.
So, a code
compiled under the 183 and executed under the 191 leads following exception:
Another problem.
In 183 `UastReferenceProvider` had default constructor without arguments, but in 191 it does not. It has a constructor with a default value for `supportedUElementTypes`, but as I remember, in a bytecode it is not equivalent to the default constructor.
So, plugin compiled on 191 doesn't work on 183 and vice versa.
Alexander Shustanov, thank you. We'll try to be more careful. All this UastReference*-related functionality was added recently and I didn't think that someone will use it outside Jetbrains. Also it will be very good if you'll publish your plugins in our Plugin Repository - in that case we'll be notified about all such external usages of our API.
Thank you again, sorry for the inconvenience. And don't hesitate to report such problems to youtrack (or contact me directly if it is about UAST) better on the EAP stages to let us fix it before release