r262806 - [ASTMatchers] Document that isAnyPointer() matcher also matches Objective-C object pointers.
Author: flx
Date: Sun Mar 6 09:27:59 2016
New Revision: 262806
URL: http://llvm.org/viewvc/llvm-project?rev=262806&view=rev
Log:
[ASTMatchers] Document that isAnyPointer() matcher also matches Objective-C
object pointers.
Summary: Add test for Objective-C object pointer matching.
Reviewers: aaron.ballman
Subscribers: klimek
Differential Revision: http://reviews.llvm.org/D17489
Modified:
cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp
Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=262806&r1=262805&r2=262806&view=diff
==
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Sun Mar 6 09:27:59 2016
@@ -3688,15 +3688,22 @@ AST_MATCHER(QualType, isAnyCharacter) {
return Node->isAnyCharacterType();
}
- \brief Matches QualType nodes that are of any pointer type.
+/// \brief Matches QualType nodes that are of any pointer type; this includes
+/// the Objective-C object pointer type, which is different despite being
+/// syntactically similar.
///
/// Given
/// \code
/// int *i = nullptr;
+///
+/// @interface Foo
+/// @end
+/// Foo *f;
+///
/// int j;
/// \endcode
/// varDecl(hasType(isAnyPointer()))
-/// matches "int *i", but not "int j".
+/// matches "int *i" and "Foo *f", but not "int j".
AST_MATCHER(QualType, isAnyPointer) {
return Node->isAnyPointerType();
}
Modified: cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp?rev=262806&r1=262805&r2=262806&view=diff
==
--- cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp (original)
+++ cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp Sun Mar 6 09:27:59 2016
@@ -1483,6 +1483,11 @@ TEST(IsAnyPointer, MatchesPointers) {
EXPECT_TRUE(matches("int* i = nullptr;", varDecl(hasType(isAnyPointer();
}
+TEST(IsAnyPointer, MatchesObjcPointer) {
+ EXPECT_TRUE(matchesObjC("@interface Foo @end Foo *f;",
+ varDecl(hasType(isAnyPointer();
+}
+
TEST(IsAnyPointer, ReportsNoFalsePositives) {
EXPECT_TRUE(notMatches("int i = 0;", varDecl(hasType(isAnyPointer();
}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D17910: clang-format: [JS] Handle certain cases of ASI.
djasper added inline comments.
Comment at: lib/Format/UnwrappedLineParser.cpp:665
@@ +664,3 @@
+// well known cases. It *must not* return true in speculative cases.
+bool UnwrappedLineParser::shouldInsertSemiBetween(FormatToken *Previous,
+ FormatToken *Next) {
Make the parameters const.
I'd also like this to have "JS" in the name somehow. And I am worried that this
might be confusing because it says "shouldInsert", but we don't insert (at
least not yet). Maybe rename this to wouldTriggerJavaScriptASI(...).
Comment at: lib/Format/UnwrappedLineParser.cpp:668
@@ +667,3 @@
+ bool IsOnSameLine =
+ CommentsBeforeNextToken.empty()
+ ? Next->NewlinesBefore == 0
I think it is a bit confusing to hand in both Previous and Next but still rely
on some state of the class. Maybe it is better to move the 4 lines from
nextToken into this function?
Comment at: lib/Format/UnwrappedLineParser.cpp:690
@@ +689,3 @@
+
+bool UnwrappedLineParser::isJavaScriptIdentifier(FormatToken *FormatTok) {
+ return FormatTok->is(tok::identifier) &&
I'd just hand in "Keywords" for now and make this a local (static) function. We
should also refactor this whole thing to not have the class definition in the
header probably.
Also, this is incorrect as it doesn't return true for C++ keywords that aren't
JS keywords, e.g. try "struct". Leave a FIXME for me to sort this out.
Comment at: lib/Format/UnwrappedLineParser.cpp:1942
@@ -1898,2 +1941,3 @@
pushToken(FormatTok);
+ FormatToken *Previous = FormatTok;
readToken();
const?
Comment at: lib/Format/UnwrappedLineParser.cpp:1945
@@ +1944,3 @@
+ if (Style.Language == FormatStyle::LK_JavaScript &&
+ shouldInsertSemiBetween(Previous, FormatTok)) {
+addUnwrappedLine();
In LLVM-style, we generally don't use braces for single-statement ifs.
Comment at: unittests/Format/FormatTestJS.cpp:56
@@ +55,3 @@
+
+ static void verifyFormatNoMessup(
+ llvm::StringRef Code,
I don't think it is useful to do this as there are always ways in which
formatting can fail leaving the input untouched. We still want to verify that
formatting takes place.
To do so, manually mess up the code in some way and use EXPECT_EQ. There should
be various examples in FormatTest.cpp.
http://reviews.llvm.org/D17910
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] r262807 - Update with work items passed in Jacksonville
Author: marshall
Date: Sun Mar 6 11:45:24 2016
New Revision: 262807
URL: http://llvm.org/viewvc/llvm-project?rev=262807&view=rev
Log:
Update with work items passed in Jacksonville
Modified:
libcxx/trunk/www/cxx1z_status.html
Modified: libcxx/trunk/www/cxx1z_status.html
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=262807&r1=262806&r2=262807&view=diff
==
--- libcxx/trunk/www/cxx1z_status.html (original)
+++ libcxx/trunk/www/cxx1z_status.html Sun Mar 6 11:45:24 2016
@@ -77,6 +77,22 @@
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/P0156R0.htm";
>P0156R0LWGVariadic lock_guard(rev
3).Kona
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/P0074R0.html";>P0074R0LWGMaking
std::owner_less more
flexibleKonaComplete3.8
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/P0013R1.html";>P0013R1LWGLogical
type traits rev 2KonaComplete3.8
+
+ http://wg21.link/P0024R2";>P0024R2LWGThe Parallelism
TS Should be StandardizedJacksonville
+ http://wg21.link/P0226R1";>P0226R1LWGMathematical
Special Functions for C++17Jacksonville
+ http://wg21.link/P0220R1";>P0220R1LWGAdopt Library
Fundamentals V1 TS Components for
C++17Jacksonville
+ http://wg21.link/P0218R1";>P0218R1LWGAdopt the File
System TS for C++17Jacksonville
+ http://wg21.link/P0033R1";>P0033R1LWGRe-enabling
shared_from_thisJacksonville
+ http://wg21.link/P0005R4";>P0005R4LWGAdopt not_fn
from Library Fundamentals 2 for
C++17Jacksonville
+ http://wg21.link/P0152R1";>P0152R1LWGconstexpr
atomic::is_always_lock_freeJacksonville
+ http://wg21.link/P0185R1";>P0185R1LWGAdding
[nothrow-]swappable traitsJacksonville
+ http://wg21.link/P0253R1";>P0253R1LWGFixing a design
mistake in the searchers
interfaceJacksonville
+ http://wg21.link/P0025R0";>P0025R0LWGAn algorithm to
"clamp" a value between a pair of boundary
valuesJacksonville
+ http://wg21.link/P0154R1";>P0154R1LWGconstexpr
std::hardware_{constructive,destructive}_interference_sizeJacksonville
+ http://wg21.link/P0030R1";>P0030R1LWGProposal to
Introduce a 3-Argument Overload to
std::hypotJacksonville
+ http://wg21.link/P0031R0";>P0031R0LWGA Proposal to
Add Constexpr Modifiers to reverse_iterator, move_iterator, array and Range
AccessJacksonville
+ http://wg21.link/P0272R1";>P0272R1LWGGive
std::string a non-const .data() member
functionJacksonville
+ http://wg21.link/P0077R2";>P0077R2LWGis_callable,
the missing INVOKE related
traitJacksonville
@@ -185,6 +201,36 @@
http://cplusplus.github.io/LWG/lwg-defects.html#2489";>2489mem_fn()
should be noexceptKonaComplete
http://cplusplus.github.io/LWG/lwg-defects.html#2492";>2492Clarify
requirements for compKonaComplete
http://cplusplus.github.io/LWG/lwg-defects.html#2495";>2495There
is no such thing as an Exception Safety
elementKonaComplete
+
+ http://cplusplus.github.io/LWG/lwg-defects.html#2192";>2192Validity
and return type of std::abs(0u) is
unclearJacksonville
+ http://cplusplus.github.io/LWG/lwg-defects.html#2276";>2276Missing
requirement on
std::promise::set_exceptionJacksonville
+ http://cplusplus.github.io/LWG/lwg-defects.html#2296";>2296std::addressof
should be constexprJacksonville
+ http://cplusplus.github.io/LWG/lwg-defects.html#2450";>2450(greater|less|greater_equal|less_equal)
do not yield a total order for pointersJacksonville
+ http://cplusplus.github.io/LWG/lwg-defects.html#2520";>2520N4089
broke initializing unique_ptr from a
nullptrJacksonville
+ http://cplusplus.github.io/LWG/lwg-defects.html#2522";>2522[fund.ts.v2]
Contradiction in set_default_resource
specificationJacksonville
+ http://cplusplus.github.io/LWG/lwg-defects.html#2523";>2523std::promise
synopsis shows two set_value_at_thread_exit()'s for no apparent
reasonJacksonvilleComplete
+ http://cplusplus.github.io/LWG/lwg-defects.html#2537";>2537Constructors
for priority_queue taking allocators should call
make_heapJacksonville
+ http://cplusplus.github.io/LWG/lwg-defects.html#2539";>2539[fund.ts.v2]
invocation_trait definition definition doesn't work for surrogate
call functionsJacksonville
+ http://cplusplus.github.io/LWG/lwg-defects.html#2545";>2545Simplify
wording for bind without explicitly specified return
typeJacksonville
+ http://cplusplus.github.io/LWG/lwg-defects.html#2557";>2557Logical
operator traits are broken in the zero-argument
caseJacksonvilleComplete
+ http://cplusplus.github.io/LWG/lwg-defects.html#2558";>2558[fund.ts.v2]
Logical operator traits are broken in the zero-argument
caseJacksonvilleComplete
+ http://cplusplus.github.io/LWG/lwg-defects.html#2559";>2559Error
in LWG 2234's resolutionJacksonvilleComplete
+ http://cplusplus.github.io/LWG/l
Re: [PATCH] D17910: clang-format: [JS] Handle certain cases of ASI.
mprobst updated this revision to Diff 49922.
mprobst marked 6 inline comments as done.
mprobst added a comment.
- Handle unary !.
- Address review comments.
http://reviews.llvm.org/D17910
Files:
lib/Format/UnwrappedLineParser.cpp
lib/Format/UnwrappedLineParser.h
unittests/Format/FormatTestJS.cpp
Index: unittests/Format/FormatTestJS.cpp
===
--- unittests/Format/FormatTestJS.cpp
+++ unittests/Format/FormatTestJS.cpp
@@ -49,8 +49,16 @@
static void verifyFormat(
llvm::StringRef Code,
const FormatStyle &Style = getGoogleStyle(FormatStyle::LK_JavaScript)) {
-std::string result = format(test::messUp(Code), Style);
-EXPECT_EQ(Code.str(), result) << "Formatted:\n" << result;
+std::string Result = format(test::messUp(Code), Style);
+EXPECT_EQ(Code.str(), Result) << "Formatted:\n" << Result;
+ }
+
+ static void verifyFormat(
+ llvm::StringRef Expected,
+ llvm::StringRef Code,
+ const FormatStyle &Style = getGoogleStyle(FormatStyle::LK_JavaScript)) {
+std::string Result = format(Code, Style);
+EXPECT_EQ(Expected.str(), Result) << "Formatted:\n" << Result;
}
};
@@ -608,7 +616,7 @@
"}");
}
-TEST_F(FormatTestJS, AutomaticSemicolonInsertion) {
+TEST_F(FormatTestJS, WrapRespectsAutomaticSemicolonInsertion) {
// The following statements must not wrap, as otherwise the program meaning
// would change due to automatic semicolon insertion.
// See http://www.ecma-international.org/ecma-262/5.1/#sec-7.9.1.
@@ -624,6 +632,46 @@
getGoogleJSStyleWithColumns(12));
}
+TEST_F(FormatTestJS, AutomaticSemicolonInsertionHeuristic) {
+ verifyFormat("a\n"
+ "b;",
+ " a \n"
+ " b ;");
+ verifyFormat("a()\n"
+ "b;",
+ " a ()\n"
+ " b ;");
+ verifyFormat("a[b]\n"
+ "c;",
+ "a [b]\n"
+ "c ;");
+ verifyFormat("1\n"
+ "a;",
+ "1 \n"
+ "a ;");
+ verifyFormat("a\n"
+ "1;",
+ "a \n"
+ "1 ;");
+ verifyFormat("a\n"
+ "'x';",
+ "a \n"
+ " 'x';");
+ verifyFormat("a++\n"
+ "b;",
+ "a ++\n"
+ "b ;");
+ verifyFormat("a\n"
+ "!b && c;",
+ "a \n"
+ " ! b && c;");
+ verifyFormat("var a", "var\n"
+"a");
+ verifyFormat("x instanceof String", "x\n"
+ "instanceof\n"
+ "String");
+}
+
TEST_F(FormatTestJS, ClosureStyleCasts) {
verifyFormat("var x = /** @type {foo} */ (bar);");
}
@@ -722,13 +770,13 @@
verifyFormat("var regex = /\a\\//g;");
verifyFormat("var regex = /a\\//;\n"
"var x = 0;");
- EXPECT_EQ("var regex = /'/g;", format("var regex = /'/g ;"));
- EXPECT_EQ("var regex = /'/g; //'", format("var regex = /'/g ; //'"));
- EXPECT_EQ("var regex = /\\/*/;\n"
-"var x = 0;",
-format("var regex = /\\/*/;\n"
- "var x=0;"));
- EXPECT_EQ("var x = /a\\//;", format("var x = /a\\// \n;"));
+ verifyFormat("var regex = /'/g;", "var regex = /'/g ;");
+ verifyFormat("var regex = /'/g; //'", "var regex = /'/g ; //'");
+ verifyFormat("var regex = /\\/*/;\n"
+ "var x = 0;",
+ "var regex = /\\/*/;\n"
+ "var x=0;");
+ verifyFormat("var x = /a\\//;", "var x = /a\\// \n;");
verifyFormat("var regex = /\"/;", getGoogleJSStyleWithColumns(16));
verifyFormat("var regex =\n"
"/\"/;",
@@ -938,38 +986,37 @@
TEST_F(FormatTestJS, TemplateStrings) {
// Keeps any whitespace/indentation within the template string.
- EXPECT_EQ("var x = `hello\n"
+ verifyFormat("var x = `hello\n"
" ${ name}\n"
" !`;",
-format("var x=`hello\n"
+"var x=`hello\n"
" ${ name}\n"
- " !`;"));
+ " !`;");
verifyFormat("var x =\n"
"`hello ${world}` >= some();",
getGoogleJSStyleWithColumns(34)); // Barely doesn't fit.
verifyFormat("var x = `hello ${world}` >= some();",
getGoogleJSStyleWithColumns(35)); // Barely fits.
- EXPECT_EQ("var x = `hello\n"
+ verifyFormat("var x = `hello\n"
" ${world}` >=\n"
"some();",
-format("var x =\n"
+"var x =\n"
"`hello\n"
" ${world}` >= some();",
- getGoogleJSStyleWithColumns(21))); // Barely doesn't fit.
- EXPECT_EQ("var x = `hello\n"
+ getGoogleJSStyleWithColumns(21)); // Barely doesn't fit.
+ verifyFormat("var x = `hello\n"
" ${world}` >= some();",
-format("v
Re: [PATCH] D17910: clang-format: [JS] Handle certain cases of ASI.
mprobst added inline comments. Comment at: unittests/Format/FormatTestJS.cpp:56 @@ +55,3 @@ + + static void verifyFormatNoMessup( + llvm::StringRef Code, djasper wrote: > I don't think it is useful to do this as there are always ways in which > formatting can fail leaving the input untouched. We still want to verify that > formatting takes place. > > To do so, manually mess up the code in some way and use EXPECT_EQ. There > should be various examples in FormatTest.cpp. Done - introduced a `verifyFormat(str, str, style)` to make it a less verbose. http://reviews.llvm.org/D17910 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D17852: Added formatAndApplyAllReplacements that works on multiple files in libTooling.
ioeric marked an inline comment as done. Comment at: include/clang/Tooling/Core/Replacement.h:228 @@ -226,3 +227,3 @@ /// \pre Replacements must be for the same file. -std::vector -calculateChangedRangesInFile(const tooling::Replacements &Replaces); +std::vector calculateChangedRangesInFile(const Replacements &Replaces); + djasper wrote: > This was pre-existing, but I'd remove the "InFile" suffix. It doesn't seem to > add any information. Will remove the "InFile" suffix. Comment at: include/clang/Tooling/Core/Replacement.h:230 @@ +229,3 @@ + +typedef std::map +FileToReplacementsMap; djasper wrote: > I think the key type in a map is always const, so no need for "const". I think "const" is needed since the `Entry` passed to map's `[]` operator is of type `const FileEntry *` in `FileToReplaces[Entry].push_back(Replace)`. The code didn't compile without the "const" qualifier. Comment at: include/clang/Tooling/Core/Replacement.h:235 @@ -229,1 +234,3 @@ +/// related to the same file entry are put into the same vector. +FileToReplacementsMap groupReplacementsByFile(const Replacements &Replaces); djasper wrote: > I also wonder whether this should really return a map. I find such maps in > interfaces sometimes a bit difficult as they have some cost and the > subsequent analyses might actually prefer a different container. How about > instead just returning a vector? I mean the Replacements > themselves already have the filename stored in them so the key in the map is > redundant anyway. > > Manuel, any thoughts? But I think the tradeoff of using `vector` is the insertion time since we'd need to index Replcements with the same filename for each insertion. Or maybe we can have a map from filename to vector index as a local variable and return a vector? http://reviews.llvm.org/D17852 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D17852: Added formatAndApplyAllReplacements that works on multiple files in libTooling.
djasper added inline comments. Comment at: include/clang/Tooling/Core/Replacement.h:230 @@ +229,3 @@ + +typedef std::map +FileToReplacementsMap; ioeric wrote: > djasper wrote: > > I think the key type in a map is always const, so no need for "const". > I think "const" is needed since the `Entry` passed to map's `[]` operator is > of type `const FileEntry *` in `FileToReplaces[Entry].push_back(Replace)`. > The code didn't compile without the "const" qualifier. Well, now it's a string and the strings are copied anyway. I am pretty sure it will compile after removing "const". Comment at: include/clang/Tooling/Core/Replacement.h:235 @@ -229,1 +234,3 @@ +/// related to the same file entry are put into the same vector. +FileToReplacementsMap groupReplacementsByFile(const Replacements &Replaces); ioeric wrote: > djasper wrote: > > I also wonder whether this should really return a map. I find such maps in > > interfaces sometimes a bit difficult as they have some cost and the > > subsequent analyses might actually prefer a different container. How about > > instead just returning a vector? I mean the Replacements > > themselves already have the filename stored in them so the key in the map > > is redundant anyway. > > > > Manuel, any thoughts? > But I think the tradeoff of using `vector` is the insertion > time since we'd need to index Replcements with the same filename for each > insertion. Or maybe we can have a map from filename to vector index as a > local variable and return a vector? Yes, that is what I would probably do, have a local map and return a vector to keep the interface cleaner. But lets see what Manuel thinks. http://reviews.llvm.org/D17852 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D17852: Added formatAndApplyAllReplacements that works on multiple files in libTooling.
ioeric added inline comments. Comment at: include/clang/Tooling/Core/Replacement.h:230 @@ +229,3 @@ + +typedef std::map +FileToReplacementsMap; djasper wrote: > ioeric wrote: > > djasper wrote: > > > I think the key type in a map is always const, so no need for "const". > > I think "const" is needed since the `Entry` passed to map's `[]` operator > > is of type `const FileEntry *` in > > `FileToReplaces[Entry].push_back(Replace)`. The code didn't compile without > > the "const" qualifier. > Well, now it's a string and the strings are copied anyway. I am pretty sure > it will compile after removing "const". Ooops! I was on another git branch! Yes, it definitely compiles for `string`. Sorry about that. http://reviews.llvm.org/D17852 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D16044: getVariableName() for MemRegion
dcoughlin added a comment.
Hi Alexander,
Some comments in line. Also, I don't see any tests. Is this code tested by your
MPI patch?
Comment at: include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h:160
@@ -153,1 +159,3 @@
+ /// \returns variable name for memory region
+ std::string getVariableName() const;
};
I'm not sure that 'getVariableName()' conveys what this function does. The
returned name is not always the name of a variable. How do you intend to use
this method? How is it different than than printPretty()? Is it for debugging
purposes? If so, then perhaps 'getDebugDescription()'? Is it for presentation
to the user? Then perhaps 'getDescriptiveName()'?
Comment at: lib/StaticAnalyzer/Core/MemRegion.cpp:635
@@ -634,1 +634,3 @@
+std::string MemRegion::getVariableName() const {
+ std::string VariableName;
It seems like this could potentially be simplified by adding a recursive helper
that threads the output stream and appends to it after the base case has been
hit. You could also modify prettyPrint() to take a flag indicating whether it
should be quoted or not (and defaulting to true). What do you think?
http://reviews.llvm.org/D16044
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15643: [clang-format] Don't allow newline after uppercase Obj-C block return types
ksuther added a comment. Thank you! I don't have commit access, so could this be committed by someone who does? http://reviews.llvm.org/D15643 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D17700: [clang-format] Proposal for changes to Objective-C block formatting
ksuther updated this revision to Diff 49928.
ksuther added a comment.
Thanks for the comments. I've made some changes that eliminates reverting
r236598 and instead makes the behavior part of `IndentNestedBlocks`. That
allows the Google Obj-C code style
(https://google.github.io/styleguide/objcguide.xml#Blocks) to still work by
default. The issue with a parameter between block parameters has also been
fixed (as part of `AllowNewlineBeforeBlockParameter`).
Apologies if I'm missing something obvious, but I don't see how
`AllowNewlineBeforeBlockParameter` belongs in `BraceWrapping`. Blocks aren't
the same as braces, in the original example, this option would be controlling
the newline insertion for `completionBlock:^(SessionWindow* window) {` and not
just the opening brace.
http://reviews.llvm.org/D17700
Files:
include/clang/Format/Format.h
lib/Format/ContinuationIndenter.cpp
lib/Format/Format.cpp
unittests/Format/FormatTest.cpp
Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -7136,6 +7136,22 @@
" outRange8:(NSRange)out_range8\n"
" outRange9:(NSRange)out_range9;");
+ FormatStyle NoIndentStyle = getLLVMStyle();
+ NoIndentStyle.IndentNestedBlocks = false;
+ verifyFormat("- (NSUInteger)indexOfObject:(id)anObject\n"
+ "inRange:(NSRange)range\n"
+ " outRange:(NSRange)out_range\n"
+ " outRange1:(NSRange)out_range1\n"
+ " outRange2:(NSRange)out_range2\n"
+ " outRange3:(NSRange)out_range3\n"
+ " outRange4:(NSRange)out_range4\n"
+ " outRange5:(NSRange)out_range5\n"
+ " outRange6:(NSRange)out_range6\n"
+ " outRange7:(NSRange)out_range7\n"
+ " outRange8:(NSRange)out_range8\n"
+ " outRange9:(NSRange)out_range9;",
+ NoIndentStyle);
+
// When the function name has to be wrapped.
FormatStyle Style = getLLVMStyle();
Style.IndentWrappedFunctionNames = false;
@@ -10849,6 +10865,20 @@
"[self onOperationDone];\n"
"}];",
FourIndent);
+
+ FormatStyle NoNestedBlocks = getLLVMStyle();
+ NoNestedBlocks.IndentNestedBlocks = false;
+ verifyFormat("[self block:^(void) {\n"
+ " doStuff();\n"
+ "} completionHandler:^(void) {\n"
+ " doStuff();\n"
+ " [self block:^(void) {\n"
+ "doStuff();\n"
+ " } completionHandler:^(void) {\n"
+ "doStuff();\n"
+ " }];\n"
+ "}];",
+ NoNestedBlocks);
}
TEST_F(FormatTest, FormatsBlocksWithZeroColumnWidth) {
@@ -10916,6 +10946,24 @@
" int i;\n"
"};",
format("void (^largeBlock)(void) = ^{ int i; };", ZeroColumn));
+
+ FormatStyle DisallowNewline = getLLVMStyle();
+ DisallowNewline.AllowNewlineBeforeBlockParameter = false;
+ DisallowNewline.ColumnLimit = 0;
+ verifyFormat("[[SessionService sharedService] loadWindowWithCompletionBlock:^(SessionWindow *window) {\n"
+ " if (window) {\n"
+ "[self windowDidLoad:window];\n"
+ " } else {\n"
+ "[self errorLoadingWindow];\n"
+ " }\n"
+ "}];",
+ DisallowNewline);
+ verifyFormat("[controller test:^{\n"
+ " doStuff();\n"
+ "} withTimeout:5 completionHandler:^{\n"
+ " doStuff();\n"
+ "}];",
+ DisallowNewline);
}
TEST_F(FormatTest, SupportsCRLF) {
Index: lib/Format/Format.cpp
===
--- lib/Format/Format.cpp
+++ lib/Format/Format.cpp
@@ -304,6 +304,10 @@
IO.mapOptional("IndentWidth", Style.IndentWidth);
IO.mapOptional("IndentWrappedFunctionNames",
Style.IndentWrappedFunctionNames);
+IO.mapOptional("IndentNestedBlocks",
+ Style.IndentNestedBlocks);
+IO.mapOptional("AllowNewlineBeforeBlockParameter",
+ Style.AllowNewlineBeforeBlockParameter);
IO.mapOptional("KeepEmptyLinesAtTheStartOfBlocks",
Style.KeepEmptyLinesAtTheStartOfBlocks);
IO.mapOptional("MacroBlockBegin", Style.MacroBlockBegin);
@@ -519,6 +523,8 @@
{".*", 1}};
LLVMStyle.IndentCaseLabels = false;
LLVMStyle.IndentWrappedFunctionNames = false;
+ LLVMStyle.IndentNestedBlocks = true;
+ LLVMStyle.AllowNewlineBeforeBlockParameter = true;
LLVMStyle.IndentWidth = 2;
LLVMStyle.TabWidth = 8;
LL
[PATCH] D17922: [clang-format] Don't add a space before Obj-C selector methods that are also clang-format keywords
ksuther created this revision.
ksuther added a reviewer: djasper.
ksuther added a subscriber: cfe-commits.
Herald added a subscriber: klimek.
The following Obj-C methods will get formatted with an extra space between the
right paren and the name:
`- (void)delete:(id)sender`
`- (void)export:(id)sender`
So they'll incorrectly appear as:
`- (void) delete:(id)sender`
`- (void) export:(id)sender`
The fix is to check if the token is a TT_SelectorName instead of
tok::identifier. That way keywords recognized by clang-format still get treated
as an Obj-C method name (because they're both a TT_SelectorName and tok::delete
type).
http://reviews.llvm.org/D17922
Files:
lib/Format/TokenAnnotator.cpp
unittests/Format/FormatTest.cpp
Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -7433,6 +7433,7 @@
" y:(id)y\n"
"NS_DESIGNATED_INITIALIZER;",
getLLVMStyleWithColumns(60));
+ verifyFormat("- (void)delete:(id)sender\n");
// Continuation indent width should win over aligning colons if the function
// name is long.
Index: lib/Format/TokenAnnotator.cpp
===
--- lib/Format/TokenAnnotator.cpp
+++ lib/Format/TokenAnnotator.cpp
@@ -2077,7 +2077,7 @@
if (Line.Type == LT_ObjCMethodDecl) {
if (Left.is(TT_ObjCMethodSpecifier))
return true;
-if (Left.is(tok::r_paren) && Right.is(tok::identifier))
+if (Left.is(tok::r_paren) && Right.is(TT_SelectorName))
// Don't space between ')' and
return false;
}
Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -7433,6 +7433,7 @@
" y:(id)y\n"
"NS_DESIGNATED_INITIALIZER;",
getLLVMStyleWithColumns(60));
+ verifyFormat("- (void)delete:(id)sender\n");
// Continuation indent width should win over aligning colons if the function
// name is long.
Index: lib/Format/TokenAnnotator.cpp
===
--- lib/Format/TokenAnnotator.cpp
+++ lib/Format/TokenAnnotator.cpp
@@ -2077,7 +2077,7 @@
if (Line.Type == LT_ObjCMethodDecl) {
if (Left.is(TT_ObjCMethodSpecifier))
return true;
-if (Left.is(tok::r_paren) && Right.is(tok::identifier))
+if (Left.is(tok::r_paren) && Right.is(TT_SelectorName))
// Don't space between ')' and
return false;
}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
