Jeff Law <jeffreya...@gmail.com> writes: > On 9/18/24 10:11 AM, Jakub Jelinek wrote: >> Hi! >> >> Trailing blanks is something even git diff diagnoses; while it is a coding >> style issue, if it is so common that git diff diagnoses it, I think it could >> be useful to various projects to check that at compile time.
Nice! Thanks for doing this. >> Dunno if it should be included in -Wextra, currently it isn't, and due to >> tons of trailing whitespace in our sources, haven't enabled it for when >> building gcc itself either. >> >> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? >> >> Note, git diff also diagnoses indentation with tab following space, wonder >> if we couldn't have trivial warning options where one would simply ask for >> checking of indentation with no tabs, just spaces vs. indentation with >> tabs followed by spaces (but never tab width or more spaces in the >> indentation). I think that would be easy to do also on the libcpp side. >> Checking how much something should be exactly indented requires syntax >> analysis (at least some limited one) and can consider columns of first token >> on line, but what the exact indentation blanks were is something only libcpp >> knows. >> >> 2024-09-18 Jakub Jelinek <ja...@redhat.com> >> >> libcpp/ >> * include/cpplib.h (struct cpp_options): Add cpp_warn_trailing_blanks >> member. >> (enum cpp_warning_reason): Add CPP_W_TRAILING_BLANKS. >> * internal.h (struct _cpp_line_note): Document 'B' line note. >> * lex.cc (_cpp_clean_line): Add 'B' line note for trailing blanks >> except for trailing whitespace after backslash. Formatting fix. >> (_cpp_process_line_notes): Emit -Wtrailing-blanks diagnostics. >> Formatting fixes. >> (lex_raw_string): Clear type on 'B' notes. >> gcc/ >> * doc/invoke.texi (Wtrailing-blanks): Document. >> gcc/c-family/ >> * c.opt (Wtrailing-blanks): New option. >> gcc/testsuite/ >> * c-c++-common/cpp/Wtrailing-blanks.c: New test. > I'd tend to think we want this and would want to (at the appropriate > time) turn it on for our builds. Better catch this nit early rather > than at commit/push time IMHO. +1 I'd much rather learn about this kind of error before the code reaches a review tool :) >From a quick check, it doesn't look like Clang has this, so there is no existing name to follow. Richard
