Le 02/10/2021 à 15:51, Saulius Krasuckas a écrit :
Hello folks,
- On 2021-09-29 12:17, Eric Pouech wrote:
For sharing :
- newest gcc version (11) sets by default of bunch of new tests for
code correctness
- it spits out around ten thousand lines of warnings (*), making it
quite impossible to look into compiler output
Eric, thanks for investigating this. I have stopped actively contributing for over 15y already, but I still would like to express my opinion.
The false positives we need to tackle:
A) misleading indentation
GCC11 complains about code like: foo; todo_wine ok(tst, ...); bar;
(gcc11 warns about 'bar ' not being properly indented wrt todo_wine)
I wonder whether/how it differentiates between spaces and tabs here.
doc says that that tabs are expanded by default to 8 characters (can be overriden with tab-stop option)
so much space for playing here
there are (as of today) 817 occurrences of those in wine tree (spread across 127 files) and counts for ~90% (*) of the line of warnings generated by GCC only 2 true positives are generated by this GCC warning
Remarks:
- constructs on a single line don't generate the warning
todo_wine ok(tst, ...); // ok no warning, whatever the indentation of the line wrt the rest of the code
- having the ok(tst, ...) inside a block after the todo_wine doesn't
generate the warning
IMO, it would be nice to have a way to achieve a single indentation style for all todo_wine* names.
Has the community decided on a single opinion (had it any polls) in that regard already? That would help.
no, different authors => different styles
(note that there other culprits as if (0) (but there are others too) that have to be taken into account
- reindent all todo_wine
same as above, but also reindenting the "todo_wine {\n<...>\n}" and the "todo_wine ok()" on a single line constructs pros/cons: indentation isn't used for adding comments to the code (that's what comments are for) cons: large impact on code base
Now as I read source [*], I think it gets down to the macro embedding a for() loop:
128 #define todo_if(is_todo) for (winetest_start_todo(is_todo); \ 129 winetest_loop_todo(); \ 130 winetest_end_todo())
Umm, would adding backslash on the line #130 too help to avoid the warning? No idea since I am away from the compiler/development box.
no the problem doesn't stem from the line after the todo, but the second line after the todo (the bar one above) which gcc doesn't like as not being indented as the todo
thanks for jumping in
A+