Fixing rename for permitted subclasses.

[lahodaj]

Having something like:

sealed interface I permits Subtype {}
final class Subtype implements I {}

Renaming Subtype will not rename the identifier in the permits clause. This is because:

a) the write model (CausalDiff) does not support permits
b) the indexing does not include the permitted subclasses.

This PR is trying to fix both.

[lahodaj]

(Found a problem in the patch.)

[lahodaj]

Should be fixed now, and ready for review. Please let me know what you think!

[mbien]

this looks good as far as I can tell (thanks for the comments in CasualDiff).

merge conflict in apichanges.xml needs to be resolved + rebasing would be good to have a fresh CI run before integration.

[mbien]

I found a regression right after review :(

if you rename the interface, it will remove the permits section, this does not happen in NB 24

[lahodaj]

FWIW: the pre-existing methods now are a bit problematic, as if some code takes a ClassTree, and creates a new one from it using the old TreeMaker.Class/Interface method with permitted subclasses, the permitted subclasses will be lost. I don't see a good way around that.

So, I've tried to go through the whole NetBeans (production code), and fix what I could. Will push that shortly. I think I still need to make at least one pass through it, maybe add some tests, and maybe add some automated way to prevent use of the pre-existing methods. Will try to look at that as I can.

[mbien]

@lahodaj Unfortunately I didn't get to taking a look why tests are failing and tomorrow is freeze - probably better to move this to NB 26?

[lahodaj]

@lahodaj Unfortunately I didn't get to taking a look why tests are failing and tomorrow is freeze - probably better to move this to NB 26?

I apparently broke something in the CasualDiff. I hope I'll cycle back to this sometime soon.

[lahodaj]

I think this is ready for review. I've updated, squashed, went through the changes.

The "old" TreeMaker.Class/Interface methods will create the AST trees without any permitted subclasses, which could lead to a loss of those permitted subclasses. I don't think there's a reasonable way around that in the generator - the generator needs to follow what is in the new trees. So these old methods are now deprecated and there's an AP that prevents use of the deprecated method inside NB sources.

[mbien]

Code looks good to me. Ran a quick manual test and everything worked.

Deprecating the method was a good idea - wanted to suggest that too so that it isn't used by accident again.

[mbien]

this is interesting. Will this run while nb-javac is used within the NB editor too or only during build?

I suppose this is picked up when -proc:full is set + module dependency to nb-javac lib is declared?

[lahodaj]

Sorry for belated reply.

(AFAIK) This will run every time this module is on the appropriate path (and the AP is enabled). I.e. it will run in the editor when the NetBeans modules that depend on this are open (like java.source.base). It will not (should not) run for ordinary unrelated user code.

[lahodaj]

Any issue with merging this sometime soon?

[matthiasblaesing]

Given, the broad changes, I think it would be good to get this in early, so I suggest to merge now. That way people running nightlies will test and report problems early.