Block inside container literal causes broken indentation

[msanders]

The following currently doesn't work correctly in space commander:

@implementation Example

- (void)callbackWithSuccess:(dispatch_block_t)success
{
    NSError *error = nil;
    [self createModelWithMapping:@{
        @"key": [NSArray ins_arrayWithCount:5 usingBlock:^__nullable id (NSUInteger idx) {
            return nil;
        }],
    } error:&error];
    if (success) {
        success();
    }
}

@end

Instead, it is formatted as:

@implementation Example

- (void)callbackWithSuccess:(dispatch_block_t)success
{
    NSError *error = nil;
    [self createModelWithMapping:@{
        @"key": [NSArray ins_arrayWithCount:5 usingBlock:^__nullable id (NSUInteger idx) {
            return nil;
}],
} error:&error];
if (success) {
    success();
}
}

@end

Is there a way to work around this? It seems to be a common use case, for example when defining Mantle value transformers.

[alanf]

This is an interesting example. It looks like the first closing brace is interpreted by clang-format as being paired with the function definition open brace, rather than with the dictionary literal open brace.

[msanders]

@alanf Any ideas on a suggested workaround? This is the only thing preventing us from turning on spacecommander everywhere in our codebase. The first thought that comes to mind is possibly a pre/post-processor? (for example, maybe as a hack we could just comment and uncomment any blocks inside dictionary literals?)

[alanf]

@msanders how about using

// clang-format off
and
// clang-format on

?

I'll create a PR that demonstrates what this looks like and also includes a note in the documentation

[msanders]

@alanf Thanks for the suggestion. Unfortunately this isn't a great workaround for our team though, since it requires all engineers to be cognizant of this bug in clang-format when writing blocks.

[alanf]

Let me know if #48 looks like a potential solution. I'd like to unblock your team from using Space Commander!

[msanders]

@alanf Thanks, you've really gone above and beyond here. I'll take a look at this later today and see if it fixes the issue for our codebase.