Mercurial > vim
view .github/ISSUE_TEMPLATE/feature_request.md @ 33404:9b35b4c6df4c v9.0.1960
patch 9.0.1960: Make CI checks more strict
Commit: https://github.com/vim/vim/commit/f7f746b1672909ae57d2eec97253d6627f6c0887
Author: Yee Cheng Chin <ychin.git@gmail.com>
Date: Sat Sep 30 12:28:50 2023 +0200
patch 9.0.1960: Make CI checks more strict
Problem: Make CI checks more strict
Solution: Add -Wstrict-prototypes -Wmissing-prototypes to CI,
fix uncovered problems
Add -Wstrict-prototypes -Wmissing-prototypes warnings check to CI
Add two new warnings to CI, silence some Perl related build-warnings:
- `strict-prototypes` helps prevent declaring a function with an empty
argument list, e.g. `int func()`. In C++, that's equivalent to `int
func(void)`, but in C, that means a function that can take any number
of arguments which is rarely what we want.
- `missing-prototypes` makes sure we use `static` for file-only internal
functions. Non-static functions should have been declared on a
prototype file.
- Add `no-compound-token-split-by-macro` to the perl cflags, since it
throws out a bunch of perl-related warnings that make the CI log
unnecessary verbose and hard to read. This seems to happen only with
clang 12 and above.
When applying those changes, it already uncovered a few warnings, so fix
up the code as well (fix prototypes, make the code static, remove
shadowed var declaration)
GTK header needs to have #pragma warning suppressiong because GTK2
headers will warn on `-Wstrict-prototypes`, and it's included by gui.h
and so we can't just turn off the warning in a couple files.
closes: #13223
closes: #13226
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
author | Christian Brabandt <cb@256bit.org> |
---|---|
date | Sat, 30 Sep 2023 12:45:05 +0200 |
parents | 4fdc8319ab24 |
children |
line wrap: on
line source
--- name: Feature request about: Suggest an enhancement for Vim title: '' labels: enhancement --- _Instructions: Replace the template text and remove irrelevant text (including this line)_ **Is your feature request about something that is currently impossible or hard to do? Please describe the problem.** A clear and concise description of what is hard to do. Ex. It is difficult to [...] when [...] (If it is related to runtime files, please check their header for where to discuss enhancements.) **Describe the solution you'd like** A clear and concise description of what you want to happen. **Describe alternatives you've considered** A clear and concise description of any alternative solutions or features you've considered. **Additional context** Add any other context or screenshots about the feature request here.