Found on Geany-lsp but also happens on b02ee9a95a48690836f08ba10ccc9db89ee89c10 on Geany so reported here.
``` Found ninja-1.10.0 at /usr/bin/ninja [3/201] Compiling C object 'tagmanager@sta/src_tagmanager_tm_ctags.c.o' ../src/tagmanager/tm_ctags.c: In function ‘rename_anon_tags’: ../src/tagmanager/tm_ctags.c:323:40: warning: array subscript has type ‘char’ [-Wchar-subscripts] 323 | anon_counter = ++anon_counter_table[kind]; | ^ [54/201] Compiling C object 'ctags@sta/ctags_main_parse.c.o' ../ctags/main/parse.c:5478:26: warning: ‘CTagsSelfTestParser’ defined but not used [-Wunused-function] 5478 | static parserDefinition *CTagsSelfTestParser (void) | ^~~~~~~~~~~~~~~~~~~ ../ctags/main/parse.c:5158:26: warning: ‘CTagsParser’ defined but not used [-Wunused-function] 5158 | static parserDefinition *CTagsParser (void) | ^~~~~~~~~~~ ../ctags/main/parse.c:5125:26: warning: ‘FallbackParser’ defined but not used [-Wunused-function] 5125 | static parserDefinition *FallbackParser (void) | ^~~~~~~~~~~~~~ [110/201] Compiling C object 'ctags@sta/ctags_parsers_markdown.c.o' ../ctags/parsers/markdown.c: In function ‘findMarkdownTags’: ../ctags/parsers/markdown.c:385:16: warning: unused variable ‘line’ [-Wunused-variable] 385 | unsigned int line = (unsigned int)getInputLineNumber (); | ^~~~ ```
What are the "ELEMENT" warnings?
For the Geany one(s), see #3665.
For CTags, see https://github.com/universal-ctags/ctags/pull/3840 for fixing some of them; but CTags has *many* warnings (at least with my wonderful flags :slightly_smiling_face: ) that are not trivial to fix; but please, get a stab at some and submit that upstream :wink: I'll probably do some of that over time, but it's not trivial. Which flags are you using yourself? Maybe we could start at what's visible be somebody a tad less extremist than myself :smile:
What are the "ELEMENT" warnings? All I can think of would be https://github.com/geany/geany/pull/2398 -- doesn't this work for you? or is it something else?
Hmm, maybe I built before I pulled and didn't notice they are gone when I re-built after :-) Anyway yeah they seem to be gone now (`touch highlightingmappings.h; meson compile -C build`).
For the Geany one(s), see https://github.com/geany/geany/pull/3665.
Ok, thats such an omnibus PR that I missed it.
Maybe we could start at what's visible be somebody a tad less extremist than myself 😄
Totally un-extremist (and lazy) defaults for GCC 9.4.0 (I'm back on my LTS machine).
Ok, #3665 removes all warnings except the above ctags ones with `--warnlevel 1` but goes crazy again with `--warnlevel 2` so maybe thats a place to start :-)
/me just learned that Meson had a built-in flag to enable some [random compiler warnings](https://mesonbuild.com/Builtin-options.html#details-for-warning_level). Half-neat, half-silly, but well. But yes, with `-Wextra` you're *gotta* want `-Wno-unused-parameter` at *least*.
@b4n has gotta be using `meson configure --warnlevel everything` ???? (my old LTS meson doesn't have that)
But yes, with -Wextra you're gotta want -Wno-unused-parameter at least.
How are you gonna get rid of the unused parameter warnings on all the GTK callbacks?
How are you gonna get rid of the unused parameter warnings on all the GTK callbacks?
`-Wno-unused-parameter` :smile: If we really want that one, we could also sprinkle the code with `G_GNUC_UNUSED` all over the place; but is it worth it?
Oh, __NO__unused_parameters, yeah.
we could also sprinkle the code with G_GNUC_UNUSED all over the place; but is it worth it?
Well, thats GUNC only IIUC, unlike G_NORETURN which supports multiple compilers. So probably not. (unless "somebody" created b4nlib and B_UNUSED :-)
Of course C++ indicates it with no name on the parameter declaration, but does C follow that sensible strategy? NO!! C23 adds ugly `[[maybe_unused]]` to function parameters as well ... sigh [end rant]
Well, thats GUNC only IIUC, unlike G_NORETURN which supports multiple compilers.
Does anybody *actually* cares about warnings from a non-GNUC compiler? I mean, it's supported by GCC and clang, and I don't think any of us is using anything else?
Of course C++ indicates it with no name on the parameter declaration, but does C follow that sensible strategy? NO!! C23 adds ugly `[[maybe_unused]]` to function parameters as well ... sigh [end rant]
IIUC [C23](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf#subsection.6.9.1) [does](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2510.pdf) have that C++ feature (thanks [Wikipedia](https://en.wikipedia.org/wiki/C23_(C_standard_revision)#Syntax) for the links)
it's supported by GCC and clang
If `G_GNUC` identifies clang as well then fine.
Does anybody actually cares about warnings from a non-GNUC compiler?
Neat, we can remove 90% of the autotools test crap :-)
IIUC [C23](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf#subsection.6.9.1) [does](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2510.pdf) have that C++ feature (thanks [Wikipedia](https://en.wikipedia.org/wiki/C23_(C_standard_revision)#Syntax) for the links)
Ok, finally!! But then why add the attribute for function parameters ... oh maybe a macro expansion might make it unused "eeeeek macro!!" /me jumps on chair.
Does anybody actually cares about warnings from a non-GNUC compiler?
Neat, we can remove 90% of the autotools test crap :-)
Note that I'm saying "*about warnings* form a non-GNUC compiler", not that we shouldn't *build* fine with any random compliant compiler -- which we definitely should (I'm gonna add "in the bounds of the reasonable" before anybody finds a silly compiler nobody uses that doesn't support a silly thing all others do just to prove me wrong -- although I'd be happy to try and fix it if it's a compliance issue reasonably easy to fix anyway).
Vs compilers? :smiling_imp:
I dare you try it 🤣 Seriously though it might even work.
I dare you try it 🤣
Probably on WSL it will. When I get my new development machine I will keep it dual boot, so I can do those sorts of things, "soon" :grin:
Beware, you'll become our new Windows expert in no time!
github-comments@lists.geany.org