runtime(java): Improve the recognition of the "style" method declarations Commit: https://github.com/vim/vim/commit/a4c085a3e607bd01d34e1db600b6460fc35fb0a3 Author: Aliaksei Budavei <0x000c70@gmail.com> Date: Wed Apr 24 21:04:25 2024 +0200 runtime(java): Improve the recognition of the "style" method declarations - Request the new regexp engine (v7.3.970) for [:upper:] and [:lower:]. - Recognise declarations of in-line annotated methods. - Recognise declarations of _strictfp_ methods. - Establish partial order for method modifiers as shown in the MethodModifier production; namely, _public_ and friends should be written the leftmost, possibly followed by _abstract_ or _default_, or possibly followed by other modifiers. - Stop looking for parameterisable primitive types (void<?>, int<Object>, etc., are malformed). - Stop looking for arrays of _void_. - Acknowledge the prevailing convention for method names to begin with a small letter and for class/interface names to begin with a capital letter; and, therefore, desist from claiming declarations of enum constants and constructors with javaFuncDef. Rationale: + Constructor is distinct from method: * its (overloaded) name is not arbitrary; * its return type is implicit; * its _throws_ clause depends on indirect vagaries of instance (variable) initialisers; * its invocation makes other constructors of its type hierarchy invoked one by one, concluding with the primordial constructor; * its explicit invocation, via _this_ or _super_, can only appear as the first statement in a constructor (not anymore, see JEP 447); else, its _super_ call cannot appear in constructors of _record_ or _enum_; and neither invocation is allowed for the primordial constructor; * it is not a member of its class, like initialisers, and is never inherited; * it is never _abstract_ or _native_. + Constructor declarations tend to be few in number and merit visual recognition from method declarations. + Enum constants define a fixed set of type instances and more resemble class variable initialisers. Note that the code duplicated for @javaFuncParams is written keeping in mind for g:java_highlight_functions a pending 3rd variant, which would require none of the :syn-cluster added groups. closes: #14620 Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>

// VIM_TEST_SETUP let g:java_highlight_functions = 'style'


import java.lang.annotation.Target;

abstract class StyleMethodsTests
{
	protected StyleMethodsTests() { }

	record Τʬ<α>(α a) { }

	enum 𝓔
	{
		A("𝕬"), B("𝕭"), C("𝕮"), D("𝕯"),
		E("𝕰"), F("𝕱"), G("𝕲"), H("𝕳");
		final String 𝐬;
		private 𝓔(String 𝐬) { this.𝐬 = 𝐬; }
	}

	@Target(java.lang.annotation.ElementType.METHOD)
	@java.lang.annotation.Repeatable(Tɐggablɘs.class)
	@interface Tɐggablɘ
	{
		String[] value() default "";
	}

	@Target(java.lang.annotation.ElementType.METHOD)
	@interface Tɐggablɘs
	{
		Tɐggablɘ[] value();
	}

	interface Stylable<Α>
	{
		default void ascii$0_() { }
		default Α μʭʭ$0_() { return null; }
	}

	@Tɐggablɘ @Tɐggablɘ abstract void ascii$0_(////////////////
								);
	@Tɐggablɘ @Tɐggablɘ abstract <α, β> Τʬ<α> μʭʭ$0_(
			/* TODO: @SuppressWarnings("bespoke")*/ β 𝛽);

	@Tɐggablɘ private native void ascii$1_(/*////////////*/);
	@Tɐggablɘ private native <α, β> Τʬ<α>[] μʭʭ$1_(
			java.util.function.Function<β, Τʬ<α>[]> ƒ);

	static final native synchronized void ascii$98_();
	static final native synchronized <α, β> Τʬ<α>[][] μʭʭ$98_(
			java.util.function.Function<β, Τʬ<α>[][]> ƒ);

	@SuppressWarnings("strictfp")
	protected static final synchronized strictfp void ascii$99_()
	{ ascii$98_(); }

	@SuppressWarnings("strictfp")
	protected static final synchronized strictfp <α, β> Τʬ<α>[] μʭʭ$99_(
			java.util.function.Function<β, Τʬ<α>[][]> ƒ)
	{
		return
	StyleMethodsTests.<α, β>μʭʭ$98_(ƒ)[0];
	}

	@Override @SuppressWarnings("cast")
	public String toString() { return (String) "StyleMethodsTests"; }
}