[cfe-dev] libformat / clang-format for table-like code

[mlimber via cfe-dev]

This Q&A asks about using clang-format to support table-like code:

http://stackoverflow.com/questions/38022831/how-to-make-clang-format-respect-table-like-code-formatting

Motivating examples for this sort of thing include GUI construction code
(e.g., this Qt sample code:
http://doc.qt.io/qt-5/qtwidgets-widgets-groupbox-example.html#window-class-implementation
).

The two cases mentioned in the Q&A could be slightly expanded to:

1. Braced initializers (including C++11 initializer lists).
2. Function calls

Each could include:

a. Rows and columns within a single statement (shown in Q&A)

b. Rows in different statements with columns following the same pattern for
each row (shown in the Q&A with Create() functions -- same function call,
same number of params, etc.).

c. Nested tables,e.g.,

  S s = {
    { { "Dubs", abc,    123 },
      { "X",    n,      m   },
      { "YZ",   ij / q, kl  } },

    { { "Dubs", abc,    123 },
      { "X",    n,      m   },
      { "YZ",   ij / q, kl  } },
  };

vs. (perhaps depending on max line length or user option)

  S s = {
    { { "Dubs", abc,    123 }, { "X",    n,      m   }, { "YZ",   ij / q,
kl  } },
    { { "X",    n,      m   }, { "YZ",   ij / q, kl  }, { "Dubs", abc,
123 } },
  };

Similar nesting could be done with function calls within function call
params.

d. Rows and columns following a looser pattern (e.g., different function
names, different number of params, optionally keeping return values):

  w  = CreateDubs( "Dubs", abc,    123 );
  x  = CreateEx(   "X",    n           ); // Two params!
  CreateWhyZed(    "YZ",   ij / q, kl  ); // Ignore return value

My question is, how hard would it be to modify LibFormat to support some or
all of these cases?

I'm an experienced developer, but I've not done LLVM development before.
I'm potentially interested in working on it and submitting a patch, but I
thought I would ask here first in case you can tell me that it would be an
exercise in futility or would be unlikely to be accepted as a feature.
Would it have to support all of these cases to be accepted?

Cheers!

M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160627/deb6e155/attachment.html>