Closed ghost closed 10 years ago
Possibly a naive question but what is the bug? Both C and Objective-C string literals are concatenated when they're beside each other (so @"foo" @"bah"
is the same as @"foobah"
), so these would seem to be identical to my eye. If this is what you're referring to a ColumnLimit of 0 might give you the behaviour you were expecting.
ya that is actually the same array / strings. clang is splitting that string over multiple lines to fit the column limit.
@travisjeffery Hmm, so is this the expected behavior even if you have the following config: ColumnLimit: 100 PenaltyBreakString: 10000 PenaltyExcessCharacter: 1
It still seems to me like there is a bug unless I am just confused about the behavior of this.
I would expect a 200 character string to have a penalty of 100 from the excess characters, which would be less than the 10000 penalty from breaking the string, however it appears to just always split the string if you have a ColumnLimit > 0 despite the penalties.
Unfortunately we tend to get a lot of these in our codebase, that end up causing clang warnings from "Concatenated NSString literal for an NSArray expression - possibly missing a comma"
Have set PenaltyBreakString: 2147483647
and clang-format is still breaking Objective-C string literals.
In my eyes, this issue should be reopened
It also seems to be a bug for me. I thought that PenaltyBreakString
should always have a higher priority than the ColumnLimit
. Otherwise, is there a way for us to keep these two settings effective at the same time?
In my eyes, this issue should be reopened
It's not an issue with ClangFormat-Xcode. You need to report these issues to the LLVM Bugzilla.
I cloned and pulled the latest release of ClangFormat, which still exhibits this bug. An NSArray literal containing NSString literals before running ClangFormat:
The same NSArray literal after running ClangFormat: