[cfe-dev] [clang-format] Spacing in C-like casts

[Oleksii Vilchanskyi via cfe-dev]

Is there a possibility in a foreseeable future to separate C and C++ 
languages, so that a proper parsing is done for each and 
language-specific configurations appear? There are already few grammars 
for Java, ObjC and even Javascript, so I make a conclusion that 
clang-format developers, fortunately, do not have any specific prejudice 
towards C, it might be just a matter of time and human resources.

Oleksii


On 17.5.2017 02:58, Richard Smith wrote:
> On 16 May 2017 at 09:15, Oleksii Vilchanskyi via cfe-dev 
> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>
>     Hi everybody,
>
>     Here is a code sample:
>
>
>
>     It was formatted with SpaceAfterCStyleCast: true option. However,
>     while bool was formatted, uint8_t wasn't. Looks like a bug to me.
>     Or is it a feature? Full config is in the attachment.
>
>
> This is one of the cases for which the C and C++ grammars require 
> contextual information to parse, which is where clang-format is most 
> likely to make mistakes. Consider:
>
>   int uint8_t(int); // a function, not a type
>   x = (uint8_t)(123); // not a cast
>
> However, given the relative frequency of that case and of C-style 
> casts, clang-format should probably be assuming that this syntax is a 
> cast. (It's not completely clear, though; parenthesizing the function 
> name is an idiom for turning off ADL, and it's possible that there are 
> codebases that make heavy use of that idiom.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170517/a84a1bcf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_20170516_180750.png
Type: image/png
Size: 79485 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170517/a84a1bcf/attachment.png>