2016-05-02 13:15 GMT+03:00 Bram Moolenaar <[email protected]>: > > Nikolay Pavlov wrote: > >> 2016-05-02 0:06 GMT+03:00 Bram Moolenaar <[email protected]>: >> > >> > Patch 7.4.1816 >> > Problem: Looping over a null list throws an error. >> > Solution: Skip over the for loop. >> > Files: src/eval.c, src/testdir/test_expr.vim >> > >> > >> > *** ../vim-7.4.1815/src/eval.c 2016-05-01 14:22:12.359965167 +0200 >> > --- src/eval.c 2016-05-01 22:55:16.965677362 +0200 >> > *************** >> > *** 3292,3302 **** >> > if (!skip) >> > { >> > l = tv.vval.v_list; >> > ! if (tv.v_type != VAR_LIST || l == NULL) >> > { >> > EMSG(_(e_listreq)); >> > clear_tv(&tv); >> > } >> > else >> > { >> > /* No need to increment the refcount, it's already set for >> > the >> > --- 3292,3307 ---- >> > if (!skip) >> > { >> > l = tv.vval.v_list; >> > ! if (tv.v_type != VAR_LIST) >> > { >> > EMSG(_(e_listreq)); >> > clear_tv(&tv); >> > } >> > + else if (l == NULL) >> > + { >> > + /* a null list is like an empty list: do nothing */ >> > + clear_tv(&tv); >> > + } >> > else >> > { >> > /* No need to increment the refcount, it's already set for >> > the >> > *** ../vim-7.4.1815/src/testdir/test_expr.vim 2016-04-20 >> > 14:59:19.047369459 +0200 >> > --- src/testdir/test_expr.vim 2016-05-01 22:52:15.147777312 +0200 >> > *************** >> > *** 83,85 **** >> > --- 83,92 ---- >> > call add(x, 'foo') >> > call assert_equal(['foo'], y) >> > endfunc >> > + >> > + func Test_loop_over_null_list() >> > + let null_list = submatch(1, 1) >> >> `v:_null_list` would be clearer. This code looks rather strange and >> depends on `submatch(1, 1)` return value when there is no submatch. >> And the fact that `submatch(1, 1)` returns NULL list is AFAIK not >> tested anywhere (and actually you can’t test it without at least >> something like id() function from Python (this one returns object >> address as an integer)). > > It's clear that for normal use a null list only happens when there is an > error. In most cases we fall back to behaving like it's an empty list. > But as we discussed before, we should return a real empty list in case > there is not really an error, so that the list can be used (e.g. to add > an element to). > > We could add a variable specific for testing. We should clearly mark > them as such. Perhaps v:test_val_null_list? Although these v: > variables take up some space even when not testing. An alternative is > to use a function: test_get_null_list(). We already have > garbagecollect_for_testing(), but prepending test_ helps to keep them > together.
v:test_val_null_list looks better. I would not believe that function will take significantly less space then a variable. > > -- > So when I saw the post to comp.editors, I rushed over to the FTP site to > grab it. So I yank apart the tarball, light x candles, where x= the > vim version multiplied by the md5sum of the source divided by the MAC of > my NIC (8A3FA78155A8A1D346C3C4A), put on black robes, dim the lights, > wave a dead chicken over the hard drive, and summon the power of GNU GCC > with the magic words "make config ; make!". > [Jason Spence, compiling Vim 5.0] > > /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
