Closed llvmbot closed 10 years ago
I think the solution here is to disable clang-format for certain regions of code (#20463 ). With macros, it is otherwise always possible to come up with something that clang-format doesn't understand and thus breaks.
I've also run into a similar case, where after macro expansion, the string is used as a label in inline assembly. Adding whitespace caused the label name to have whitespace, which caused a compile failure. Arguably, clang-format should not be used for non-C code, but inline assembly is kind of special.
Thx for the explanation. One question we already had was whether we'd want to make it possible to configure a few "stringify macro identifiers" (we have similar problems in the VS headers). I think that the use case for this is becoming more and more compelling. Thanks for reporting!
From the Qt documentation: "Qt uses normalized signatures to decide whether two given signals and slots are compatible. Normalization reduces whitespace to a minimum, moves 'const' to the front where appropriate, removes 'const' from value types and replaces const references with values."
The connects will still work with any combination of whitespace characters but since your signature doesn't have to be normalized you save some time.
For further clarification: http://marcmutz.wordpress.com/effective-qt/prefer-to-use-normalised-signalslot-signatures/
Can you expand on why changing the whitespace here is a problem for the Qt case? (note that clang-format does not know about macro definitions, it only lexes)
Extended Description
define MAKE_STRING(str) #str
MAKE_STRING(function(ParamType1*,ParamType2));
is changed to MAKE_STRING(function(ParamType1 *, ParamType2));
The output should be unchanged, because it is used as a string and changing it could change the behaviour of the program.
This is usually used in Qt's Signal & Slot system: connect(sender, SIGNAL(destroyed(QObject)), this, SLOT(objectDestroyed(Qbject)));