| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: Cannot make Vim fail on an internal error.
Solution: Add IEMSG() and IEMSG2(). (Domenique Pelle) Avoid reporting an
internal error without mentioning where.
https://github.com/vim/vim/commit/95f096030ed1a8afea028f2ea295d6f6a70f466f
Signed-off-by: Michael Schupikov <michael@schupikov.de>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* typval_encode.c.h: avoid -Wnonnull-compare warning
closes #6847
The NULL check is needed because TYPVAL_ENCODE_CONV_EMPTY_DICT may be
invoked with literal `NULL`.
Warning occurs even for `Debug` build-type:
neovim/src/nvim/eval/typval.c: In function ‘_typval_encode_nothing_convert_one_value’:
neovim/src/nvim/eval/typval.c:1802:10: warning: nonnull argument ‘tv’ compared to NULL [-Wnonnull-compare]
if (tv != NULL) { \
^
../src/nvim/eval/typval_encode.c.h:398:9: note: in expansion of macro ‘TYPVAL_ENCODE_CONV_EMPTY_DICT’
TYPVAL_ENCODE_CONV_EMPTY_DICT(tv, tv->vval.v_dict);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gcc version:
gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406
* fixup! typval_encode.c.h: avoid -Wnonnull-compare warning
|
| | | |
|
| | |
| |
| |
| | |
Still missing: problems in window.c, it should be possible to construct a test
for them.
|
| | | |
|
| | |
| |
| | |
[ci skip]
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Most of files, except for eval.c and eval/* were only processed by perl.
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
vim-patch:fafcf0dd59fd
patch 8.0.1206: no autocmd for entering or leaving the command line
Problem: No autocmd for entering or leaving the command line.
Solution: Add CmdlineEnter and CmdlineLeave.
https://github.com/vim/vim/commit/fafcf0dd59fd9c4ef743bb333ae40d1d322b6079
|
| |
|
|
|
|
|
| |
Clang complains because memchr has undefined behavior if the ptr is
NULL, even if len==0.
Helped-by: Nikolai Aleksandrovich Pavlov <kp-pav@yandex.ru>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
After merging +num64, the 64-bit sanitizer builds show that Vim doesn't
buffer the user from C's UB in signed arithmetic. Upstream doesn't
appear to be [interested] in fixing the issue, so suppress UBSAN until
someone decides to fix the problem.
N.B., the problem existed before but went unnoticed since the sanitizer
builds weren't being run in 32-bit mode.
[interested]: https://groups.google.com/d/topic/vim_dev/_tqf8eQy5eA/discussion
|
| | |
|
| |
|
|
|
|
|
| |
Problem: Number variables are not 64 bits while they could be.
Solution: Add the num64 feature. (Ken Takata)
https://github.com/vim/vim/commit/22fcfad29276bd5f317faf516637dcd491b96a12
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
| |
Although GCC now detects possibly unintentional fall through, there
rules around which the comments are detected are rather strict. In
cases where a comment isn't detected, upstream [recommends] using their
fallthrough attribute.
[recommends]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77817#c11
|
| |\ |
|
| | |\ |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Same as tv_list_alloc, but additionally ret_tv receives pointer to the newly
allocated list.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Allocated dict points to previously allocated dict.
Queue in allocated dict points to itself.
Hashtab in allocated dict points to inside itself.
Allocated dict is saved to gc_first_dict.
|
| | | |
| | |
| | | |
Allocated storage may receive pointer to the list after tv_copy().
|
| | | |
| | |
| | |
| | | |
Allocated list points to previously allocated list.
Allocated list is saved to gc_first_list.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Not using enum{} because SIZE_MAX exceeds integer and I do not really like how
enum definition is described in C99:
1. Even though all values must fit into the chosen type (6.7.2.2, p 4) the type
to choose is still implementation-defined.
2. 6.4.4.3 explicitly states that “an identifier declared as an enumeration
constant has type `int`”. So it looks like “no matter what type was chosen
for enumeration, constants will be integers”. Yet the following simple
program:
#include <stdint.h>
#include <stdio.h>
#include <stddef.h>
enum { X=SIZE_MAX };
int main(int argc, char **argv)
{
printf("x:%zu m:%zu t:%zu v:%zu",
sizeof(X), sizeof(SIZE_MAX), sizeof(size_t), (size_t)X);
}
yields one of the following using different compilers:
- clang/gcc/pathcc: `x:8 m:8 t:8 v:18446744073709551615`
- pcc/tcc: `x:4 m:8 t:8 v:1844674407370955161`
If I remove the cast of X to size_t then pcc/tcc both yield `x:4 m:8 t:8
v:4294967295`, other compilers’ output does not change.
All compilers were called with `$compiler -std=c99 -xc -` (feeding program
from echo), except for `tcc` which has missing `-std=c99`. `pcc` seems to
ignore the argument though: it is perfectly fine with `-std=c1000`.
|
| | | | |
|
| | |/
| |
| |
| | |
Ref #6437
|
| | |
| |
| | |
Closes #6437
|
| | | |
|
| |\| |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Drops comments `// for …` that do not pass linter for them being unmaintainable
and fast to becoming incomplete or even incorrect.
Mention @dedmass
|
