review: fix: Fix return type of setParent

[slarse]

Fix #4098 (see issue for description of problem)

Breaking change!

This PR implements option 2 presented in #4098. It's a purely statically breaking change, meaning that some compilation may be affected, but behavior is not. However, compilation is pretty unlikely to be affected, and it should really only be the case if the parameterization of the method is explicitly provided.

[slarse]

Case and point in small amount of breakage: this was the only part of the entire Spoon codebase that needed to change, apart from the directly affected method headers.

[slarse]

@I-Al-Istannen The improved Javadoc check pinpointed the correct error: https://github.com/INRIA/spoon/runs/3337956190?check_suite_focus=true#step:9:25 :)

EDIT: Almost, it was off by one method. But pretty close!

[monperrus]

Thanks for the analysis and proof that it's minor.

What about this alternative <E extends CtElement> E setParent(CtElement parent), not changing the return type and type parameters?

[slarse]

Ah, yes, that should also work. Technically speaking the return type is changed, as it is no longer bound to the argument. This means that there could potentially still be static breakage, but as the return type was incorrect we probably want that breakage.

Oh, and note that this is the super sketchy use of type parameters in return types that I advocated against in #1846 (although there I talk about return-type only parameters, but it's really a problem wherever unchecked casts are used). It can cause stuff like this, where incorrect typing simply isn't detected. But it's already there so we need to roll with it.

[monperrus]

Simple and to the point, thanks. Will merge.

[monperrus]

Thanks @slarse

[slarse]

This caused a regression in Spork (and likely will for any Kotlin dependents).

For any call previously looking like so:

element.setParent(parent);

Must now be amended like so:

element.setParent<CtElement>(parent);

For the reasons outlined in #1846