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>

/* vi:set ts=8 sw=8 noet:
 *
 * VIM - Vi IMproved	by Bram Moolenaar
 *			Visual Workshop integration by Gordon Prieur
 *
 * Do ":help uganda"  in Vim to read copying and usage conditions.
 * Do ":help credits" in Vim to see a list of people who contributed.
 */


#ifndef NBDEBUG_H
#define NBDEBUG_H

#ifdef NBDEBUG

# ifndef ASSERT
#  define ASSERT(c) \
    if (!(c)) \
    { \
	fprintf(stderr, "Assertion failed: line %d, file %s\n", \
		__LINE__, __FILE__); \
	fflush(stderr); \
	abort(); \
    }
# endif

# define nbdebug(a) nbdbg a

# define NB_TRACE		0x00000001
# define NB_TRACE_VERBOSE	0x00000002
# define NB_TRACE_COLONCMD	0x00000004
# define NB_PRINT		0x00000008
# define NB_DEBUG_ALL		0xffffffff

# define NBDLEVEL(flags)	(nb_debug != NULL && (nb_dlevel & (flags)))

# define NBDEBUG_TRACE	1

typedef enum {
		WT_ENV = 1,		// look for env var if set
		WT_WAIT,		// look for ~/.gvimwait if set
		WT_STOP			// look for ~/.gvimstop if set
} WtWait;


void		 nbdbg(char *, ...) ATTRIBUTE_FORMAT_PRINTF(1, 2);

void nbdebug_wait(u_int wait_flags, char *wait_var, u_int wait_secs);
void nbdebug_log_init(char *log_var, char *level_var);

extern FILE	*nb_debug;
extern u_int	 nb_dlevel;		// nb_debug verbosity level

#else		// not NBDEBUG

# ifndef ASSERT
#  define ASSERT(c)
# endif

/*
 * The following 3 stubs are needed because a macro cannot be used because of
 * the variable number of arguments.
 */

void
nbdbg(
	char		*fmt,
	...)
{
}

#endif // NBDEBUG
#endif // NBDEBUG_H