patch 9.1.0372: Calling CLEAR_FIELD() on the same struct twice
Problem: Calling CLEAR_FIELD() on the same struct twice.
Solution: Remove the second CLEAR_FIELD(). Move the assignment of cookie.sourceing_lnum (zeertzjq).
closes: #14627
Signed-off-by: zeertzjq <email address hidden>
Signed-off-by: Christian Brabandt <cb@256bit.org>
f6c1fb2...
by
Yegappan Lakshmanan <email address hidden>
patch 9.1.0371: Vim9: compile_def_function() still too long
Problem: Vim9: compile_def_function() still too long
Solution: Refactor the code into separate functions
(Yegappan Lakshmanan)
closes: #14632
Signed-off-by: Yegappan Lakshmanan <email address hidden>
Signed-off-by: Christian Brabandt <cb@256bit.org>
e679a37...
by
=?utf-8?b?SXZhbiBQZcWhacSH?= <email address hidden>
translation(sr): Update Serbian messages (#14633)
Signed-off-by: Ivan Pešić <email address hidden>
Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0370: MS-Windows: patch number is zero in installer
Problem: MS-Windows: patch number is zero in installer (jonathan-b-wiebe)
Solution: Set VIM_VERSION_PATCHLEVEL, fix a few typos in the installer (RestorerZ)
fixes: #14629
closes: #14635
Signed-off-by: RestorerZ <email address hidden>
Signed-off-by: Christian Brabandt <cb@256bit.org>
runtime(doc): clarify the effect of setting the shell to powershell
fixes: #14636
Signed-off-by: Christian Brabandt <cb@256bit.org>
a4c085a...
by
Aliaksei Budavei <email address hidden>
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 <email address hidden>
Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0369: Vim9: problem when importing autoloaded scripts
Problem: Vim9: problem when importing autoloaded scripts
Solution: In `:def` handle storing to vim9 autoload export
(Ernie Rael)
Problem occurs when `import autoload ./.../autoload/...`. The autoload
in the specified path causes the use of an autoload_prefix which combines
with the `import autoload` to create trouble.
In `generate_store_var()` `case dest_script` use ISN_STOREEXPORT,
when needed, instead of ISN_STORES. When executing ISN_STOREEXPORT,
check for autoload_prefix.
patch 9.1.0368: MS-Windows: Hard to define the Vim Patchlevel with leading zeroes
Problem: MS-Windows: Hard to define the Vim Patchlevel with leading
zeroes for the installer
Solution: re-define VIM_VERSION_PATCHLEVEL_STR with leading zeroes,
interpret Patchlevel as decimal in Make_mvc.mak (RestorerZ)
closes: #14471
Signed-off-by: RestorerZ <email address hidden>
Signed-off-by: Christian Brabandt <cb@256bit.org>
