[RDY] :cquit to take an error code argument

[joshleeb]

Enhance :cquit to take an error code argument #2699.

Update the :cquit command to take an error code argument. By default the exit code is still 1, but when an exit code is provided then Neovim will exit with the specified code.

[jamessan]

There was a similar patch proposed upstream. I think it'd be worth prodding that discussion to see if it can get merged into Vim.

[joshleeb]

There was a similar patch proposed upstream.

Okay thanks, I'll take a look.

[ZyX-I]

Here should be argument listed, or :[count]cq[uit], better the second.

[ZyX-I]

It is more consistent with COUNT plus NOTADR and not WORD1 and argument: this would allow typing :2cq<CR> in addition to :cq2<CR> (which is consistent with e.g. :cnext), and simplify ex_cquit to a great extent: you just call getout(eap->addr_count > 0 ? eap->line2 : 1).

[ZyX-I]

Missing negative checks: what will happen if you supply it non-number argument? Number followed by non-number? Out-of-range for exit codes (e.g. 1024 while maximal exit code is 255) number? Out-of-range for regular integer number?

(BTW, COUNT takes care of that too: :cnext 1x and :cnext x are errors and you are absolutely missing checking for errors what you must do.)

[ZyX-I]

Also it is good idea to test whether executing if 0|cquit 5|endif throws some syntax errors (better use redir_exec, not exc_exec). With some combination of flags you need to bother populating eap->nextcmd, though I do not remember with which exactly (most likely not WORD1 though and definitely not with COUNT+NOTADR, but without WORD1).

[ZyX-I]

And check :0cquit and :cquit 0. It is logical that second will yield zero exit code and illogical, but consistent that first will yield exit code 1 (check :0cnext vs :cnext 0).

[ZyX-I]

Ah, no, add ZEROR flag to the list and :0cquit should be the same as :cquit 0. It is just :cnext thinks that is incorrect.

[ZyX-I]

And COUNT goes with RANGE for desired behaviour. Basically what is expected is

diff --git a/src/nvim/ex_cmds.lua b/src/nvim/ex_cmds.lua
index 5a578cd08..6a1e6ceb3 100644
--- a/src/nvim/ex_cmds.lua
+++ b/src/nvim/ex_cmds.lua
@@ -614,7 +614,7 @@ return {
   },
   {
     command='cquit',
-    flags=bit.bor(TRLBAR, BANG),
+    flags=bit.bor(RANGE, NOTADR, COUNT, ZEROR, TRLBAR, BANG),
     addr_type=ADDR_LINES,
     func='ex_cquit',
   },

[ZyX-I]

Original patch, BTW, has some strange code: it should not check *eap->arg, ex_docmd takes care of checking for trailing characters already, using [code] goes against more common convention of using [count] (and there are no tests). Though it appears that all what is needed for :cquit is indeed just

diff --git a/src/nvim/ex_docmd.c b/src/nvim/ex_docmd.c
index 6e7938046..825d93a95 100644
--- a/src/nvim/ex_docmd.c
+++ b/src/nvim/ex_docmd.c
@@ -5995,7 +5995,7 @@ static void ex_quit(exarg_T *eap)
  */
 static void ex_cquit(exarg_T *eap)
 {
-  getout(1);
+  getout((int)eap->line2);
 }
 
 /*

[joshleeb]

Thanks a lot @ZyX-I. I've updated the patch based on your comments.

I've confirmed that if 0|cquit 5|endif doesn't throw a syntax error and works as expected. Also that :cquit 0 and :0 cquit exit with a status code of 0. For no exit value, the status code remains as the default, which is 1. And when a value out of the exit value range is provided then it will set the exit code to 255.

[ZyX-I]

I think that should too great exit values cause any issues the situation should be handled by mch_exit and not here and not even getout. AFAIK on linux it just works like a cast to uint8_t. BTW, it looks like according to the C99 standard EXIT_FAILURE is the only proper default: 0 or EXIT_SUCCESS indicates success (standard explicitly mentions both), EXIT_FAILURE indicates failure and everything else is “implementation-defined” with no particular meaning attached by the standard, but without claiming that any other value yields undefined behaviour either.

So do not limit values by yourself, and use EXIT_FAILURE. May need an addition to os/win_defs.h: import stdlib.h there, define EXIT_FAILURE to 1 if it is not already defined: Windows headers have a habit of not containing some values they must according to the standard.

[ZyX-I]

diff --git a/src/nvim/ex_docmd.c b/src/nvim/ex_docmd.c
index 6e7938046..d4ce78aa3 100644
--- a/src/nvim/ex_docmd.c
+++ b/src/nvim/ex_docmd.c
@@ -9,6 +9,7 @@
 #include <string.h>
 #include <stdbool.h>
 #include <stdint.h>
+#include <stdlib.h>
 #include <inttypes.h>
 
 #include "nvim/vim.h"
@@ -5995,7 +5996,7 @@ static void ex_quit(exarg_T *eap)
  */
 static void ex_cquit(exarg_T *eap)
 {
-  getout(1);
+  getout(eap->addr_count > 0 ? (int)eap->line2 : EXIT_FAILURE);
 }
 
 /*

[ZyX-I]

The good thing is that Vim help was nice enough to not specify what “error code” is exactly, so EXIT_FAILURE will not go against the help even should it be not one (and I have it defined to 1).

[ZyX-I]

Missing documentation on what “count” means, also this does not have to have parenthesis:

Quit Vim with an error code, or the code specified in [count]. This may make a difference when Vim is called from another program which needs editor: e.g. git commit will abort the comitting process, fc (built-in from various shells including bash and zsh) will not execute the command, …

No need to mention “some compilers”, it is not useful without some specifics (like what was in original message). Not suggesting to add “compiler will not compile …” because of me never hearing the compiler which bothers to call editor at all.

[ZyX-I]

Still missing most of the tests I listed. I would also highly advise on creating a “test generator” function called like test_cq('cquit 0', 0, nil):

local function test_cq(cmdline, exit_code, redir_msg)
  if redir_msg then
    eq('\n' .. redir_msg, redir_exec(cmdline))
    wait()
    eq(1, eval('1'))  -- Check that Neovim did not crash or exit
  else
    funcs.system({nvim_prog, '-u', 'NONE', '-i', 'NONE', '--headless', '--cmd', cmdline})
    eq(exit_code, eval('v:shell_error'))
    local function on_setup()
       command('autocmd VimLeavePre * call rpcrequest('..cid..', "")')
       command('autocmd VimLeave    * call rpcrequest('..cid..', "")')
       command(cmdline)
     end
     local function on_request()
       eq(exit_code, eval('v:exiting'))
       return ''
     end
     run(on_request, nil, on_setup)
  end
end

Note the significant difference: I do not suggest checking only v:exiting, this test does not really serve its purpose because you can’t observe exit code before Neovim actually exits and you can’t have v:exiting available after it exits: test is only valid as long as there is connection between v:exiting and exit value and it is not necessary the case if somebody added a bug. Actually since I mentioned it: what you are testing is :cquit, not v:exiting, so while checking for it sideways is fine, setting v:exiting is by no means a purpose of :cquit: it is purpose of v:exiting to contain exit value Neovim will use, purpose of :cq is quit Neovim with specified exit value which is checked by system() check only.

Thus remove :cq out of the current describe() block, it is not correct.

[ZyX-I]

AppVeyor MINGW_32 failure looks unrelated: it fails building dependencies:

[ 92%] Generating usr/lib/luarocks/rocks/mpack
call usr\2.4\luarocks.bat build mpack CC=C:/msys64/mingw32/bin/gcc.exe LD=C:/msys64/mingw32/bin/gcc.exe
lmpack.c:21:17: fatal error: lua.h: No such file or directory
 #include <lua.h>
                 ^
compilation terminated.
C:/msys64/mingw32/bin/gcc.exe -O2 -c -o lmpack.o -IC:/projects/neovim/.deps/usr/include/luajit-2.0/ lmpack.c
Error: Build error: Failed compiling object lmpack.o
mingw32-make[2]: *** [CMakeFiles\mpack.dir\build.make:60: usr/lib/luarocks/rocks/mpack] Error 1
mingw32-make[2]: Leaving directory 'C:/projects/neovim/.deps'
mingw32-make[1]: *** [CMakeFiles\Makefile2:99: CMakeFiles/mpack.dir/all] Error 2
mingw32-make[1]: Leaving directory 'C:/projects/neovim/.deps'
mingw32-make: *** [Makefile:83: all] Error 2

[justinmk]

Merged. @joshleeb thanks for the attention to detail.

Granular commits are appreciated if they explain something that's not obvious by the code change, otherwise just name them "fixup" and squash them later.