Inline unapplys in the inlining phase

[nicolasstucki]

These currently got inlined while typing. Therefore they used to generate code that should not be pickled. The non-transparent inline methods should be inlined in the inlining phase.

This was found while working on #19380.

[jchyb]

Won't that cause the transparent inline call to also be inlined later, at the inlining phase? Outside of the one deleted here, I can't see any other reference to inlineUnapply in Typer. Unless the idea is to first transparent inline the unapply call in typer, and later wrap the result of that with the anon class in inlineUnapply? I suppose this would also fix #19369

[nicolasstucki]

Won't that cause the transparent inline call to also be inlined later, at the inlining phase?

Yes. I changed this to keep inlining the transparent ones before pickling.

[nicolasstucki]

We should only merge this if it is also backported to 3.4.0-RC-2. Otherwise we will need to merge for 3.5.0-RC1.

[nicolasstucki]

This implementation changed after I rebased.

[nicolasstucki]

This was deleted after I rebased

[Gedochao]

It has been decided to be included in the 3.5.0 release.

[jchyb]

Suggested change

	case tree: UnApply =>
	tree match
	case tree1: UnApply if Inlines.needsInlining(tree1) =>
	super.transform(cpy.UnApply(tree1)(fun = Inlines.inlinedUnapplyFun(tree1.fun)))
	case tree1 => super.transform(tree1)
	case tree: UnApply if Inlines.needsInlining(tree) =>
	super.transform(cpy.UnApply(tree)(fun = Inlines.inlinedUnapplyFun(tree.fun)))

Just a NIT/question. Would this work? I see there is a case that should go through super.transform(tree) for non inline Unapply trees later as well

[nicolasstucki]

I probably wanted to avoid calling needsInlining twice. I can refactor it to make it more concise.