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

Reply via email to