Problem:    illegal memory access when completing with invalid bytes.
Solution:   Avoid going over the end of the completion text.

vim/vim@4b28ba3

Co-authored-by: Bram Moolenaar <Bram@vim.org>

It no longer hangs on Windows CI.

Problem:  'shortmess' "F" flag doesn't work properly with 'autoread'
          (after 9.1.0154)
Solution: Hide the file info message instead of the warning dialog
          (zeertzjq)

closes: vim/vim#14159
closes: vim/vim#14158

https://github.com/vim/vim/commit/8a01744c563f615ae7f6b3ab7f5208214a45a8e2

Problem:  shm=F not respected when reloading buffer with 'autoread'
Solution: Check SHM_FILEINFO in buf_check_timestamp()
          (Shougo Matsushita)

closes: vim/vim#14144

https://github.com/vim/vim/commit/9db39b0ec90600bb41faec3a12b934b17c298b1f

Co-authored-by: Shougo Matsushita <Shougo.Matsu@gmail.com>

Problem:  Duplicate assignment in f_getregion().
Solution: Remove the duplicate assignment.  Also improve getregion()
          docs wording and fix an unrelated typo (zeertzjq)

closes: vim/vim#14154

https://github.com/vim/vim/commit/0df8f93bdaea77a1afb9f4eca94fe67ec73e6df2

Problem:  can only call getregion() for current buffer
Solution: Allow to retrieve selections from different buffers
          (Shougo Matsushita)

closes: vim/vim#14131

https://github.com/vim/vim/commit/84bf6e658da51126bdd2e50af1f40cabd149343f

Co-authored-by: Shougo Matsushita <Shougo.Matsu@gmail.com>

Problem:  v:echospace wrong after setting invalid value to 'showcmdloc'.
Solution: Only call comp_col() if value is valid.
          (zeertzjq)

closes: vim/vim#14119

https://github.com/vim/vim/commit/c27fcf4857228bc650943246ffbba444a085b3e7

Problem:  the amount of available space (v:echospace) on the command
          line is not correct when showcmdloc is drawn into the
          statusline or tabline.
Solution: only add SHOWCMD_COLS to the shown command column when
          'showcmdloc' is set to last (Sam-programs)

closes: vim/vim#14108

https://github.com/vim/vim/commit/062141b1a70cf5364e6983ec901282e0111745c1

Co-authored-by: Sam-programs <130783534+Sam-programs@users.noreply.github.com>

Problem:  getregion() needs more tests
Solution: Run the getregion() test in both the legacy and Vim9 contexts
          (Yegappan Lakshmanan)

closes: vim/vim#14114

https://github.com/vim/vim/commit/4d55c54e307c27600c644c6631ff673ed89dd53a

Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>

Problem:  [security]: autocmd cause use-after-free in set_curbuf()
          (kawarimidoll)
Solution: check side-effect of BufLeave autocommand, when the number
          of windows changed, close windows containing buffers that will
          be wiped, if curbuf changed unexpectedly make sure b_nwindows
          is decremented otherwise it cannot be wiped

set_curbuf() already makes some efforts to ensure the BufLeave
autocommands do not cause issues.  However there are still 2 issues
that are not taken care of:

1) If a BufLeave autocommand opens a new window containing the same
buffer as that is going got be closed in close_buffer() a bit later,
we suddenly have another window open, containing a free'd buffer.  So we
must check if the number of windows changed and if it does (and the
current buffer is going to be wiped (according to the 'bufhidden'
setting), let's immediately close all windows containing the current
buffer using close_windows()

2) If a BufLeave autocommand changes our current buffer (displays it in
the current window), buf->b_nwindow will be incremented. As part of
set_curbuf() we will however enter another buffer soon, which means, the
newly created curbuf will have b_nwindows still have set, even so the
buffer is no longer displayed in a window. This causes later problems,
because it will no longer be possible to wipe such a buffer. So just
before entering the final buffer, check if the curbuf changed when
calling the BufLeave autocommand and if it does (and curbuf is still
valid), decrement curbuf->b_nwindows.

Both issues can be verified using the provided test (however the second
issue only because such an impacted buffer won't be wiped, causing
futher issues in later tests).

fixes: vim/vim#13839
closes: vim/vim#14104

https://github.com/vim/vim/commit/55f8bba73be5f9c3a5a4d0d6c5f56e65f2c7d3fc

Co-authored-by: Christian Brabandt <cb@256bit.org>