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"; }
|
|
|
|
|
}
|