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 syntax file
" Language:		Hitachi H-8300h specific syntax for GNU Assembler
" Maintainer:		Doug Kearns <dougkearns@gmail.com>
" Previous Maintainer:	Kevin Dahlhausen <kdahlhaus@yahoo.com>
" Last Change:		2020 Oct 31

if exists("b:current_syntax")
  finish
endif

runtime! syntax/asm.vim

syn case ignore

syn match asmDirective	"\.h8300[hs]n\="

"h8300[h] registers
syn match asmRegister	"e\=r\o[lh]\="

"h8300[h] opcodes - order is important!
syn match asmOpcode "add\.[lbw]"
syn match asmOpcode "add[sx :]"
syn match asmOpcode "and\.[lbw]"
syn match asmOpcode "bl[deots]"
syn match asmOpcode "cmp\.[lbw]"
syn match asmOpcode "dec\.[lbw]"
syn match asmOpcode "divx[us].[bw]"
syn match asmOpcode "ext[su]\.[lw]"
syn match asmOpcode "inc\.[lw]"
syn match asmOpcode "mov\.[lbw]"
syn match asmOpcode "mulx[su]\.[bw]"
syn match asmOpcode "neg\.[lbw]"
syn match asmOpcode "not\.[lbw]"
syn match asmOpcode "or\.[lbw]"
syn match asmOpcode "pop\.[wl]"
syn match asmOpcode "push\.[wl]"
syn match asmOpcode "rotx\=[lr]\.[lbw]"
syn match asmOpcode "sha[lr]\.[lbw]"
syn match asmOpcode "shl[lr]\.[lbw]"
syn match asmOpcode "sub\.[lbw]"
syn match asmOpcode "xor\.[lbw]"

syn keyword asmOpcode andc band bcc bclr bcs beq bf bge bgt
syn keyword asmOpcode bhi bhs biand bild bior bist bixor bmi
syn keyword asmOpcode bne bnot bnp bor bpl bpt bra brn bset
syn keyword asmOpcode bsr btst bst bt bvc bvs bxor cmp daa
syn keyword asmOpcode das eepmov eepmovw inc jmp jsr ldc movfpe
syn keyword asmOpcode movtpe mov nop orc rte rts sleep stc
syn keyword asmOpcode sub trapa xorc

syn case match

hi def link asmOpcode	Statement
hi def link asmRegister	Identifier

let b:current_syntax = "asmh8300"

" vim: nowrap sw=2 sts=2 ts=8 noet