[PATCH] [WIP] clang-format: Enforce EOL at EOF as required by C standard
alp at nuanti.com
Sun Oct 6 06:44:21 PDT 2013
On 06/10/2013 14:13, Daniel Jasper wrote:
> Actually, the C++11 standard says:
> "A source ﬁle that is not empty and that does not end in a new-line
> character, or that ends in a new-line character immediately preceded
> by a backslash character before any such splicing takes place, shall
> be processed as if an additional new-line character were appended to
> the ﬁle."
You're right that it's not a hard error in C++, only C, and the remarks
should be updated to reflect that.
> I think this pretty much implies that source files are allowed to not
> end in a newline. Also, I think it is fine for clang-format to not
> alter its input file in this regard. If your VCS requires this,
> configure your editor appropriately ..
If my editor got formatting right, I wouldn't need clang-format :-)
Newline at EOF is certainly part of the coding style on the WebKit
project and checked for during code review. It's always a pain to miss
this and have to go back and fix after the fact.
I can't speak for LLVM but Benjamin Kramer's commit r191857 (Add newline
at eof) suggests it's also part of the coding style here.
Then there's clang r189110 (Respect -Wnewline-eof even in C++11 mode,
<rdar://problem/12922063>) showing that Apple customers also consider
this important with C++ code.
I'm guessing from your response that it's not part of the Google coding
style, so I'll make sure that this check is disabled for C++ sources in
GoogleStyle in the next revision of the patch.
That leaves ChromiumStyle which I don't know enough about. Anyone?
Thanks for the feedback.
> On Sun, Oct 6, 2013 at 2:10 PM, Alp Toker <alp at nuanti.com
> <mailto:alp at nuanti.com>> wrote:
> I'm just putting this patch out there for now as it's been useful
> to us
> in its current state. Some tweaks are needed before this can land:
> 1) It needs a lot of existing unit tests to be fixed. The tests
> could be
> fixed before this patch goes in if anyone has the time to volunteer(!)
> 2) I'm not convinced it's worth even having a 'AllowNoEOL' format flag
> for this. The spec is clear that it's mandatory and many VCS also
> EOL at EOF to work properly.
> 3) That means we might do better to add a command line flag to
> that the code is being formatted for snippets, which uses the
> forSnippets() internally, in which case AllowNoEOL would be made true.
> 4) There are other rules such as trailing slash in 188.8.131.52 that
> I'm not
> sure are handled yet, though these could be worked on subequent to
> patch landing.
> Note also that this fixes a bug in clang-format where it was reporting
> an error code for an empty (zero-sized) file. There's no benefit
> to the
> special case so we can just remove that check now.
> Here's the change:
> clang-format: Enforce EOL at EOF as required by C standard
> This enables end-of-line correction as specified for C-family
> C11 184.108.40.206p2 "A source file that is not empty shall end in a
> The new setting 'AllowNoEOL' and the fluent
> FormatStyle::forSnippets() helper
> are provided for consumers that prefer the old behaviour, which is
> for inline code snippets in documentation.
> the browser experts
the browser experts
More information about the cfe-commits