LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 17851 - Please add a style based on the GNU coding conventions
Summary: Please add a style based on the GNU coding conventions
Status: RESOLVED FIXED
Alias: None
Product: clang
Classification: Unclassified
Component: Formatter (show other bugs)
Version: unspecified
Hardware: PC All
: P enhancement
Assignee: Alexander Kornienko
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-08 15:00 PST by Diego Novillo
Modified: 2014-08-05 07:20 PDT (History)
3 users (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Diego Novillo 2013-11-08 15:00:49 PST
Would it be possible to add a GNU coding style?  The full style description for the GNU coding conventions is at http://www.gnu.org/prep/standards/standards.html#Writing-C.

Out of those conventions, I think these are the more prominent ones:

- Line length is 80 columns.

- Open brace for a function body is always in column 1.
- The name of the function is always at column 1.
The above two rules mean that function definition 'int foo(int x, int y) { ... }' must be formatted as:

int
foo (int x, int y)
{
  ...
}

- There must always be a space between a function name and the open parens. So, it's "foo (x, y)", never "foo(x, y)". Yeah, I hate it too.

- Open braces for structs/unions can be on the same line or column 1.

- There is always a space after a comma.

- Braces always go on the next line, indented by 2:

int
foo (int x, int y)
{
  while (x < y)
    {
      do_something_with (x);
      x++;
    }
  return x;
}

- When splitting expressions into multiple lines, split BEFORE the operator:

  if (this_is_a_very_long_predicate
      && x > this_other_value)
    {
      ...
    }

- do-while statements are formatted like:

  do
    {
      ...
    }
  while (...);


Thanks.
Comment 1 Alexander Kornienko 2013-12-16 03:42:50 PST
Starting from r197138 clang-format supports most of GNU style conventions. You can try this using -style=gnu or putting "BasedOnStyle: GNU" in your project's .clang-format file.

At the moment, there are at least two unsupported features:
  * always breaking before function names;
  * formatting of pre-standard C function argument lists: void f (a, b) int a, char b;

The absence of the former feature doesn't allow to format whole files, but you can still format function bodies using the editor integration. I don't know how much we care about the latter.

Please report, what other features would you like to be implemented for the GNU style support to be usable.
Comment 2 Daniel Jasper 2014-08-05 07:20:40 PDT
Function return types are now forced on their own line in GNU style (r214858).

I'll mark this as fixed. Please reopen individual bug reports if you find missing features. Or reopen this one if the pre-standard C function argument lists are important (I can't really judge that).