[vim/vim] Add additional autocmd tests (PR #10507)
Yegappan Lakshmanan
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/10507
Commit Summary
- 4a447c3 Add additional autocmd tests
File Changes
(4 files)
- M src/autocmd.c (36)
- M src/testdir/gen_opt_test.vim (2)
- M src/testdir/test_autocmd.vim (10)
- M src/testdir/test_cmdline.vim (9)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
codecov[bot]
Codecov Report
Merging #10507 (4a447c3) into master (b5912e0) will increase coverage by
0.90%.
The diff coverage is92.30%.
@@ Coverage Diff @@ ## master #10507 +/- ## ========================================== + Coverage 81.65% 82.56% +0.90% ========================================== Files 158 148 -10 Lines 185232 172611 -12621 Branches 41899 39028 -2871 ========================================== - Hits 151260 142523 -8737 + Misses 21519 17499 -4020 - Partials 12453 12589 +136
| Flag | Coverage Δ | |
|---|---|---|
| huge-clang-none | 82.56% <92.30%> (+<0.01%) |
⬆️ |
| linux | 82.56% <92.30%> (+<0.01%) |
⬆️ |
| mingw-x64-HUGE | ? |
|
| mingw-x64-HUGE-gui | ? |
|
| windows | ? |
Flags with carried forward coverage won't be shown. Click here to find out more.
| Impacted Files | Coverage Δ | |
|---|---|---|
| src/autocmd.c | 86.07% <92.30%> (+0.90%) |
⬆️ |
| src/highlight.c | 78.69% <0.00%> (-2.70%) |
⬇️ |
| src/misc2.c | 86.38% <0.00%> (-2.62%) |
⬇️ |
| src/time.c | 87.08% <0.00%> (-2.56%) |
⬇️ |
| src/buffer.c | 84.15% <0.00%> (-2.39%) |
⬇️ |
| src/help.c | 80.07% <0.00%> (-2.38%) |
⬇️ |
| src/libvterm/src/screen.c | 51.96% <0.00%> (-2.04%) |
⬇️ |
| src/session.c | 63.15% <0.00%> (-1.94%) |
⬇️ |
| src/gui.c | 71.15% <0.00%> (-1.88%) |
⬇️ |
| src/menu.c | 81.03% <0.00%> (-1.86%) |
⬇️ |
| ... and 129 more |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing data
Powered by Codecov. Last update b5912e0...4a447c3. Read the comment docs.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Not sure why you remove that check for NULL, theoretically it can happen if the string value is NULL.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
Not sure why you remove that check for NULL, theoretically it can happen if the string value is NULL.
vim-dev ML
On Wed, Jun 1, 2022 at 4:33 AM Bram Moolenaar ***@***.***>
wrote:
> Not sure why you remove that check for NULL, theoretically it can happen
> if the string value is NULL.
>
>
> I removed the NULL check because it is redundant and will never be hit.
The pointer is validated just before this check in the if-else block.
Regards,
Yegappan
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
checks the value of "end", while the value of "p" is actually used.
"end" is overwritten by the call to event_name2nr().
In the "if" block there is this:
p = eli->li_tv.vval.v_string;
A string may have a NULL value. Oh, that is actually checked just
above.
Let me change that to make it clearer, and also to avoid a compiler
warning for uninitialized variable.
--
There are 2 kinds of people in my world: those who know Unix, Perl, Vim, GNU,
Linux, etc, and those who know COBOL. It gets very difficult for me at
parties, not knowing which group to socialise with :-)
Sitaram Chamarty
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
vim-dev ML
> On Wed, Jun 1, 2022 at 4:33 AM Bram Moolenaar ***@***.***>
> wrote:
>
> > Not sure why you remove that check for NULL, theoretically it can happen
> > if the string value is NULL.
>
> I removed the NULL check because it is redundant and will never be hit.
> The pointer is validated just before this check in the if-else block.
That is true for the "else" block. The code is confusing, since it
checks the value of "end", while the value of "p" is actually used.
"end" is overwritten by the call to event_name2nr().
In the "if" block there is this:
p = eli->li_tv.vval.v_string;
A string may have a NULL value. Oh, that is actually checked just
above.
Let me change that to make it clearer, and also to avoid a compiler
warning for uninitialized variable.
--
There are 2 kinds of people in my world: those who know Unix, Perl, Vim, GNU,
Linux, etc, and those who know COBOL. It gets very difficult for me at
parties, not knowing which group to socialise with :-)
Sitaram Chamarty
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.