I failed to deduce why analyzer thinks E882 may not be triggered, though
conditions for triggering it are strange: it would trigger E882 only in the
single case “function returned non-number”. Cases “function thrown exception”,
or “built-in sorter encountered error” will neither yield E882 nor stop
sort()/uniq().
Note though that searching test code revealed that neither E702 nor E882 are not
tested anywhere.
MSBuild still returns a non-zero exit code because it detects the word "error" in the stdout which is caused by some of the test names such as api/buf {get,set,del}_line get_line : out-of-bounds is an error.
CMake mailing list thread:
https://cmake.org/pipermail/cmake-developers/2015-October/026775.html
There isn't any good solution for it, so I modified the build script to detect the error message printed by RunTests.cmake.
closes#7698
Wrapping a command in double-quotes allows cmd.exe to safely dequote the
entire command as if the user entered the entire command in an
interactive prompt. This reduces the need to escape nested and uneven
double quotes.
The `/s` flag of cmd.exe makes the behaviour more reliable:
:set shellcmdflag=/s\ /c
Before this patch, cmd.exe cannot use cygwin echo.exe (as opposed to
cmd.exe `echo` builtin) even if it is wrapped in double quotes.
Example:
:: internal echo
> cmd /s /c " echo foo\:bar" "
foo\:bar"
:: cygwin echo.exe
> cmd /s /c " "echo" foo\:bar" "
foo:bar
During provider dispatch, eval_call_provider() saves global
state--including pointers, such as `autocmd_fname`--into
`provider_caller_scope` which is later restored by f_rpcrequest().
But `autocmd_fname` is special-cased in eval_vars(), for performance
(see Vim patch 7.2.021; this is also the singular purpose of the
`autocmd_fname_full` global. Yay!)
If eval_vars() frees `autocmd_fname` then its provider-RPC-scoped alias
becomes a problem.
Solution: Don't free autocmd_fname in eval_vars(), just copy into it.
closes#5245closes#5617
Reference
------------------------------------------------------------------------
Vim patch 7.2.021
f6dad43c98
Problem: When executing autocommands getting the full file name may be
slow. (David Kotchan)
Solution: Postpone calling FullName_save() until autocmd_fname is used.
vim_dev discussion (2008): "Problem with CursorMoved AutoCommand when
Editing Files on a Remote WIndows Share"
https://groups.google.com/d/msg/vim_dev/kj95weZa_eE/GTgj4aq5sIgJ
Infinite timeout results in hangs which waste time. If some test needs
longer than 10s to wait for a message, it should specify the timeout
explicitly.
