| 
									
										
											  
											
												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>
											
										 
											2024-04-24 21:04:25 +02:00
										 |  |  |  | // VIM_TEST_SETUP let g:java_highlight_functions = 'style'
 | 
					
						
							| 
									
										
										
										
											2024-05-10 15:49:06 +03:00
										 |  |  |  | // VIM_TEST_SETUP set encoding=utf-8 termencoding=utf-8
 | 
					
						
							| 
									
										
											  
											
												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>
											
										 
											2024-04-24 21:04:25 +02:00
										 |  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2024-04-29 21:24:35 +03:00
										 |  |  |  | import java.lang.annotation.ElementType;
 | 
					
						
							| 
									
										
											  
											
												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>
											
										 
											2024-04-24 21:04:25 +02:00
										 |  |  |  | import java.lang.annotation.Target;
 | 
					
						
							|  |  |  |  | 
 | 
					
						
							|  |  |  |  | abstract class StyleMethodsTests
 | 
					
						
							|  |  |  |  | {
 | 
					
						
							| 
									
										
										
										
											2024-04-29 21:24:35 +03:00
										 |  |  |  | 	// TYPES.
 | 
					
						
							| 
									
										
											  
											
												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>
											
										 
											2024-04-24 21:04:25 +02:00
										 |  |  |  | 	record Τʬ<α>(α a) { }
 | 
					
						
							|  |  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2024-05-10 15:49:06 +03:00
										 |  |  |  | 	enum E
 | 
					
						
							| 
									
										
											  
											
												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>
											
										 
											2024-04-24 21:04:25 +02:00
										 |  |  |  | 	{
 | 
					
						
							| 
									
										
										
										
											2024-05-10 15:49:06 +03:00
										 |  |  |  | 		A("a"), B("b"), C("c"), D("d"),
 | 
					
						
							|  |  |  |  | 		E("e"), F("f"), G("g"), H("h");
 | 
					
						
							|  |  |  |  | 		final String s;
 | 
					
						
							|  |  |  |  | 		private E(String s) { this.s = s; }
 | 
					
						
							| 
									
										
											  
											
												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>
											
										 
											2024-04-24 21:04:25 +02:00
										 |  |  |  | 	}
 | 
					
						
							|  |  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2024-04-29 21:24:35 +03:00
										 |  |  |  | 	@Target({ElementType.METHOD, ElementType.CONSTRUCTOR})
 | 
					
						
							| 
									
										
											  
											
												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>
											
										 
											2024-04-24 21:04:25 +02:00
										 |  |  |  | 	@java.lang.annotation.Repeatable(Tɐggablɘs.class)
 | 
					
						
							|  |  |  |  | 	@interface Tɐggablɘ
 | 
					
						
							|  |  |  |  | 	{
 | 
					
						
							|  |  |  |  | 		String[] value() default "";
 | 
					
						
							|  |  |  |  | 	}
 | 
					
						
							|  |  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2024-04-29 21:24:35 +03:00
										 |  |  |  | 	@Target({ElementType.METHOD, ElementType.CONSTRUCTOR})
 | 
					
						
							| 
									
										
											  
											
												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>
											
										 
											2024-04-24 21:04:25 +02:00
										 |  |  |  | 	@interface Tɐggablɘs
 | 
					
						
							|  |  |  |  | 	{
 | 
					
						
							|  |  |  |  | 		Tɐggablɘ[] value();
 | 
					
						
							|  |  |  |  | 	}
 | 
					
						
							|  |  |  |  | 
 | 
					
						
							|  |  |  |  | 	interface Stylable<Α>
 | 
					
						
							|  |  |  |  | 	{
 | 
					
						
							|  |  |  |  | 		default void ascii$0_() { }
 | 
					
						
							|  |  |  |  | 		default Α μʭʭ$0_() { return null; }
 | 
					
						
							|  |  |  |  | 	}
 | 
					
						
							|  |  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2024-04-29 21:24:35 +03:00
										 |  |  |  | 	// FIELDS.
 | 
					
						
							|  |  |  |  | 	private static final Class<?> CLASS_LOCK = classLock();
 | 
					
						
							|  |  |  |  | 
 | 
					
						
							|  |  |  |  | 	private final Object instanceLock = new Object();
 | 
					
						
							|  |  |  |  | 
 | 
					
						
							|  |  |  |  | 	// CONSTRUCTORS.
 | 
					
						
							|  |  |  |  | 	@Tɐggablɘ @Tɐggablɘ protected StyleMethodsTests() { }
 | 
					
						
							|  |  |  |  | 	<T extends Comparable<T>> StyleMethodsTests(T t, Void v) { }
 | 
					
						
							|  |  |  |  | 	private <T extends Comparable<T>> StyleMethodsTests(T t) { }
 | 
					
						
							|  |  |  |  | 
 | 
					
						
							|  |  |  |  | 	// METHODS.
 | 
					
						
							| 
									
										
											  
											
												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>
											
										 
											2024-04-24 21:04:25 +02:00
										 |  |  |  | 	@Tɐggablɘ @Tɐggablɘ abstract void ascii$0_(////////////////
 | 
					
						
							|  |  |  |  | 								);
 | 
					
						
							|  |  |  |  | 	@Tɐggablɘ @Tɐggablɘ abstract <α, β> Τʬ<α> μʭʭ$0_(
 | 
					
						
							| 
									
										
										
										
											2024-06-13 18:30:09 +03:00
										 |  |  |  | 				@SuppressWarnings("bespoke") β b);
 | 
					
						
							| 
									
										
											  
											
												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>
											
										 
											2024-04-24 21:04:25 +02:00
										 |  |  |  | 
 | 
					
						
							|  |  |  |  | 	@Tɐggablɘ private native void ascii$1_(/*////////////*/);
 | 
					
						
							|  |  |  |  | 	@Tɐggablɘ private native <α, β> Τʬ<α>[] μʭʭ$1_(
 | 
					
						
							|  |  |  |  | 			java.util.function.Function<β, Τʬ<α>[]> ƒ);
 | 
					
						
							|  |  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2024-04-29 21:24:35 +03:00
										 |  |  |  | 	void Ascii$2_() { }
 | 
					
						
							|  |  |  |  | 	<T, U extends Stylable<T>> void Μʭʭ$2_(U u) { }
 | 
					
						
							|  |  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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>
											
										 
											2024-04-24 21:04:25 +02:00
										 |  |  |  | 	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];
 | 
					
						
							|  |  |  |  | 	}
 | 
					
						
							|  |  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2024-04-29 21:24:35 +03:00
										 |  |  |  | 	public static Class<?> classLock() { return StyleMethodsTests.class; }
 | 
					
						
							|  |  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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>
											
										 
											2024-04-24 21:04:25 +02:00
										 |  |  |  | 	@Override @SuppressWarnings("cast")
 | 
					
						
							|  |  |  |  | 	public String toString() { return (String) "StyleMethodsTests"; }
 | 
					
						
							|  |  |  |  | }
 |