Problem: The a: dict is not immutable as documented.
Solution: Make the a:dict immutable, add a test. (Ozaki Kiichi, Yasuhiro
Matsumoto, closesvim/vim#3929)
31b816042f
Inspired by quickbuild failure, where `g:val` was increased already:
20:07:04,227 INFO - not ok 1164 - timers works with repeat two
20:07:04,227 INFO - # test/functional/eval/timer_spec.lua @ 36
20:07:04,227 INFO - # Failure message: test/functional/eval/timer_spec.lua:38: Expected objects to be the same.
20:07:04,227 INFO - # Passed in:
20:07:04,227 INFO - # (number) 1
20:07:04,227 INFO - # Expected:
20:07:04,227 INFO - # (number) 0
20:07:04,227 INFO - # stack traceback:
20:07:04,227 INFO - # test/functional/eval/timer_spec.lua:38: in function <test/functional/eval/timer_spec.lua:36>
Uses a pattern of `eq()`ing `timer_start` and `g:val` in the same `eval`
call, and decreases timeouts in general.
Improves runtime from ~5s to <2s.
There was a longer timeout for Windows already, but unlike stated in
51d42917f it is not a worst-case, but gets waited for always.
The test is only about "-1" on timeout, so reduce it to this.
Fixes:
16:33:19,309 INFO - not ok 627 - jobs jobwait with timeout argument will return -1 if the wait timed out
16:33:19,309 INFO - # test/functional/core/job_spec.lua @ 707
16:33:19,309 INFO - # Failure message: test/functional/core/job_spec.lua:714: Expected objects to be the same.
16:33:19,309 INFO - # Passed in:
16:33:19,309 INFO - # (table: 0x0db1a3f0) {
16:33:19,309 INFO - # [1] = 'notification'
16:33:19,309 INFO - # [2] = 'wait'
16:33:19,309 INFO - # *[3] = {
16:33:19,309 INFO - # *[1] = {
16:33:19,309 INFO - # *[1] = -1
16:33:19,309 INFO - # [2] = -1 } } }
16:33:19,309 INFO - # Expected:
16:33:19,309 INFO - # (table: 0x0db1a480) {
16:33:19,309 INFO - # [1] = 'notification'
16:33:19,309 INFO - # [2] = 'wait'
16:33:19,309 INFO - # *[3] = {
16:33:19,309 INFO - # *[1] = {
16:33:19,309 INFO - # *[1] = 4
16:33:19,309 INFO - # [2] = -1 } } }
16:33:19,309 INFO - # stack traceback:
16:33:19,309 INFO - # test/functional/core/job_spec.lua:714: in function <test/functional/core/job_spec.lua:707>
Seen on quickbuild:
23:01:01,289 INFO - not ok 1172 - timers can be stopped from the handler
23:01:01,289 INFO - # test/functional/eval/timer_spec.lua @ 154
23:01:01,289 INFO - # Failure message: test/functional/eval/timer_spec.lua:166: Expected objects to be the same.
23:01:01,289 INFO - # Passed in:
23:01:01,289 INFO - # (number) 3
23:01:01,289 INFO - # Expected:
23:01:01,289 INFO - # (number) 0
23:01:01,289 INFO - # stack traceback:
23:01:01,289 INFO - # test/functional/eval/timer_spec.lua:166: in function <test/functional/eval/timer_spec.lua:154>
Log: http://neovim-qb.szakmeister.net/build/24288
Ref: https://github.com/neovim/neovim/pull/10364
Before this commit, when `inccomand` was set to `nosplit`, multi-line
substitutions collapsed the command-line.
This happened because when ex_getln.c:cursorcmd() computed a msg_row, it
was given a cmdline_row one line too high. This happened because
message.c:msg_puts_display() was supposed to decrement cmdline_row but
didn't, because of the `msg_no_more && lines_left == 0` check placed
just before the decrementation part in msg_puts_display's while loop.
Every time msg_puts_display writes a line, it decreases `lines_left` (a
variable used to know how many lines are left for prompts). Since
redrawcommandline() did not reset `lines_left` between calls to
msg_puts_display, every time a character was pressed, `lines_left` was
decremented. This meant that once the user pressed COLUMNS+ROWS numbers
of characters, `lines_left` would reach 0 and prevent msg_row from being
decremented.
It makes sense to fix setting `lines_left` to `cmdline_row` in
`compute_cmdrow` ; after all, computing where the command line row
should be placed is equivalent to computing how many `lines_left` of
output there are left.
Closes#8254.
(<Cmd>0<cr> is not really a no-op, it moves the cursor.)
Attempt to avoid flaky test:
test/functional/ui/cmdline_spec.lua @ 830
Failure message: ./test/functional/ui/screen.lua:579: Row 2 did not match.
Expected:
| |
|*{1:~ }|
|{3: }|
|:012345678901234567890123|
|456789^ |
Actual:
| |
|*{3: }|
|:012345678901234567890123|
|:012345678901234567890123|
|456789^ |
./test/functional/ui/screen.lua:579: in function '_wait'
./test/functional/ui/screen.lua:367: in function 'expect'
test/functional/ui/cmdline_spec.lua:841: in function <test/functional/ui/cmdline_spec.lua:830>
ref https://github.com/neovim/neovim/pull/10171#issuecomment-520134344
ref #10171
Regardless of the comment "Big timeout for ASAN/valgrind" it would use
10s by default already.
This changes it to use `load_adjust`, which itself is only computed on
CI now, and outside of any tests - since it has side effects when being
used the first time!
The failure seen on AppVeyor:
[ RUN ] jobs can get the pid value using getpid: ERR
test\functional\helpers.lua:167:
==============================================================================
got 0 messages (ignored 0), expected 1
stack traceback:
test\functional\helpers.lua:167: in function 'expect_msg_seq'
test/functional\core\job_spec.lua:288: in function <test/functional\core\job_spec.lua:281>
Log: https://ci.appveyor.com/project/neovim/neovim/builds/26537324/job/y1io66fbx399q7h6?fullLog=true#L6554
Fix flaky "shell command :! throttles shell-command output greater than ~10KB:":
[ RUN ] shell command :! throttles shell-command output greater than ~10KB:
warning: Screen changes were received after the expected state. This indicates
indeterminism in the test. Try adding screen:expect(...) (or wait()) between
asynchronous (feed(), nvim_input()) and synchronous API calls.
- Use screen:redraw_debug() to investigate; it may find relevant intermediate
states that should be added to the test to make it more robust.
- If the purpose of the test is to assert state after some user input sent
with feed(), adding screen:expect() before the feed() will help to ensure
the input is sent when Nvim is in a predictable state. This is preferable
to wait(), for being closer to real user interaction.
- wait() can trigger redraws and consequently generate more indeterminism.
Try removing wait().
ERR
test/functional/ui/screen.lua:579: Failed to match any screen lines.
Expected (anywhere): "
%."
Actual:
|XXXXXXXXXX 591 |
|XXXXXXXXXX 592 |
|XXXXXXXXXX 593 |
|XXXXXXXXXX 594 |
| |
| |
|{3:-- TERMINAL --} |
stack traceback:
test/functional/ui/screen.lua:579: in function '_wait'
test/functional/ui/screen.lua:367: in function 'expect'
test/functional/ui/output_spec.lua:63: in function <test/functional/ui/output_spec.lua:53>
Log: https://travis-ci.org/neovim/neovim/jobs/569082705#L5355
(gcc-functionaltest-lua)
