From 30b7d09d7a3151118d6ee6dc8582a3eb87286ef4 Mon Sep 17 00:00:00 2001 From: Ben Hamilton Date: Fri, 8 Feb 2019 15:55:18 +0000 Subject: [Format/ObjC] Fix [foo bar]->baz formatting as lambda arrow Summary: Currently, `UnwrappedLineParser` thinks an arrow token after an ObjC method expression is a C++ lambda arrow, so it formats: ``` [foo bar]->baz ``` as: ``` [foo bar] -> baz ``` Because `UnwrappedLineParser` runs before `TokenAnnotator`, it can't know if the arrow token is after an ObjC method expression or not. This diff makes `TokenAnnotator` remove the TT_LambdaArrow on the arrow token if it follows an ObjC method expression. Test Plan: New test added. Ran test with: % ninja FormatTests && ./tools/clang/unittests/Format/FormatTests Confirmed test failed before diff and passed after diff. Reviewers: krasimir, djasper, sammccall Reviewed By: sammccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57923 llvm-svn: 353531 --- clang/lib/Format/UnwrappedLineParser.cpp | 3 +++ 1 file changed, 3 insertions(+) (limited to 'clang/lib/Format/UnwrappedLineParser.cpp') diff --git a/clang/lib/Format/UnwrappedLineParser.cpp b/clang/lib/Format/UnwrappedLineParser.cpp index f6727fcfa97..80bfca644c9 100644 --- a/clang/lib/Format/UnwrappedLineParser.cpp +++ b/clang/lib/Format/UnwrappedLineParser.cpp @@ -1426,6 +1426,9 @@ bool UnwrappedLineParser::tryToParseLambda() { nextToken(); break; case tok::arrow: + // This might or might not actually be a lambda arrow (this could be an + // ObjC method invocation followed by a dereferencing arrow). We might + // reset this back to TT_Unknown in TokenAnnotator. FormatTok->Type = TT_LambdaArrow; nextToken(); break; -- cgit v1.2.3