mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-28 21:36:04 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/clang/unittests/Format/TokenAnnotatorTest.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

2078 lines
88 KiB
C++
Raw Normal View History

[clang-format] Fix misformatted macro definitions after D86959 After D86959 the code `#define lambda [](const decltype(x) &ptr) {}` was formatted as `#define lambda [](const decltype(x) & ptr) {}` due to now parsing the '&' token as a BinaryOperator. The problem was caused by the condition `Line.InPPDirective && (!Left->Previous || !Left->Previous->is(tok::identifier))) {` being matched and therefore not performing the checks for "previous token is one of decltype/_Atomic/etc.". This patch moves those checks after the existing if/else chain to ensure the left-parent token classification is always run after checking whether the contents of the parens is an expression or not. This change also introduces a new TokenAnnotatorTest that checks the token kind and Role of Tokens after analyzing them. This is used to check for TT_PointerOrReference, in addition to indirectly testing this based on the resulting formatting. Reviewed By: MyDeveloperDay Differential Revision: https://reviews.llvm.org/D88956
2020-10-27 10:05:55 +00:00
//===- unittest/Format/TokenAnnotatorTest.cpp - Formatting unit tests -----===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
#include "clang/Format/Format.h"
#include "FormatTestUtils.h"
#include "TestLexer.h"
#include "gtest/gtest.h"
namespace clang {
namespace format {
[clang-format] Improve require and concept handling - Added an option where to put the requires clauses. - Renamed IndentRequires to IndentRequiresClause. - Changed BreakBeforeConceptDeclaration from bool to an enum. Fixes https://llvm.org/PR32165, and https://llvm.org/PR52401. Differential Revision: https://reviews.llvm.org/D113319
2021-11-05 21:10:09 +01:00
// Not really the equality, but everything we need.
static bool operator==(const FormatToken &LHS,
const FormatToken &RHS) noexcept {
return LHS.Tok.getKind() == RHS.Tok.getKind() &&
LHS.getType() == RHS.getType();
}
[clang-format] Fix misformatted macro definitions after D86959 After D86959 the code `#define lambda [](const decltype(x) &ptr) {}` was formatted as `#define lambda [](const decltype(x) & ptr) {}` due to now parsing the '&' token as a BinaryOperator. The problem was caused by the condition `Line.InPPDirective && (!Left->Previous || !Left->Previous->is(tok::identifier))) {` being matched and therefore not performing the checks for "previous token is one of decltype/_Atomic/etc.". This patch moves those checks after the existing if/else chain to ensure the left-parent token classification is always run after checking whether the contents of the parens is an expression or not. This change also introduces a new TokenAnnotatorTest that checks the token kind and Role of Tokens after analyzing them. This is used to check for TT_PointerOrReference, in addition to indirectly testing this based on the resulting formatting. Reviewed By: MyDeveloperDay Differential Revision: https://reviews.llvm.org/D88956
2020-10-27 10:05:55 +00:00
namespace {
class TokenAnnotatorTest : public ::testing::Test {
protected:
TokenList annotate(llvm::StringRef Code,
const FormatStyle &Style = getLLVMStyle()) {
Fix use-after-scope introduced in 850325348ae82cd5e26ea9edfd04219d0fbe7828
2020-10-27 14:26:23 +00:00
return TestLexer(Allocator, Buffers, Style).annotate(Code);
[clang-format] Fix misformatted macro definitions after D86959 After D86959 the code `#define lambda [](const decltype(x) &ptr) {}` was formatted as `#define lambda [](const decltype(x) & ptr) {}` due to now parsing the '&' token as a BinaryOperator. The problem was caused by the condition `Line.InPPDirective && (!Left->Previous || !Left->Previous->is(tok::identifier))) {` being matched and therefore not performing the checks for "previous token is one of decltype/_Atomic/etc.". This patch moves those checks after the existing if/else chain to ensure the left-parent token classification is always run after checking whether the contents of the parens is an expression or not. This change also introduces a new TokenAnnotatorTest that checks the token kind and Role of Tokens after analyzing them. This is used to check for TT_PointerOrReference, in addition to indirectly testing this based on the resulting formatting. Reviewed By: MyDeveloperDay Differential Revision: https://reviews.llvm.org/D88956
2020-10-27 10:05:55 +00:00
}
Fix use-after-scope introduced in 850325348ae82cd5e26ea9edfd04219d0fbe7828
2020-10-27 14:26:23 +00:00
llvm::SpecificBumpPtrAllocator<FormatToken> Allocator;
std::vector<std::unique_ptr<llvm::MemoryBuffer>> Buffers;
[clang-format] Fix misformatted macro definitions after D86959 After D86959 the code `#define lambda [](const decltype(x) &ptr) {}` was formatted as `#define lambda [](const decltype(x) & ptr) {}` due to now parsing the '&' token as a BinaryOperator. The problem was caused by the condition `Line.InPPDirective && (!Left->Previous || !Left->Previous->is(tok::identifier))) {` being matched and therefore not performing the checks for "previous token is one of decltype/_Atomic/etc.". This patch moves those checks after the existing if/else chain to ensure the left-parent token classification is always run after checking whether the contents of the parens is an expression or not. This change also introduces a new TokenAnnotatorTest that checks the token kind and Role of Tokens after analyzing them. This is used to check for TT_PointerOrReference, in addition to indirectly testing this based on the resulting formatting. Reviewed By: MyDeveloperDay Differential Revision: https://reviews.llvm.org/D88956
2020-10-27 10:05:55 +00:00
};
#define EXPECT_TOKEN_KIND(FormatTok, Kind) \
EXPECT_EQ((FormatTok)->Tok.getKind(), Kind) << *(FormatTok)
#define EXPECT_TOKEN_TYPE(FormatTok, Type) \
EXPECT_EQ((FormatTok)->getType(), Type) << *(FormatTok)
[clang-format] Handle Verilog numbers and operators Reviewed By: HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D126845
2022-07-28 23:17:19 +00:00
#define EXPECT_TOKEN_PRECEDENCE(FormatTok, Prec) \
EXPECT_EQ((FormatTok)->getPrecedence(), Prec) << *(FormatTok)
[clang-format] Adjust braced list detection (reland 6dcde65) This is a retry of https://reviews.llvm.org/D114583, which was backed out for regressions. Clang Format is detecting a nested scope followed by another open brace as a braced initializer list due to incorrectly thinking it's matching a braced initializer at the end of a constructor initializer list which is followed by the body open brace. Unfortunately, UnwrappedLineParser isn't doing a very detailed parse, so it's not super straightforward to distinguish these cases given the current structure of calculateBraceTypes. My current hypothesis is that these can be disambiguated by looking at the token preceding the l_brace, as initializer list parameters will be preceded by an identifier, but a scope block generally will not (barring the MACRO wildcard). To this end, I am adding tracking of the previous token to the LBraceStack to help scope this particular case. TokenAnnotatorTests cherry picked from https://reviews.llvm.org/D150452. Fixes #33891. Fixes #52911. Differential Revision: https://reviews.llvm.org/D150403
2023-05-22 20:11:17 -07:00
#define EXPECT_BRACE_KIND(FormatTok, Kind) \
EXPECT_EQ(FormatTok->getBlockKind(), Kind) << *(FormatTok)
[clang-format] Fix misformatted macro definitions after D86959 After D86959 the code `#define lambda [](const decltype(x) &ptr) {}` was formatted as `#define lambda [](const decltype(x) & ptr) {}` due to now parsing the '&' token as a BinaryOperator. The problem was caused by the condition `Line.InPPDirective && (!Left->Previous || !Left->Previous->is(tok::identifier))) {` being matched and therefore not performing the checks for "previous token is one of decltype/_Atomic/etc.". This patch moves those checks after the existing if/else chain to ensure the left-parent token classification is always run after checking whether the contents of the parens is an expression or not. This change also introduces a new TokenAnnotatorTest that checks the token kind and Role of Tokens after analyzing them. This is used to check for TT_PointerOrReference, in addition to indirectly testing this based on the resulting formatting. Reviewed By: MyDeveloperDay Differential Revision: https://reviews.llvm.org/D88956
2020-10-27 10:05:55 +00:00
#define EXPECT_TOKEN(FormatTok, Kind, Type) \
do { \
EXPECT_TOKEN_KIND(FormatTok, Kind); \
EXPECT_TOKEN_TYPE(FormatTok, Type); \
[clang-format][NFC] Remove redundant semi All "calls" have a semi, as they should, remove the one from the macro. Differential Revision: https://reviews.llvm.org/D120359
2022-02-22 23:26:17 +01:00
} while (false)
[clang-format] Fix misformatted macro definitions after D86959 After D86959 the code `#define lambda [](const decltype(x) &ptr) {}` was formatted as `#define lambda [](const decltype(x) & ptr) {}` due to now parsing the '&' token as a BinaryOperator. The problem was caused by the condition `Line.InPPDirective && (!Left->Previous || !Left->Previous->is(tok::identifier))) {` being matched and therefore not performing the checks for "previous token is one of decltype/_Atomic/etc.". This patch moves those checks after the existing if/else chain to ensure the left-parent token classification is always run after checking whether the contents of the parens is an expression or not. This change also introduces a new TokenAnnotatorTest that checks the token kind and Role of Tokens after analyzing them. This is used to check for TT_PointerOrReference, in addition to indirectly testing this based on the resulting formatting. Reviewed By: MyDeveloperDay Differential Revision: https://reviews.llvm.org/D88956
2020-10-27 10:05:55 +00:00
[clang-format][NFC] Rename test and remove comments Why put "InMacros" in the name? We test other things to, and I will add more, withut macros. Also all our tests are regression tests. Differential Revision: https://reviews.llvm.org/D120401
2022-02-23 07:07:13 +01:00
TEST_F(TokenAnnotatorTest, UnderstandsUsesOfStarAndAmp) {
[clang-format] Fix misformatted macro definitions after D86959 After D86959 the code `#define lambda [](const decltype(x) &ptr) {}` was formatted as `#define lambda [](const decltype(x) & ptr) {}` due to now parsing the '&' token as a BinaryOperator. The problem was caused by the condition `Line.InPPDirective && (!Left->Previous || !Left->Previous->is(tok::identifier))) {` being matched and therefore not performing the checks for "previous token is one of decltype/_Atomic/etc.". This patch moves those checks after the existing if/else chain to ensure the left-parent token classification is always run after checking whether the contents of the parens is an expression or not. This change also introduces a new TokenAnnotatorTest that checks the token kind and Role of Tokens after analyzing them. This is used to check for TT_PointerOrReference, in addition to indirectly testing this based on the resulting formatting. Reviewed By: MyDeveloperDay Differential Revision: https://reviews.llvm.org/D88956
2020-10-27 10:05:55 +00:00
auto Tokens = annotate("auto x = [](const decltype(x) &ptr) {};");
EXPECT_EQ(Tokens.size(), 18u) << Tokens;
EXPECT_TOKEN(Tokens[7], tok::kw_decltype, TT_Unknown);
EXPECT_TOKEN(Tokens[8], tok::l_paren, TT_TypeDeclarationParen);
EXPECT_TOKEN(Tokens[9], tok::identifier, TT_Unknown);
EXPECT_TOKEN(Tokens[10], tok::r_paren, TT_TypeDeclarationParen);
EXPECT_TOKEN(Tokens[11], tok::amp, TT_PointerOrReference);
[clang-format][NFC] Rename test and remove comments Why put "InMacros" in the name? We test other things to, and I will add more, withut macros. Also all our tests are regression tests. Differential Revision: https://reviews.llvm.org/D120401
2022-02-23 07:07:13 +01:00
[clang-format] Fix misformatted macro definitions after D86959 After D86959 the code `#define lambda [](const decltype(x) &ptr) {}` was formatted as `#define lambda [](const decltype(x) & ptr) {}` due to now parsing the '&' token as a BinaryOperator. The problem was caused by the condition `Line.InPPDirective && (!Left->Previous || !Left->Previous->is(tok::identifier))) {` being matched and therefore not performing the checks for "previous token is one of decltype/_Atomic/etc.". This patch moves those checks after the existing if/else chain to ensure the left-parent token classification is always run after checking whether the contents of the parens is an expression or not. This change also introduces a new TokenAnnotatorTest that checks the token kind and Role of Tokens after analyzing them. This is used to check for TT_PointerOrReference, in addition to indirectly testing this based on the resulting formatting. Reviewed By: MyDeveloperDay Differential Revision: https://reviews.llvm.org/D88956
2020-10-27 10:05:55 +00:00
Tokens = annotate("auto x = [](const decltype(x) *ptr) {};");
EXPECT_EQ(Tokens.size(), 18u) << Tokens;
EXPECT_TOKEN(Tokens[10], tok::r_paren, TT_TypeDeclarationParen);
EXPECT_TOKEN(Tokens[11], tok::star, TT_PointerOrReference);
Tokens = annotate("#define lambda [](const decltype(x) &ptr) {}");
EXPECT_EQ(Tokens.size(), 17u) << Tokens;
EXPECT_TOKEN(Tokens[7], tok::kw_decltype, TT_Unknown);
EXPECT_TOKEN(Tokens[8], tok::l_paren, TT_TypeDeclarationParen);
EXPECT_TOKEN(Tokens[9], tok::identifier, TT_Unknown);
EXPECT_TOKEN(Tokens[10], tok::r_paren, TT_TypeDeclarationParen);
EXPECT_TOKEN(Tokens[11], tok::amp, TT_PointerOrReference);
[clang-format][NFC] Rename test and remove comments Why put "InMacros" in the name? We test other things to, and I will add more, withut macros. Also all our tests are regression tests. Differential Revision: https://reviews.llvm.org/D120401
2022-02-23 07:07:13 +01:00
[clang-format] Fix misformatted macro definitions after D86959 After D86959 the code `#define lambda [](const decltype(x) &ptr) {}` was formatted as `#define lambda [](const decltype(x) & ptr) {}` due to now parsing the '&' token as a BinaryOperator. The problem was caused by the condition `Line.InPPDirective && (!Left->Previous || !Left->Previous->is(tok::identifier))) {` being matched and therefore not performing the checks for "previous token is one of decltype/_Atomic/etc.". This patch moves those checks after the existing if/else chain to ensure the left-parent token classification is always run after checking whether the contents of the parens is an expression or not. This change also introduces a new TokenAnnotatorTest that checks the token kind and Role of Tokens after analyzing them. This is used to check for TT_PointerOrReference, in addition to indirectly testing this based on the resulting formatting. Reviewed By: MyDeveloperDay Differential Revision: https://reviews.llvm.org/D88956
2020-10-27 10:05:55 +00:00
Tokens = annotate("#define lambda [](const decltype(x) *ptr) {}");
EXPECT_EQ(Tokens.size(), 17u) << Tokens;
EXPECT_TOKEN(Tokens[10], tok::r_paren, TT_TypeDeclarationParen);
EXPECT_TOKEN(Tokens[11], tok::star, TT_PointerOrReference);
[clang-format] Allow to set token types final We have a little problem. TokenAnnotator::resetTokenMetadata() resets the type, except for a (growing) whitelist. This is because the TokenAnnotator visits some tokens multiple times. E.g. trying to identify if a < is an operator less or a template opener. And in some runs, which are bascially "reverted" the types are reset. On the other hand, if the parser does already know the type, it should be able to set it, without it being reset. So we introduce the ability to set a type and make that final. Differential Revision: https://reviews.llvm.org/D120511
2022-02-24 08:57:03 +01:00
Tokens = annotate("void f() {\n"
" while (p < a && *p == 'a')\n"
" p++;\n"
"}");
EXPECT_EQ(Tokens.size(), 21u) << Tokens;
EXPECT_TOKEN(Tokens[10], tok::ampamp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[11], tok::star, TT_UnaryOperator);
[clang-format] Refactor determineStarAmpUsage NFC There was some duplicate code in determineStarAmpUsage and determinePlusMinusCaretUsage Now a `-` or `+` following `;`, `sizeof`, `co_await`, or `delete` is regarded as a unary operator. Now a `*` or `&` following `case` is also a unary operator. Reviewed By: curdeius, MyDeveloperDay, HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D121754
2022-04-24 22:30:22 +00:00
Tokens = annotate("case *x:");
EXPECT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::star, TT_UnaryOperator);
Tokens = annotate("case &x:");
EXPECT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::amp, TT_UnaryOperator);
[clang-format] Fix misplacement of `*` in declaration of pointer to struct Fixes #55810 Differential Revision: https://reviews.llvm.org/D127873
2022-06-29 15:09:05 +08:00
[clang-format] Distinguish logical and after bracket from reference Fix commit `b646f0955574` and remove redundant code. Differential Revision: https://reviews.llvm.org/D131750
2022-08-13 11:12:10 +08:00
Tokens = annotate("bool b = 3 == int{3} && true;\n");
EXPECT_EQ(Tokens.size(), 13u) << Tokens;
EXPECT_TOKEN(Tokens[9], tok::ampamp, TT_BinaryOperator);
[clang-format] Fix misplacement of `*` in declaration of pointer to struct Fixes #55810 Differential Revision: https://reviews.llvm.org/D127873
2022-06-29 15:09:05 +08:00
Tokens = annotate("struct {\n"
"} *ptr;");
EXPECT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::star, TT_PointerOrReference);
Tokens = annotate("union {\n"
"} *ptr;");
EXPECT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::star, TT_PointerOrReference);
Tokens = annotate("class {\n"
"} *ptr;");
EXPECT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::star, TT_PointerOrReference);
Tokens = annotate("struct {\n"
"} &&ptr = {};");
EXPECT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::ampamp, TT_PointerOrReference);
Tokens = annotate("union {\n"
"} &&ptr = {};");
EXPECT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::ampamp, TT_PointerOrReference);
Tokens = annotate("class {\n"
"} &&ptr = {};");
EXPECT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::ampamp, TT_PointerOrReference);
[clang-format] distinguish multiplication after brace-init from pointer After https://github.com/llvm/llvm-project/commit/b646f0955574c6ad4c156c9db522e46f597cfda9, the added regression test started being formatted as-if the multiplication `*` was a pointer. This adapts the heuristic to distinguish between these two cases. Reviewed By: jackhong12, curdeius, HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D129771
2022-07-15 11:36:08 +02:00
Tokens = annotate("int i = int{42} * 2;");
EXPECT_EQ(Tokens.size(), 11u) << Tokens;
EXPECT_TOKEN(Tokens[7], tok::star, TT_BinaryOperator);
[clang-format] Fix annotating when deleting array of pointers Fixes https://github.com/llvm/llvm-project/issues/57418 The token `*` below should be annotated as `UnaryOperator`. ``` delete[] *ptr; ``` Reviewed By: owenpan, MyDeveloperDay Differential Revision: https://reviews.llvm.org/D132911
2022-08-30 13:56:45 +08:00
Tokens = annotate("delete[] *ptr;");
EXPECT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::star, TT_UnaryOperator);
Tokens = annotate("delete[] **ptr;");
EXPECT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::star, TT_UnaryOperator);
EXPECT_TOKEN(Tokens[4], tok::star, TT_UnaryOperator);
Tokens = annotate("delete[] *(ptr);");
EXPECT_EQ(Tokens.size(), 9u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::star, TT_UnaryOperator);
[clang-format] Correctly annotate star/amp in function pointer params Inside the arguments part of a function pointer declaration, `determineStarAmpUsage` results in a binary operator rather than pointers, because said parens are assumed to be an expression. This patch correctly marks the argument parens of a function pointer type as not an expression. Note that this fix already existed for Objective-C blocks as part of f1f267b447f60528440d2c066b29ab014ae7f90f. As Objective-C blocks and C/C++ function pointers share a lot of the same logic, that fix also makes sense here. Fixes https://github.com/llvm/llvm-project/issues/31659 Differential Revision: https://reviews.llvm.org/D135707
2022-10-11 22:16:48 +03:00
Tokens = annotate("void f() { void (*fnptr)(char* foo); }");
EXPECT_EQ(Tokens.size(), 18u) << Tokens;
EXPECT_TOKEN(Tokens[6], tok::l_paren, TT_FunctionTypeLParen);
// FIXME: The star of a function pointer probably makes more sense as
// TT_PointerOrReference.
EXPECT_TOKEN(Tokens[7], tok::star, TT_UnaryOperator);
EXPECT_TOKEN(Tokens[12], tok::star, TT_PointerOrReference);
Tokens = annotate("void f() { void (*fnptr)(t* foo); }");
EXPECT_EQ(Tokens.size(), 18u) << Tokens;
EXPECT_TOKEN(Tokens[6], tok::l_paren, TT_FunctionTypeLParen);
EXPECT_TOKEN(Tokens[7], tok::star, TT_UnaryOperator);
EXPECT_TOKEN(Tokens[12], tok::star, TT_PointerOrReference);
[clang-format] Handle object instansiation in if-statements Before this patch code like this: ``` if (Class* obj{getObject()}) { } ``` would be mis-formated since the * would be annotated as a binaryoperator. This patch changes the * to become a PointerOrReference instead and fixes the formatting issues. Reviewed By: HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D137327
2022-11-07 08:34:40 +01:00
[clang-format] Treats &/&& as reference when followed by ',' or ')' Ran into an issue where function declarations inside function scopes or uses of sizeof inside a function would treat the && in 'sizeof(Type &&)' as a binary operator. Attempt to fix this by assuming reference when followed by ',' or ')'. Also adds tests for these. Also hit an edge case in another test that treated "and" the same as "&&" since it parses as C++. Changed the "and" to "also" so it is no longer a keyword. Fixes #58923. Differential Revision: https://reviews.llvm.org/D137755
2022-11-12 00:51:35 -08:00
Tokens = annotate("int f3() { return sizeof(Foo&); }");
ASSERT_EQ(Tokens.size(), 14u) << Tokens;
EXPECT_TOKEN(Tokens[9], tok::amp, TT_PointerOrReference);
Tokens = annotate("int f4() { return sizeof(Foo&&); }");
ASSERT_EQ(Tokens.size(), 14u) << Tokens;
EXPECT_TOKEN(Tokens[9], tok::ampamp, TT_PointerOrReference);
Tokens = annotate("void f5() { int f6(Foo&, Bar&); }");
ASSERT_EQ(Tokens.size(), 17u) << Tokens;
EXPECT_TOKEN(Tokens[9], tok::amp, TT_PointerOrReference);
EXPECT_TOKEN(Tokens[12], tok::amp, TT_PointerOrReference);
Tokens = annotate("void f7() { int f8(Foo&&, Bar&&); }");
ASSERT_EQ(Tokens.size(), 17u) << Tokens;
EXPECT_TOKEN(Tokens[9], tok::ampamp, TT_PointerOrReference);
EXPECT_TOKEN(Tokens[12], tok::ampamp, TT_PointerOrReference);
[clang-format] Fix inconsistent annotation of operator& Token annotator incorrectly annotates operator& as a reference type in situations like Boost serialization archives: https://www.boost.org/doc/libs/1_81_0/libs/serialization/doc/tutorial.html Add annotation rules for standalone and chained operator& instances while preserving behavior for reference declarations at class scope. Add tests to validate annotation and formatting behavior. Differential Revision: https://reviews.llvm.org/D141959
2023-02-05 13:19:11 -08:00
Tokens = annotate("Type1 &val1 = val2;");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::amp, TT_PointerOrReference);
Tokens = annotate("Type1 *val1 = &val2;");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::star, TT_PointerOrReference);
EXPECT_TOKEN(Tokens[4], tok::amp, TT_UnaryOperator);
Tokens = annotate("val1 & val2;");
ASSERT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::amp, TT_BinaryOperator);
Tokens = annotate("val1 & val2.member;");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::amp, TT_BinaryOperator);
Tokens = annotate("val1 & val2.*member;");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::amp, TT_BinaryOperator);
Tokens = annotate("val1.*member & val2;");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::amp, TT_BinaryOperator);
Tokens = annotate("val1 & val2->*member;");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::amp, TT_BinaryOperator);
Tokens = annotate("val1->member & val2;");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::amp, TT_BinaryOperator);
Tokens = annotate("val1 & val2 & val3;");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::amp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[3], tok::amp, TT_BinaryOperator);
Tokens = annotate("val1 & val2 // comment\n"
" & val3;");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::amp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[4], tok::amp, TT_BinaryOperator);
Tokens =
annotate("val1 & val2.member & val3.member() & val4 & val5->member;");
ASSERT_EQ(Tokens.size(), 19u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::amp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[5], tok::amp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[11], tok::amp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[13], tok::amp, TT_BinaryOperator);
Tokens = annotate("class c {\n"
" void func(type &a) { a & member; }\n"
" anotherType &member;\n"
"}");
ASSERT_EQ(Tokens.size(), 22u) << Tokens;
EXPECT_TOKEN(Tokens[7], tok::amp, TT_PointerOrReference);
EXPECT_TOKEN(Tokens[12], tok::amp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[17], tok::amp, TT_PointerOrReference);
Tokens = annotate("struct S {\n"
" auto Mem = C & D;\n"
"}");
ASSERT_EQ(Tokens.size(), 12u) << Tokens;
EXPECT_TOKEN(Tokens[7], tok::amp, TT_BinaryOperator);
[clang-format] Annotate noexcept, explicit specifiers as containing expressions The noexcept specifier and explicit specifier can optionally include a boolean expression to make these specifiers apply conditionally, however, clang-format didn't set the context for the parenthesized content of these specifiers, meaning they inherited the parent context, which usually isn't an expressions, leading to misannotated binary operators. This patch applies expression context to the content of these specifiers, making them similar to the static_assert keyword. Fixes https://github.com/llvm/llvm-project/issues/44543 Reviewed By: owenpan, MyDeveloperDay Differential Revision: https://reviews.llvm.org/D146284
2023-03-22 20:26:38 +02:00
Tokens =
annotate("template <typename T> void swap() noexcept(Bar<T> && Foo<T>);");
ASSERT_EQ(Tokens.size(), 23u) << Tokens;
EXPECT_TOKEN(Tokens[15], tok::ampamp, TT_BinaryOperator);
Tokens = annotate("template <typename T> struct S {\n"
" explicit(Bar<T> && Foo<T>) S(const S &);\n"
"};");
ASSERT_EQ(Tokens.size(), 30u) << Tokens;
EXPECT_TOKEN(Tokens[14], tok::ampamp, TT_BinaryOperator);
[clang-format] Treat NTTP default values as expressions clang-format already has logic to threat the right-hand side of an equals sign. This patch applies that logic to template defaults, which are likely to be non-template type parameters in which case the default value should be annotated as an expression. This should mostly only ever apply to bool and &&. Fixes https://github.com/llvm/llvm-project/issues/61664 Reviewed By: MyDeveloperDay, owenpan Differential Revision: https://reviews.llvm.org/D146760
2023-03-26 04:39:03 +03:00
Tokens = annotate("template <bool B = C && D> struct S {};");
ASSERT_EQ(Tokens.size(), 15u) << Tokens;
EXPECT_TOKEN(Tokens[6], tok::ampamp, TT_BinaryOperator);
Tokens = annotate("template <typename T, bool B = C && D> struct S {};");
ASSERT_EQ(Tokens.size(), 18u) << Tokens;
EXPECT_TOKEN(Tokens[9], tok::ampamp, TT_BinaryOperator);
[clang-format] Don't format typename template parameters as expression bb4f6c4dca98a47054117708015bb2724256ee83 made it so that template parameter defaults are seen akin to assignments and formatted as expressions, however, the patch did this for all template parameters, even for `typename` template parameters. This patch formats `typename` and `class` template parameters as types. Fixes https://github.com/llvm/llvm-project/issues/61841 Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay Differential Revision: https://reviews.llvm.org/D147318
2023-04-01 16:51:10 +03:00
Tokens = annotate("template <typename T, typename U = T&&> struct S {};");
ASSERT_EQ(Tokens.size(), 17u) << Tokens;
EXPECT_TOKEN(Tokens[9], tok::ampamp, TT_PointerOrReference);
Tokens = annotate("template <typename T = int (*)(int)> struct S {};");
ASSERT_EQ(Tokens.size(), 19u) << Tokens;
EXPECT_TOKEN(Tokens[6], tok::l_paren, TT_FunctionTypeLParen);
EXPECT_TOKEN(Tokens[7], tok::star, TT_PointerOrReference);
[clang-format] Don't modify template arguments on the LHS of assignment After clang-format has determined that an equals sign starts an expression, it will also go backwards and modify any star/amp/ampamp binary operators on the left side of the assignment to be pointers/references instead. There already exists logic to skip over contents of parentheses and square brackets, but this patch also expands that logic to apply to angle brackets. This is so that binary operators inside of template arguments would not be touched, primary arguments to non-type template parameters. Fixes https://github.com/llvm/llvm-project/issues/62055 Reviewed By: owenpan, MyDeveloperDay, HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D148024
2023-04-12 00:33:12 +03:00
Tokens = annotate("Foo<A && B> a = {};");
ASSERT_EQ(Tokens.size(), 12u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::ampamp, TT_BinaryOperator);
Tokens = annotate("Foo<A &&> a = {};");
ASSERT_EQ(Tokens.size(), 11u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::ampamp, TT_PointerOrReference);
Tokens = annotate("template <enable_if_t<foo && !bar>* = nullptr> void f();");
ASSERT_EQ(Tokens.size(), 19u) << Tokens;
EXPECT_TOKEN(Tokens[5], tok::ampamp, TT_BinaryOperator);
[clang-format] Add TypeNames option to disambiguate types/objects If a non-keyword identifier is found in TypeNames, then a *, &, or && that follows it is annotated as TT_PointerOrReference. Differential Revision: https://reviews.llvm.org/D155273
2023-07-14 01:25:34 -07:00
[clang-format] Fix misannotation of && before noexcept (#65526) When we are in an expression, it has to be a binary operator and not pointer or reference.
2023-09-07 12:44:26 +02:00
Tokens =
annotate("auto foo() noexcept(noexcept(bar()) && "
"trait<std::decay_t<decltype(bar())>> && noexcept(baz())) {}");
EXPECT_EQ(Tokens.size(), 38u) << Tokens;
EXPECT_TOKEN(Tokens[12], tok::ampamp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[27], tok::ampamp, TT_BinaryOperator);
[clang-format] Fix a bug in annotating `&&` followed by `*` or `&` (#65933) Fixes #65877.
2023-09-13 23:57:34 -07:00
Tokens = annotate("foo = *i < *j && *j > *k;");
EXPECT_EQ(Tokens.size(), 15u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::less, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[7], tok::ampamp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[10], tok::greater, TT_BinaryOperator);
[clang-format] Add TypeNames option to disambiguate types/objects If a non-keyword identifier is found in TypeNames, then a *, &, or && that follows it is annotated as TT_PointerOrReference. Differential Revision: https://reviews.llvm.org/D155273
2023-07-14 01:25:34 -07:00
FormatStyle Style = getLLVMStyle();
Style.TypeNames.push_back("MYI");
Tokens = annotate("if (MYI *p{nullptr})", Style);
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::identifier, TT_TypeName);
EXPECT_TOKEN(Tokens[3], tok::star, TT_PointerOrReference);
Style.TypeNames.push_back("Class");
Tokens = annotate("if (Class *obj {getObj()})", Style);
ASSERT_EQ(Tokens.size(), 12u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::identifier, TT_TypeName);
EXPECT_TOKEN(Tokens[3], tok::star, TT_PointerOrReference);
[clang-format] Refactor determineStarAmpUsage NFC There was some duplicate code in determineStarAmpUsage and determinePlusMinusCaretUsage Now a `-` or `+` following `;`, `sizeof`, `co_await`, or `delete` is regarded as a unary operator. Now a `*` or `&` following `case` is also a unary operator. Reviewed By: curdeius, MyDeveloperDay, HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D121754
2022-04-24 22:30:22 +00:00
}
TEST_F(TokenAnnotatorTest, UnderstandsUsesOfPlusAndMinus) {
auto Tokens = annotate("x - 0");
ASSERT_EQ(Tokens.size(), 4u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::minus, TT_BinaryOperator);
Tokens = annotate("0 + 0");
ASSERT_EQ(Tokens.size(), 4u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::plus, TT_BinaryOperator);
Tokens = annotate("x + +0");
ASSERT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::plus, TT_UnaryOperator);
Tokens = annotate("x ? -0 : +0");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::minus, TT_UnaryOperator);
EXPECT_TOKEN(Tokens[5], tok::plus, TT_UnaryOperator);
Tokens = annotate("(-0)");
ASSERT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::minus, TT_UnaryOperator);
Tokens = annotate("0, -0");
ASSERT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::minus, TT_UnaryOperator);
Tokens = annotate("for (; -1;) {\n}");
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::minus, TT_UnaryOperator);
Tokens = annotate("x = -1;");
ASSERT_EQ(Tokens.size(), 6u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::minus, TT_UnaryOperator);
Tokens = annotate("x[-1]");
ASSERT_EQ(Tokens.size(), 6u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::minus, TT_UnaryOperator);
Tokens = annotate("x = {-1};");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::minus, TT_UnaryOperator);
Tokens = annotate("case -x:");
ASSERT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::minus, TT_UnaryOperator);
Tokens = annotate("co_await -x;");
ASSERT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::minus, TT_UnaryOperator);
Tokens = annotate("co_return -x;");
ASSERT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::minus, TT_UnaryOperator);
Tokens = annotate("co_yield -x;");
ASSERT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::minus, TT_UnaryOperator);
Tokens = annotate("delete -x;");
ASSERT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::minus, TT_UnaryOperator);
Tokens = annotate("return -x;");
ASSERT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::minus, TT_UnaryOperator);
Tokens = annotate("throw -x;");
ASSERT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::minus, TT_UnaryOperator);
Tokens = annotate("sizeof -x");
ASSERT_EQ(Tokens.size(), 4u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::minus, TT_UnaryOperator);
Tokens = annotate("co_await +x;");
ASSERT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::plus, TT_UnaryOperator);
Tokens = annotate("co_return +x;");
ASSERT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::plus, TT_UnaryOperator);
Tokens = annotate("co_yield +x;");
ASSERT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::plus, TT_UnaryOperator);
Tokens = annotate("delete +x;");
ASSERT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::plus, TT_UnaryOperator);
Tokens = annotate("return +x;");
ASSERT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::plus, TT_UnaryOperator);
Tokens = annotate("throw +x;");
ASSERT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::plus, TT_UnaryOperator);
Tokens = annotate("sizeof +x");
ASSERT_EQ(Tokens.size(), 4u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::plus, TT_UnaryOperator);
Tokens = annotate("(int)-x");
ASSERT_EQ(Tokens.size(), 6u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::minus, TT_UnaryOperator);
Tokens = annotate("(-x)");
ASSERT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::minus, TT_UnaryOperator);
Tokens = annotate("!+x");
ASSERT_EQ(Tokens.size(), 4u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::exclaim, TT_UnaryOperator);
EXPECT_TOKEN(Tokens[1], tok::plus, TT_UnaryOperator);
[clang-format] Fix misformatted macro definitions after D86959 After D86959 the code `#define lambda [](const decltype(x) &ptr) {}` was formatted as `#define lambda [](const decltype(x) & ptr) {}` due to now parsing the '&' token as a BinaryOperator. The problem was caused by the condition `Line.InPPDirective && (!Left->Previous || !Left->Previous->is(tok::identifier))) {` being matched and therefore not performing the checks for "previous token is one of decltype/_Atomic/etc.". This patch moves those checks after the existing if/else chain to ensure the left-parent token classification is always run after checking whether the contents of the parens is an expression or not. This change also introduces a new TokenAnnotatorTest that checks the token kind and Role of Tokens after analyzing them. This is used to check for TT_PointerOrReference, in addition to indirectly testing this based on the resulting formatting. Reviewed By: MyDeveloperDay Differential Revision: https://reviews.llvm.org/D88956
2020-10-27 10:05:55 +00:00
}
[clang-format] Fix AllowShortFunctionsOnASingleLine: InlineOnly with wrapping after record. Fixes https://github.com/llvm/llvm-project/issues/53430. Initially, I had a quick and dirty approach, but it led to a myriad of special cases handling comments (that may add unwrapped lines). So I added TT_RecordLBrace type annotations and it seems like a much nicer solution. I think that in the future it will allow us to clean up some convoluted code that detects records. Reviewed By: MyDeveloperDay, HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D118337
2022-01-27 17:54:58 +01:00
TEST_F(TokenAnnotatorTest, UnderstandsClasses) {
auto Tokens = annotate("class C {};");
EXPECT_EQ(Tokens.size(), 6u) << Tokens;
[clang-format] Fix formatting of struct-like records followed by variable declaration. Fixes https://github.com/llvm/llvm-project/issues/24781. Fixes https://github.com/llvm/llvm-project/issues/38160. This patch splits `TT_RecordLBrace` for classes/enums/structs/unions (and other records, e.g. interfaces) and uses the brace type to avoid the error-prone scanning for record token. The mentioned bugs were provoked by the scanning being too limited (and so not considering `const` or `constexpr`, or other qualifiers, on an anonymous struct variable declaration). Moreover, the proposed solution is more efficient as we parse tokens once only (scanning being parsing too). Reviewed By: MyDeveloperDay, HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D119785
2022-02-14 22:25:36 +01:00
EXPECT_TOKEN(Tokens[2], tok::l_brace, TT_ClassLBrace);
Tokens = annotate("const class C {} c;");
EXPECT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::l_brace, TT_ClassLBrace);
Tokens = annotate("const class {} c;");
EXPECT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::l_brace, TT_ClassLBrace);
[clang-format] Don't annotate left brace of class as FunctionLBrace The l_brace of class/struct/union was incorrectly annotated as TT_FunctionLBrace in the presence of attributes. This in turn would cause the RemoveSemicolon option to remove the semicolon at the end of the declaration, resulting in invalid code being generated. Fixes #61188. Differential Revision: https://reviews.llvm.org/D145344
2023-03-05 17:52:42 -08:00
Tokens = annotate("class [[deprecated(\"\")]] C { int i; };");
EXPECT_EQ(Tokens.size(), 17u) << Tokens;
EXPECT_TOKEN(Tokens[10], tok::l_brace, TT_ClassLBrace);
[clang-format] Fix AllowShortFunctionsOnASingleLine: InlineOnly with wrapping after record. Fixes https://github.com/llvm/llvm-project/issues/53430. Initially, I had a quick and dirty approach, but it led to a myriad of special cases handling comments (that may add unwrapped lines). So I added TT_RecordLBrace type annotations and it seems like a much nicer solution. I think that in the future it will allow us to clean up some convoluted code that detects records. Reviewed By: MyDeveloperDay, HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D118337
2022-01-27 17:54:58 +01:00
}
TEST_F(TokenAnnotatorTest, UnderstandsStructs) {
auto Tokens = annotate("struct S {};");
EXPECT_EQ(Tokens.size(), 6u) << Tokens;
[clang-format] Fix formatting of struct-like records followed by variable declaration. Fixes https://github.com/llvm/llvm-project/issues/24781. Fixes https://github.com/llvm/llvm-project/issues/38160. This patch splits `TT_RecordLBrace` for classes/enums/structs/unions (and other records, e.g. interfaces) and uses the brace type to avoid the error-prone scanning for record token. The mentioned bugs were provoked by the scanning being too limited (and so not considering `const` or `constexpr`, or other qualifiers, on an anonymous struct variable declaration). Moreover, the proposed solution is more efficient as we parse tokens once only (scanning being parsing too). Reviewed By: MyDeveloperDay, HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D119785
2022-02-14 22:25:36 +01:00
EXPECT_TOKEN(Tokens[2], tok::l_brace, TT_StructLBrace);
[clang-format] Don't annotate left brace of struct as FunctionLBrace Related to a02c3af9f19d. Fixes #61700. Differential Revision: https://reviews.llvm.org/D146895
2023-03-25 19:31:57 -07:00
Tokens = annotate("struct EXPORT_MACRO [[nodiscard]] C { int i; };");
EXPECT_EQ(Tokens.size(), 15u) << Tokens;
EXPECT_TOKEN(Tokens[8], tok::l_brace, TT_StructLBrace);
Tokens = annotate("struct [[deprecated]] [[nodiscard]] C { int i; };");
EXPECT_EQ(Tokens.size(), 19u) << Tokens;
EXPECT_TOKEN(Tokens[12], tok::l_brace, TT_StructLBrace);
[clang-format] Don't misannotate left squares as lambda introducers A left square can start a lambda only if it's not preceded by an identifier other than return and co-wait/co-yield/co-return. Fixes #54245. Fixes #61786. Differential Revision: https://reviews.llvm.org/D147295
2023-03-30 20:16:52 -07:00
Tokens = annotate("template <typename T> struct S<const T[N]> {};");
EXPECT_EQ(Tokens.size(), 18u) << Tokens;
EXPECT_TOKEN(Tokens[7], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[10], tok::l_square, TT_ArraySubscriptLSquare);
EXPECT_TOKEN(Tokens[13], tok::greater, TT_TemplateCloser);
EXPECT_TOKEN(Tokens[14], tok::l_brace, TT_StructLBrace);
Tokens = annotate("template <typename T> struct S<T const[N]> {};");
EXPECT_EQ(Tokens.size(), 18u) << Tokens;
EXPECT_TOKEN(Tokens[7], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[10], tok::l_square, TT_ArraySubscriptLSquare);
EXPECT_TOKEN(Tokens[13], tok::greater, TT_TemplateCloser);
EXPECT_TOKEN(Tokens[14], tok::l_brace, TT_StructLBrace);
Tokens = annotate("template <typename T, unsigned n> struct S<T const[n]> {\n"
" void f(T const (&a)[n]);\n"
"};");
EXPECT_EQ(Tokens.size(), 35u) << Tokens;
EXPECT_TOKEN(Tokens[10], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[13], tok::l_square, TT_ArraySubscriptLSquare);
EXPECT_TOKEN(Tokens[16], tok::greater, TT_TemplateCloser);
EXPECT_TOKEN(Tokens[17], tok::l_brace, TT_StructLBrace);
EXPECT_TOKEN(Tokens[23], tok::l_paren, TT_FunctionTypeLParen);
EXPECT_TOKEN(Tokens[24], tok::amp, TT_UnaryOperator);
EXPECT_TOKEN(Tokens[27], tok::l_square, TT_ArraySubscriptLSquare);
[clang-format] Fix AllowShortFunctionsOnASingleLine: InlineOnly with wrapping after record. Fixes https://github.com/llvm/llvm-project/issues/53430. Initially, I had a quick and dirty approach, but it led to a myriad of special cases handling comments (that may add unwrapped lines). So I added TT_RecordLBrace type annotations and it seems like a much nicer solution. I think that in the future it will allow us to clean up some convoluted code that detects records. Reviewed By: MyDeveloperDay, HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D118337
2022-01-27 17:54:58 +01:00
}
TEST_F(TokenAnnotatorTest, UnderstandsUnions) {
auto Tokens = annotate("union U {};");
EXPECT_EQ(Tokens.size(), 6u) << Tokens;
[clang-format] Fix formatting of struct-like records followed by variable declaration. Fixes https://github.com/llvm/llvm-project/issues/24781. Fixes https://github.com/llvm/llvm-project/issues/38160. This patch splits `TT_RecordLBrace` for classes/enums/structs/unions (and other records, e.g. interfaces) and uses the brace type to avoid the error-prone scanning for record token. The mentioned bugs were provoked by the scanning being too limited (and so not considering `const` or `constexpr`, or other qualifiers, on an anonymous struct variable declaration). Moreover, the proposed solution is more efficient as we parse tokens once only (scanning being parsing too). Reviewed By: MyDeveloperDay, HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D119785
2022-02-14 22:25:36 +01:00
EXPECT_TOKEN(Tokens[2], tok::l_brace, TT_UnionLBrace);
Tokens = annotate("union U { void f() { return; } };");
EXPECT_EQ(Tokens.size(), 14u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::l_brace, TT_UnionLBrace);
EXPECT_TOKEN(Tokens[7], tok::l_brace, TT_FunctionLBrace);
[clang-format] Fix AllowShortFunctionsOnASingleLine: InlineOnly with wrapping after record. Fixes https://github.com/llvm/llvm-project/issues/53430. Initially, I had a quick and dirty approach, but it led to a myriad of special cases handling comments (that may add unwrapped lines). So I added TT_RecordLBrace type annotations and it seems like a much nicer solution. I think that in the future it will allow us to clean up some convoluted code that detects records. Reviewed By: MyDeveloperDay, HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D118337
2022-01-27 17:54:58 +01:00
}
TEST_F(TokenAnnotatorTest, UnderstandsEnums) {
auto Tokens = annotate("enum E {};");
EXPECT_EQ(Tokens.size(), 6u) << Tokens;
[clang-format] Fix formatting of struct-like records followed by variable declaration. Fixes https://github.com/llvm/llvm-project/issues/24781. Fixes https://github.com/llvm/llvm-project/issues/38160. This patch splits `TT_RecordLBrace` for classes/enums/structs/unions (and other records, e.g. interfaces) and uses the brace type to avoid the error-prone scanning for record token. The mentioned bugs were provoked by the scanning being too limited (and so not considering `const` or `constexpr`, or other qualifiers, on an anonymous struct variable declaration). Moreover, the proposed solution is more efficient as we parse tokens once only (scanning being parsing too). Reviewed By: MyDeveloperDay, HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D119785
2022-02-14 22:25:36 +01:00
EXPECT_TOKEN(Tokens[2], tok::l_brace, TT_EnumLBrace);
[clang-format] Fix AllowShortFunctionsOnASingleLine: InlineOnly with wrapping after record. Fixes https://github.com/llvm/llvm-project/issues/53430. Initially, I had a quick and dirty approach, but it led to a myriad of special cases handling comments (that may add unwrapped lines). So I added TT_RecordLBrace type annotations and it seems like a much nicer solution. I think that in the future it will allow us to clean up some convoluted code that detects records. Reviewed By: MyDeveloperDay, HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D118337
2022-01-27 17:54:58 +01:00
}
[clang-format] Correctly format variable templates. Fixes https://github.com/llvm/llvm-project/issues/54257. Reviewed By: MyDeveloperDay, HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D121456
2022-03-15 13:16:08 +01:00
TEST_F(TokenAnnotatorTest, UnderstandsDefaultedAndDeletedFunctions) {
auto Tokens = annotate("auto operator<=>(const T &) const & = default;");
EXPECT_EQ(Tokens.size(), 14u) << Tokens;
EXPECT_TOKEN(Tokens[9], tok::amp, TT_PointerOrReference);
Tokens = annotate("template <typename T> void F(T) && = delete;");
EXPECT_EQ(Tokens.size(), 15u) << Tokens;
EXPECT_TOKEN(Tokens[10], tok::ampamp, TT_PointerOrReference);
}
TEST_F(TokenAnnotatorTest, UnderstandsVariables) {
auto Tokens =
annotate("inline bool var = is_integral_v<int> && is_signed_v<int>;");
EXPECT_EQ(Tokens.size(), 15u) << Tokens;
EXPECT_TOKEN(Tokens[8], tok::ampamp, TT_BinaryOperator);
}
TEST_F(TokenAnnotatorTest, UnderstandsVariableTemplates) {
auto Tokens =
annotate("template <typename T> "
"inline bool var = is_integral_v<int> && is_signed_v<int>;");
EXPECT_EQ(Tokens.size(), 20u) << Tokens;
EXPECT_TOKEN(Tokens[13], tok::ampamp, TT_BinaryOperator);
}
[clang-format] Fix template arguments in macros Fixes https://github.com/llvm/llvm-project/issues/57738 old ``` #define FOO(typeName, realClass) \ { \ #typeName, foo < FooType>(new foo <realClass>(#typeName)) \ } ``` new ``` #define FOO(typeName, realClass) \ { #typeName, foo<FooType>(new foo<realClass>(#typeName)) } ``` Previously, when an UnwrappedLine began with a hash in a macro definition, the program incorrectly assumed the line was a preprocessor directive. It should be stringification. The rule in spaceRequiredBefore was added in 8b5297117b. Its purpose is to add a space in an include directive. It also added a space to a template opener when the line began with a stringification hash. So we changed it. Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D133954
2022-09-16 13:18:21 +00:00
TEST_F(TokenAnnotatorTest, UnderstandsTemplatesInMacros) {
auto Tokens =
annotate("#define FOO(typeName) \\\n"
" { #typeName, foo<FooType>(new foo<realClass>(#typeName)) }");
ASSERT_EQ(Tokens.size(), 27u) << Tokens;
EXPECT_TOKEN(Tokens[11], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[13], tok::greater, TT_TemplateCloser);
EXPECT_TOKEN(Tokens[17], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[19], tok::greater, TT_TemplateCloser);
}
[clang-format] fix template closer followed by > fix https://github.com/llvm/llvm-project/issues/59785 Reviewed By: HazardyKnusperkeks, MyDeveloperDay, owenpan Differential Revision: https://reviews.llvm.org/D140843
2023-01-06 21:05:15 +08:00
TEST_F(TokenAnnotatorTest, UnderstandsGreaterAfterTemplateCloser) {
auto Tokens = annotate("if (std::tuple_size_v<T> > 0)");
ASSERT_EQ(Tokens.size(), 12u) << Tokens;
EXPECT_TOKEN(Tokens[5], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[7], tok::greater, TT_TemplateCloser);
EXPECT_TOKEN(Tokens[8], tok::greater, TT_BinaryOperator);
[clang-format] Don't allow template to be preceded by closing brace This check is similar to the right paren check right below it, but it doesn't need the overloaded operator check. This patch prevents brace-initialized objects that are being compared from being mis-annotated as template parameters. Fixes https://github.com/llvm/llvm-project/issues/57004 Reviewed By: owenpan, MyDeveloperDay Differential Revision: https://reviews.llvm.org/D150629
2023-05-17 01:35:22 +03:00
}
TEST_F(TokenAnnotatorTest, UnderstandsNonTemplateAngleBrackets) {
auto Tokens = annotate("return a < b && c > d;");
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::less, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[6], tok::greater, TT_BinaryOperator);
Tokens = annotate("a < 0 ? b : a > 0 ? c : d;");
ASSERT_EQ(Tokens.size(), 15u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::less, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[7], tok::greater, TT_BinaryOperator);
Tokens = annotate("ratio{-1, 2} < ratio{-1, 3} == -1 / 3 > -1 / 2;");
ASSERT_EQ(Tokens.size(), 27u) << Tokens;
EXPECT_TOKEN(Tokens[7], tok::less, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[20], tok::greater, TT_BinaryOperator);
[clang-format] fix template closer followed by > fix https://github.com/llvm/llvm-project/issues/59785 Reviewed By: HazardyKnusperkeks, MyDeveloperDay, owenpan Differential Revision: https://reviews.llvm.org/D140843
2023-01-06 21:05:15 +08:00
}
[clang-format] Fix regressions in WhitespaceSensitiveMacros Fixes #54522. Fixes #57158. Differential Revision: https://reviews.llvm.org/D132001
2022-08-16 16:30:40 -07:00
TEST_F(TokenAnnotatorTest, UnderstandsWhitespaceSensitiveMacros) {
FormatStyle Style = getLLVMStyle();
Style.WhitespaceSensitiveMacros.push_back("FOO");
auto Tokens = annotate("FOO(1+2 )\n", Style);
EXPECT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::identifier, TT_UntouchableMacroFunc);
Tokens = annotate("FOO(a:b:c)\n", Style);
EXPECT_EQ(Tokens.size(), 9u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::identifier, TT_UntouchableMacroFunc);
}
[clang-format] Fix formatting of the array form of delete. Fixes https://github.com/llvm/llvm-project/issues/53576. There was an inconsistency in formatting of delete expressions. Before: ``` delete (void*)a; delete[](void*) a; ``` After this patch: ``` delete (void*)a; delete[] (void*)a; ``` Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D119117
2022-02-09 22:16:16 +01:00
TEST_F(TokenAnnotatorTest, UnderstandsDelete) {
auto Tokens = annotate("delete (void *)p;");
EXPECT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::r_paren, TT_CastRParen);
Tokens = annotate("delete[] (void *)p;");
EXPECT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[6], tok::r_paren, TT_CastRParen);
Tokens = annotate("delete[] /*comment*/ (void *)p;");
EXPECT_EQ(Tokens.size(), 11u) << Tokens;
EXPECT_TOKEN(Tokens[7], tok::r_paren, TT_CastRParen);
Tokens = annotate("delete[/*comment*/] (void *)p;");
EXPECT_EQ(Tokens.size(), 11u) << Tokens;
EXPECT_TOKEN(Tokens[7], tok::r_paren, TT_CastRParen);
Tokens = annotate("delete/*comment*/[] (void *)p;");
EXPECT_EQ(Tokens.size(), 11u) << Tokens;
EXPECT_TOKEN(Tokens[7], tok::r_paren, TT_CastRParen);
}
[clang-format] Allow `throw` to be a keyword in front of casts This makes throw more similar to return. However, unlike return, it has to more strict as to not remove spaces after usages of throw as a (deprecated) exception specifier. Fixes https://github.com/llvm/llvm-project/issues/57391 Differential Revision: https://reviews.llvm.org/D132762
2022-09-05 12:32:40 +02:00
TEST_F(TokenAnnotatorTest, UnderstandsCasts) {
auto Tokens = annotate("(void)p;");
EXPECT_EQ(Tokens.size(), 6u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::r_paren, TT_CastRParen);
Tokens = annotate("auto x = (Foo)p;");
EXPECT_EQ(Tokens.size(), 9u) << Tokens;
EXPECT_TOKEN(Tokens[5], tok::r_paren, TT_CastRParen);
Tokens = annotate("(std::vector<int>)p;");
EXPECT_EQ(Tokens.size(), 11u) << Tokens;
EXPECT_TOKEN(Tokens[7], tok::r_paren, TT_CastRParen);
Tokens = annotate("return (Foo)p;");
EXPECT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::r_paren, TT_CastRParen);
Tokens = annotate("throw (Foo)p;");
EXPECT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::r_paren, TT_CastRParen);
[clang-format] Fix bugs in annotating r_paren as C-style cast Don't annotate r_paren as TT_CastRParen if it's followed by an amp/star and either the line is in a macro definition or a numeric_constant follows the amp/star. Fixes #59634. Differential Revision: https://reviews.llvm.org/D153745
2023-06-25 22:18:12 -07:00
Tokens = annotate("#define FOO(x) (((uint64_t)(x) * BAR) / 100)");
EXPECT_EQ(Tokens.size(), 21u) << Tokens;
EXPECT_TOKEN(Tokens[10], tok::r_paren, TT_CastRParen);
EXPECT_TOKEN(Tokens[13], tok::r_paren, TT_Unknown);
EXPECT_TOKEN(Tokens[14], tok::star, TT_BinaryOperator);
Tokens = annotate("return (Foo) & 10;");
EXPECT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::r_paren, TT_Unknown);
EXPECT_TOKEN(Tokens[4], tok::amp, TT_BinaryOperator);
[clang-format] Allow `throw` to be a keyword in front of casts This makes throw more similar to return. However, unlike return, it has to more strict as to not remove spaces after usages of throw as a (deprecated) exception specifier. Fixes https://github.com/llvm/llvm-project/issues/57391 Differential Revision: https://reviews.llvm.org/D132762
2022-09-05 12:32:40 +02:00
}
TEST_F(TokenAnnotatorTest, UnderstandsDynamicExceptionSpecifier) {
auto Tokens = annotate("void f() throw(int);");
EXPECT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::kw_throw, TT_Unknown);
}
[clang-format] Add regression tests for function ref qualifiers on operator definition. NFC. Fixes https://github.com/llvm/llvm-project/issues/54374.
2022-03-15 12:00:37 +01:00
TEST_F(TokenAnnotatorTest, UnderstandsFunctionRefQualifiers) {
auto Tokens = annotate("void f() &;");
EXPECT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::amp, TT_PointerOrReference);
[clang-format] Correctly format variable templates. Fixes https://github.com/llvm/llvm-project/issues/54257. Reviewed By: MyDeveloperDay, HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D121456
2022-03-15 13:16:08 +01:00
Tokens = annotate("void operator=(T) &&;");
EXPECT_EQ(Tokens.size(), 9u) << Tokens;
EXPECT_TOKEN(Tokens[6], tok::ampamp, TT_PointerOrReference);
[clang-format] Add regression tests for function ref qualifiers on operator definition. NFC. Fixes https://github.com/llvm/llvm-project/issues/54374.
2022-03-15 12:00:37 +01:00
Tokens = annotate("template <typename T> void f() &;");
EXPECT_EQ(Tokens.size(), 12u) << Tokens;
EXPECT_TOKEN(Tokens[9], tok::amp, TT_PointerOrReference);
[clang-format] Correctly format variable templates. Fixes https://github.com/llvm/llvm-project/issues/54257. Reviewed By: MyDeveloperDay, HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D121456
2022-03-15 13:16:08 +01:00
Tokens = annotate("template <typename T> void operator=(T) &;");
EXPECT_EQ(Tokens.size(), 14u) << Tokens;
EXPECT_TOKEN(Tokens[11], tok::amp, TT_PointerOrReference);
[clang-format] Add regression tests for function ref qualifiers on operator definition. NFC. Fixes https://github.com/llvm/llvm-project/issues/54374.
2022-03-15 12:00:37 +01:00
}
[clang-format] Correctly annotate UDLs as OverloadedOperator While the opening parenthesis of an user-defined literal operator was correctly annotated as OverloadedOperatorLParen, the "" and its suffix wasn't annotated as OverloadedOperator. Fixes https://github.com/llvm/llvm-project/issues/58035 Differential Revision: https://reviews.llvm.org/D134853
2022-09-29 10:10:47 +03:00
TEST_F(TokenAnnotatorTest, UnderstandsOverloadedOperators) {
auto Tokens = annotate("x.operator+()");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
[clang-format] Correctly annotate */&/&& in operator function calls Reverts 4986f3f2f220 (but keeps its unit tests) and fixes #49973 differently. Also fixes bugs that incorrectly annotate the operator keyword as TT_FunctionDeclarationName in function calls and as TT_Unknown in function declarations and definitions. Differential Revision: https://reviews.llvm.org/D154184
2023-06-29 18:14:18 -07:00
EXPECT_TOKEN(Tokens[2], tok::kw_operator, TT_Unknown);
[clang-format] Correctly annotate UDLs as OverloadedOperator While the opening parenthesis of an user-defined literal operator was correctly annotated as OverloadedOperatorLParen, the "" and its suffix wasn't annotated as OverloadedOperator. Fixes https://github.com/llvm/llvm-project/issues/58035 Differential Revision: https://reviews.llvm.org/D134853
2022-09-29 10:10:47 +03:00
EXPECT_TOKEN(Tokens[3], tok::plus, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[4], tok::l_paren, TT_OverloadedOperatorLParen);
Tokens = annotate("x.operator=()");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
[clang-format] Correctly annotate */&/&& in operator function calls Reverts 4986f3f2f220 (but keeps its unit tests) and fixes #49973 differently. Also fixes bugs that incorrectly annotate the operator keyword as TT_FunctionDeclarationName in function calls and as TT_Unknown in function declarations and definitions. Differential Revision: https://reviews.llvm.org/D154184
2023-06-29 18:14:18 -07:00
EXPECT_TOKEN(Tokens[2], tok::kw_operator, TT_Unknown);
[clang-format] Correctly annotate UDLs as OverloadedOperator While the opening parenthesis of an user-defined literal operator was correctly annotated as OverloadedOperatorLParen, the "" and its suffix wasn't annotated as OverloadedOperator. Fixes https://github.com/llvm/llvm-project/issues/58035 Differential Revision: https://reviews.llvm.org/D134853
2022-09-29 10:10:47 +03:00
EXPECT_TOKEN(Tokens[3], tok::equal, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[4], tok::l_paren, TT_OverloadedOperatorLParen);
Tokens = annotate("x.operator+=()");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
[clang-format] Correctly annotate */&/&& in operator function calls Reverts 4986f3f2f220 (but keeps its unit tests) and fixes #49973 differently. Also fixes bugs that incorrectly annotate the operator keyword as TT_FunctionDeclarationName in function calls and as TT_Unknown in function declarations and definitions. Differential Revision: https://reviews.llvm.org/D154184
2023-06-29 18:14:18 -07:00
EXPECT_TOKEN(Tokens[2], tok::kw_operator, TT_Unknown);
[clang-format] Correctly annotate UDLs as OverloadedOperator While the opening parenthesis of an user-defined literal operator was correctly annotated as OverloadedOperatorLParen, the "" and its suffix wasn't annotated as OverloadedOperator. Fixes https://github.com/llvm/llvm-project/issues/58035 Differential Revision: https://reviews.llvm.org/D134853
2022-09-29 10:10:47 +03:00
EXPECT_TOKEN(Tokens[3], tok::plusequal, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[4], tok::l_paren, TT_OverloadedOperatorLParen);
Tokens = annotate("x.operator,()");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
[clang-format] Correctly annotate */&/&& in operator function calls Reverts 4986f3f2f220 (but keeps its unit tests) and fixes #49973 differently. Also fixes bugs that incorrectly annotate the operator keyword as TT_FunctionDeclarationName in function calls and as TT_Unknown in function declarations and definitions. Differential Revision: https://reviews.llvm.org/D154184
2023-06-29 18:14:18 -07:00
EXPECT_TOKEN(Tokens[2], tok::kw_operator, TT_Unknown);
[clang-format] Correctly annotate UDLs as OverloadedOperator While the opening parenthesis of an user-defined literal operator was correctly annotated as OverloadedOperatorLParen, the "" and its suffix wasn't annotated as OverloadedOperator. Fixes https://github.com/llvm/llvm-project/issues/58035 Differential Revision: https://reviews.llvm.org/D134853
2022-09-29 10:10:47 +03:00
EXPECT_TOKEN(Tokens[3], tok::comma, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[4], tok::l_paren, TT_OverloadedOperatorLParen);
Tokens = annotate("x.operator()()");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
[clang-format] Correctly annotate */&/&& in operator function calls Reverts 4986f3f2f220 (but keeps its unit tests) and fixes #49973 differently. Also fixes bugs that incorrectly annotate the operator keyword as TT_FunctionDeclarationName in function calls and as TT_Unknown in function declarations and definitions. Differential Revision: https://reviews.llvm.org/D154184
2023-06-29 18:14:18 -07:00
EXPECT_TOKEN(Tokens[2], tok::kw_operator, TT_Unknown);
[clang-format] Correctly annotate UDLs as OverloadedOperator While the opening parenthesis of an user-defined literal operator was correctly annotated as OverloadedOperatorLParen, the "" and its suffix wasn't annotated as OverloadedOperator. Fixes https://github.com/llvm/llvm-project/issues/58035 Differential Revision: https://reviews.llvm.org/D134853
2022-09-29 10:10:47 +03:00
EXPECT_TOKEN(Tokens[3], tok::l_paren, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[4], tok::r_paren, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[5], tok::l_paren, TT_OverloadedOperatorLParen);
Tokens = annotate("x.operator[]()");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
[clang-format] Correctly annotate */&/&& in operator function calls Reverts 4986f3f2f220 (but keeps its unit tests) and fixes #49973 differently. Also fixes bugs that incorrectly annotate the operator keyword as TT_FunctionDeclarationName in function calls and as TT_Unknown in function declarations and definitions. Differential Revision: https://reviews.llvm.org/D154184
2023-06-29 18:14:18 -07:00
EXPECT_TOKEN(Tokens[2], tok::kw_operator, TT_Unknown);
[clang-format] Correctly annotate UDLs as OverloadedOperator While the opening parenthesis of an user-defined literal operator was correctly annotated as OverloadedOperatorLParen, the "" and its suffix wasn't annotated as OverloadedOperator. Fixes https://github.com/llvm/llvm-project/issues/58035 Differential Revision: https://reviews.llvm.org/D134853
2022-09-29 10:10:47 +03:00
// EXPECT_TOKEN(Tokens[3], tok::l_square, TT_OverloadedOperator);
// EXPECT_TOKEN(Tokens[4], tok::r_square, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[5], tok::l_paren, TT_OverloadedOperatorLParen);
Tokens = annotate("x.operator\"\"_a()");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
[clang-format] Correctly annotate */&/&& in operator function calls Reverts 4986f3f2f220 (but keeps its unit tests) and fixes #49973 differently. Also fixes bugs that incorrectly annotate the operator keyword as TT_FunctionDeclarationName in function calls and as TT_Unknown in function declarations and definitions. Differential Revision: https://reviews.llvm.org/D154184
2023-06-29 18:14:18 -07:00
EXPECT_TOKEN(Tokens[2], tok::kw_operator, TT_Unknown);
[clang-format] Correctly annotate UDLs as OverloadedOperator While the opening parenthesis of an user-defined literal operator was correctly annotated as OverloadedOperatorLParen, the "" and its suffix wasn't annotated as OverloadedOperator. Fixes https://github.com/llvm/llvm-project/issues/58035 Differential Revision: https://reviews.llvm.org/D134853
2022-09-29 10:10:47 +03:00
EXPECT_TOKEN(Tokens[3], tok::string_literal, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[4], tok::l_paren, TT_OverloadedOperatorLParen);
Tokens = annotate("x.operator\"\" _a()");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
[clang-format] Correctly annotate */&/&& in operator function calls Reverts 4986f3f2f220 (but keeps its unit tests) and fixes #49973 differently. Also fixes bugs that incorrectly annotate the operator keyword as TT_FunctionDeclarationName in function calls and as TT_Unknown in function declarations and definitions. Differential Revision: https://reviews.llvm.org/D154184
2023-06-29 18:14:18 -07:00
EXPECT_TOKEN(Tokens[2], tok::kw_operator, TT_Unknown);
[clang-format] Correctly annotate UDLs as OverloadedOperator While the opening parenthesis of an user-defined literal operator was correctly annotated as OverloadedOperatorLParen, the "" and its suffix wasn't annotated as OverloadedOperator. Fixes https://github.com/llvm/llvm-project/issues/58035 Differential Revision: https://reviews.llvm.org/D134853
2022-09-29 10:10:47 +03:00
EXPECT_TOKEN(Tokens[3], tok::string_literal, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[5], tok::l_paren, TT_OverloadedOperatorLParen);
Tokens = annotate("x.operator\"\"if()");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
[clang-format] Correctly annotate */&/&& in operator function calls Reverts 4986f3f2f220 (but keeps its unit tests) and fixes #49973 differently. Also fixes bugs that incorrectly annotate the operator keyword as TT_FunctionDeclarationName in function calls and as TT_Unknown in function declarations and definitions. Differential Revision: https://reviews.llvm.org/D154184
2023-06-29 18:14:18 -07:00
EXPECT_TOKEN(Tokens[2], tok::kw_operator, TT_Unknown);
[clang-format] Correctly annotate UDLs as OverloadedOperator While the opening parenthesis of an user-defined literal operator was correctly annotated as OverloadedOperatorLParen, the "" and its suffix wasn't annotated as OverloadedOperator. Fixes https://github.com/llvm/llvm-project/issues/58035 Differential Revision: https://reviews.llvm.org/D134853
2022-09-29 10:10:47 +03:00
EXPECT_TOKEN(Tokens[3], tok::string_literal, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[4], tok::l_paren, TT_OverloadedOperatorLParen);
Tokens = annotate("x.operator\"\"s()");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
[clang-format] Correctly annotate */&/&& in operator function calls Reverts 4986f3f2f220 (but keeps its unit tests) and fixes #49973 differently. Also fixes bugs that incorrectly annotate the operator keyword as TT_FunctionDeclarationName in function calls and as TT_Unknown in function declarations and definitions. Differential Revision: https://reviews.llvm.org/D154184
2023-06-29 18:14:18 -07:00
EXPECT_TOKEN(Tokens[2], tok::kw_operator, TT_Unknown);
[clang-format] Correctly annotate UDLs as OverloadedOperator While the opening parenthesis of an user-defined literal operator was correctly annotated as OverloadedOperatorLParen, the "" and its suffix wasn't annotated as OverloadedOperator. Fixes https://github.com/llvm/llvm-project/issues/58035 Differential Revision: https://reviews.llvm.org/D134853
2022-09-29 10:10:47 +03:00
EXPECT_TOKEN(Tokens[3], tok::string_literal, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[4], tok::l_paren, TT_OverloadedOperatorLParen);
Tokens = annotate("x.operator\"\" s()");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
[clang-format] Correctly annotate */&/&& in operator function calls Reverts 4986f3f2f220 (but keeps its unit tests) and fixes #49973 differently. Also fixes bugs that incorrectly annotate the operator keyword as TT_FunctionDeclarationName in function calls and as TT_Unknown in function declarations and definitions. Differential Revision: https://reviews.llvm.org/D154184
2023-06-29 18:14:18 -07:00
EXPECT_TOKEN(Tokens[2], tok::kw_operator, TT_Unknown);
[clang-format] Correctly annotate UDLs as OverloadedOperator While the opening parenthesis of an user-defined literal operator was correctly annotated as OverloadedOperatorLParen, the "" and its suffix wasn't annotated as OverloadedOperator. Fixes https://github.com/llvm/llvm-project/issues/58035 Differential Revision: https://reviews.llvm.org/D134853
2022-09-29 10:10:47 +03:00
EXPECT_TOKEN(Tokens[3], tok::string_literal, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[5], tok::l_paren, TT_OverloadedOperatorLParen);
[clang-format] Remove special case for kw_operator when aligning decls This change breaks no existing tests but does fix the linked issue. Declarations of operator overloads are annotated with `TT_FunctionDeclarationName` on the `operator` keyword, which is already being checked for when aligning, so the extra `kw_operator` doesn't seem to be necessary. (just for reference, it was added in rG92b397fb9d55ccdf4632c2b1b15b4a0ee417cf74 / 92b397fb9d55ccdf4632c2b1b15b4a0ee417cf74) Fixes https://github.com/llvm/llvm-project/issues/55733 Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D137223
2022-11-17 11:35:43 +02:00
Tokens = annotate("int operator+(int);");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::kw_operator, TT_FunctionDeclarationName);
EXPECT_TOKEN(Tokens[2], tok::plus, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[3], tok::l_paren, TT_OverloadedOperatorLParen);
Tokens = annotate("auto operator=(T&) {}");
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::kw_operator, TT_FunctionDeclarationName);
EXPECT_TOKEN(Tokens[2], tok::equal, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[3], tok::l_paren, TT_OverloadedOperatorLParen);
Tokens = annotate("auto operator()() {}");
ASSERT_EQ(Tokens.size(), 9u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::kw_operator, TT_FunctionDeclarationName);
EXPECT_TOKEN(Tokens[2], tok::l_paren, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[3], tok::r_paren, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[4], tok::l_paren, TT_OverloadedOperatorLParen);
[clang-format] Correctly annotate operator free function call The annotator correctly annotates an overloaded operator call when called as a member function, like `x.operator+(y)`, however, when called as a free function, like `operator+(x, y)`, the annotator assumed it was an overloaded operator function *declaration*, instead of a call. This patch allows for a free function call to correctly be annotated as a call, but only if the current like cannot be a declaration, usually within the bodies of a function. Fixes https://github.com/llvm/llvm-project/issues/49973 Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay, Nuullll Differential Revision: https://reviews.llvm.org/D153798
2023-06-29 19:46:04 +03:00
Tokens = annotate("class Foo {\n"
" int operator+(a* b);\n"
"}");
ASSERT_EQ(Tokens.size(), 14u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::kw_operator, TT_FunctionDeclarationName);
EXPECT_TOKEN(Tokens[5], tok::plus, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[6], tok::l_paren, TT_OverloadedOperatorLParen);
EXPECT_TOKEN(Tokens[8], tok::star, TT_PointerOrReference);
[clang-format] Correctly annotate */&/&& in operator function calls Reverts 4986f3f2f220 (but keeps its unit tests) and fixes #49973 differently. Also fixes bugs that incorrectly annotate the operator keyword as TT_FunctionDeclarationName in function calls and as TT_Unknown in function declarations and definitions. Differential Revision: https://reviews.llvm.org/D154184
2023-06-29 18:14:18 -07:00
Tokens = annotate("class Foo {\n"
" int c = operator+(a * b);\n"
"}");
ASSERT_EQ(Tokens.size(), 16u) << Tokens;
EXPECT_TOKEN(Tokens[6], tok::kw_operator, TT_Unknown);
EXPECT_TOKEN(Tokens[7], tok::plus, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[8], tok::l_paren, TT_OverloadedOperatorLParen);
EXPECT_TOKEN(Tokens[10], tok::star, TT_BinaryOperator);
[clang-format] Correctly annotate operator free function call The annotator correctly annotates an overloaded operator call when called as a member function, like `x.operator+(y)`, however, when called as a free function, like `operator+(x, y)`, the annotator assumed it was an overloaded operator function *declaration*, instead of a call. This patch allows for a free function call to correctly be annotated as a call, but only if the current like cannot be a declaration, usually within the bodies of a function. Fixes https://github.com/llvm/llvm-project/issues/49973 Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay, Nuullll Differential Revision: https://reviews.llvm.org/D153798
2023-06-29 19:46:04 +03:00
Tokens = annotate("void foo() {\n"
" operator+(a * b);\n"
"}");
ASSERT_EQ(Tokens.size(), 15u) << Tokens;
[clang-format] Correctly annotate */&/&& in operator function calls Reverts 4986f3f2f220 (but keeps its unit tests) and fixes #49973 differently. Also fixes bugs that incorrectly annotate the operator keyword as TT_FunctionDeclarationName in function calls and as TT_Unknown in function declarations and definitions. Differential Revision: https://reviews.llvm.org/D154184
2023-06-29 18:14:18 -07:00
EXPECT_TOKEN(Tokens[5], tok::kw_operator, TT_Unknown);
[clang-format] Correctly annotate operator free function call The annotator correctly annotates an overloaded operator call when called as a member function, like `x.operator+(y)`, however, when called as a free function, like `operator+(x, y)`, the annotator assumed it was an overloaded operator function *declaration*, instead of a call. This patch allows for a free function call to correctly be annotated as a call, but only if the current like cannot be a declaration, usually within the bodies of a function. Fixes https://github.com/llvm/llvm-project/issues/49973 Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay, Nuullll Differential Revision: https://reviews.llvm.org/D153798
2023-06-29 19:46:04 +03:00
EXPECT_TOKEN(Tokens[6], tok::plus, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[7], tok::l_paren, TT_OverloadedOperatorLParen);
EXPECT_TOKEN(Tokens[9], tok::star, TT_BinaryOperator);
[clang-format] Correctly annotate */&/&& in operator function calls Reverts 4986f3f2f220 (but keeps its unit tests) and fixes #49973 differently. Also fixes bugs that incorrectly annotate the operator keyword as TT_FunctionDeclarationName in function calls and as TT_Unknown in function declarations and definitions. Differential Revision: https://reviews.llvm.org/D154184
2023-06-29 18:14:18 -07:00
Tokens = annotate("return operator+(a * b, c & d) + operator+(a && b && c);");
ASSERT_EQ(Tokens.size(), 24u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::kw_operator, TT_Unknown);
EXPECT_TOKEN(Tokens[2], tok::plus, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[3], tok::l_paren, TT_OverloadedOperatorLParen);
EXPECT_TOKEN(Tokens[5], tok::star, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[9], tok::amp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[13], tok::kw_operator, TT_Unknown);
EXPECT_TOKEN(Tokens[14], tok::plus, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[15], tok::l_paren, TT_OverloadedOperatorLParen);
EXPECT_TOKEN(Tokens[17], tok::ampamp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[19], tok::ampamp, TT_BinaryOperator);
[clang-format] Correctly annotate operator free function call The annotator correctly annotates an overloaded operator call when called as a member function, like `x.operator+(y)`, however, when called as a free function, like `operator+(x, y)`, the annotator assumed it was an overloaded operator function *declaration*, instead of a call. This patch allows for a free function call to correctly be annotated as a call, but only if the current like cannot be a declaration, usually within the bodies of a function. Fixes https://github.com/llvm/llvm-project/issues/49973 Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay, Nuullll Differential Revision: https://reviews.llvm.org/D153798
2023-06-29 19:46:04 +03:00
Tokens = annotate("class Foo {\n"
" void foo() {\n"
" operator+(a * b);\n"
" }\n"
"}");
ASSERT_EQ(Tokens.size(), 19u) << Tokens;
[clang-format] Correctly annotate */&/&& in operator function calls Reverts 4986f3f2f220 (but keeps its unit tests) and fixes #49973 differently. Also fixes bugs that incorrectly annotate the operator keyword as TT_FunctionDeclarationName in function calls and as TT_Unknown in function declarations and definitions. Differential Revision: https://reviews.llvm.org/D154184
2023-06-29 18:14:18 -07:00
EXPECT_TOKEN(Tokens[8], tok::kw_operator, TT_Unknown);
[clang-format] Correctly annotate operator free function call The annotator correctly annotates an overloaded operator call when called as a member function, like `x.operator+(y)`, however, when called as a free function, like `operator+(x, y)`, the annotator assumed it was an overloaded operator function *declaration*, instead of a call. This patch allows for a free function call to correctly be annotated as a call, but only if the current like cannot be a declaration, usually within the bodies of a function. Fixes https://github.com/llvm/llvm-project/issues/49973 Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay, Nuullll Differential Revision: https://reviews.llvm.org/D153798
2023-06-29 19:46:04 +03:00
EXPECT_TOKEN(Tokens[9], tok::plus, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[10], tok::l_paren, TT_OverloadedOperatorLParen);
EXPECT_TOKEN(Tokens[12], tok::star, TT_BinaryOperator);
[clang-format] Correctly annotate overloaded operator function name The operator keyword preceded by a template closer should be annotated as TT_FunctionDeclarationName. Fixes #63879. Differential Revision: https://reviews.llvm.org/D155358
2023-07-15 00:45:18 -07:00
Tokens = annotate("std::vector<Foo> operator()(Foo &foo);");
ASSERT_EQ(Tokens.size(), 16u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[5], tok::greater, TT_TemplateCloser);
EXPECT_TOKEN(Tokens[6], tok::kw_operator, TT_FunctionDeclarationName);
EXPECT_TOKEN(Tokens[7], tok::l_paren, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[8], tok::r_paren, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[9], tok::l_paren, TT_OverloadedOperatorLParen);
EXPECT_TOKEN(Tokens[11], tok::amp, TT_PointerOrReference);
[clang-format] Correctly annotate UDLs as OverloadedOperator While the opening parenthesis of an user-defined literal operator was correctly annotated as OverloadedOperatorLParen, the "" and its suffix wasn't annotated as OverloadedOperator. Fixes https://github.com/llvm/llvm-project/issues/58035 Differential Revision: https://reviews.llvm.org/D134853
2022-09-29 10:10:47 +03:00
}
Reland [clang-format] Add a space between an overloaded operator and '>' The token annotator doesn't annotate the template opener and closer as such if they enclose an overloaded operator. This causes the space between the operator and the closer to be removed, resulting in invalid C++ code. Fixes #58602. Differential Revision: https://reviews.llvm.org/D143755
2023-02-10 08:50:49 -08:00
TEST_F(TokenAnnotatorTest, OverloadedOperatorInTemplate) {
struct {
const char *Text;
tok::TokenKind Kind;
} Operators[] = {{"+", tok::plus},
{"-", tok::minus},
// FIXME:
// {"*", tok::star},
{"/", tok::slash},
{"%", tok::percent},
{"^", tok::caret},
// FIXME:
// {"&", tok::amp},
{"|", tok::pipe},
{"~", tok::tilde},
{"!", tok::exclaim},
{"=", tok::equal},
// FIXME:
// {"<", tok::less},
{">", tok::greater},
{"+=", tok::plusequal},
{"-=", tok::minusequal},
{"*=", tok::starequal},
{"/=", tok::slashequal},
{"%=", tok::percentequal},
{"^=", tok::caretequal},
{"&=", tok::ampequal},
{"|=", tok::pipeequal},
{"<<", tok::lessless},
{">>", tok::greatergreater},
{">>=", tok::greatergreaterequal},
{"<<=", tok::lesslessequal},
{"==", tok::equalequal},
{"!=", tok::exclaimequal},
{"<=", tok::lessequal},
{">=", tok::greaterequal},
{"<=>", tok::spaceship},
{"&&", tok::ampamp},
{"||", tok::pipepipe},
{"++", tok::plusplus},
{"--", tok::minusminus},
{",", tok::comma},
{"->*", tok::arrowstar},
{"->", tok::arrow}};
for (const auto &Operator : Operators) {
std::string Input("C<&operator");
Input += Operator.Text;
Input += " > a;";
auto Tokens = annotate(std::string(Input));
ASSERT_EQ(Tokens.size(), 9u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[4], Operator.Kind, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[5], tok::greater, TT_TemplateCloser);
}
auto Tokens = annotate("C<&operator< <X>> lt;");
ASSERT_EQ(Tokens.size(), 12u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[4], tok::less, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[5], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[7], tok::greater, TT_TemplateCloser);
EXPECT_TOKEN(Tokens[8], tok::greater, TT_TemplateCloser);
}
[clang-format] Improve require and concept handling - Added an option where to put the requires clauses. - Renamed IndentRequires to IndentRequiresClause. - Changed BreakBeforeConceptDeclaration from bool to an enum. Fixes https://llvm.org/PR32165, and https://llvm.org/PR52401. Differential Revision: https://reviews.llvm.org/D113319
2021-11-05 21:10:09 +01:00
TEST_F(TokenAnnotatorTest, UnderstandsRequiresClausesAndConcepts) {
auto Tokens = annotate("template <typename T>\n"
"concept C = (Foo && Bar) && (Bar && Baz);");
ASSERT_EQ(Tokens.size(), 21u) << Tokens;
EXPECT_TOKEN(Tokens[10], tok::ampamp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[13], tok::ampamp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[16], tok::ampamp, TT_BinaryOperator);
[clang-format] Concepts: allow identifiers after negation Previously, the formatter would refuse to treat identifiers within a compound concept definition as actually part of the definition, if they were after the negation operator !. It is now made consistent with the likes of && and ||. Fixes https://github.com/llvm/llvm-project/issues/55898 Differential Revision: https://reviews.llvm.org/D131978
2022-09-05 12:33:59 +02:00
Tokens = annotate("template <typename T>\n"
"concept C = Foo && !Bar;");
ASSERT_EQ(Tokens.size(), 14u) << Tokens;
EXPECT_TOKEN(Tokens[9], tok::ampamp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[10], tok::exclaim, TT_UnaryOperator);
[clang-format] Improve require and concept handling - Added an option where to put the requires clauses. - Renamed IndentRequires to IndentRequiresClause. - Changed BreakBeforeConceptDeclaration from bool to an enum. Fixes https://llvm.org/PR32165, and https://llvm.org/PR52401. Differential Revision: https://reviews.llvm.org/D113319
2021-11-05 21:10:09 +01:00
Tokens = annotate("template <typename T>\n"
"concept C = requires(T t) {\n"
" { t.foo() };\n"
"} && Bar<T> && Baz<T>;");
ASSERT_EQ(Tokens.size(), 35u) << Tokens;
[clang-format] Further improve support for requires expressions Detect requires expressions in more unusable contexts. This is far from perfect, but currently we have no good metric to decide between a requires expression and a trailing requires clause. Differential Revision: https://reviews.llvm.org/D119138
2022-02-07 15:46:46 +01:00
EXPECT_TOKEN(Tokens[8], tok::kw_requires, TT_RequiresExpression);
EXPECT_TOKEN(Tokens[9], tok::l_paren, TT_RequiresExpressionLParen);
EXPECT_TOKEN(Tokens[13], tok::l_brace, TT_RequiresExpressionLBrace);
[clang-format] Improve require and concept handling - Added an option where to put the requires clauses. - Renamed IndentRequires to IndentRequiresClause. - Changed BreakBeforeConceptDeclaration from bool to an enum. Fixes https://llvm.org/PR32165, and https://llvm.org/PR52401. Differential Revision: https://reviews.llvm.org/D113319
2021-11-05 21:10:09 +01:00
EXPECT_TOKEN(Tokens[23], tok::ampamp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[28], tok::ampamp, TT_BinaryOperator);
Tokens = annotate("template<typename T>\n"
"requires C1<T> && (C21<T> || C22<T> && C2e<T>) && C3<T>\n"
"struct Foo;");
ASSERT_EQ(Tokens.size(), 36u) << Tokens;
[clang-format] Further improve support for requires expressions Detect requires expressions in more unusable contexts. This is far from perfect, but currently we have no good metric to decide between a requires expression and a trailing requires clause. Differential Revision: https://reviews.llvm.org/D119138
2022-02-07 15:46:46 +01:00
EXPECT_TOKEN(Tokens[5], tok::kw_requires, TT_RequiresClause);
[clang-format] Improve require and concept handling - Added an option where to put the requires clauses. - Renamed IndentRequires to IndentRequiresClause. - Changed BreakBeforeConceptDeclaration from bool to an enum. Fixes https://llvm.org/PR32165, and https://llvm.org/PR52401. Differential Revision: https://reviews.llvm.org/D113319
2021-11-05 21:10:09 +01:00
EXPECT_TOKEN(Tokens[6], tok::identifier, TT_Unknown);
EXPECT_EQ(Tokens[6]->FakeLParens.size(), 1u);
EXPECT_TOKEN(Tokens[10], tok::ampamp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[16], tok::pipepipe, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[21], tok::ampamp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[27], tok::ampamp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[31], tok::greater, TT_TemplateCloser);
EXPECT_EQ(Tokens[31]->FakeRParens, 1u);
EXPECT_TRUE(Tokens[31]->ClosesRequiresClause);
Tokens =
annotate("template<typename T>\n"
"requires (C1<T> && (C21<T> || C22<T> && C2e<T>) && C3<T>)\n"
"struct Foo;");
ASSERT_EQ(Tokens.size(), 38u) << Tokens;
[clang-format] Further improve support for requires expressions Detect requires expressions in more unusable contexts. This is far from perfect, but currently we have no good metric to decide between a requires expression and a trailing requires clause. Differential Revision: https://reviews.llvm.org/D119138
2022-02-07 15:46:46 +01:00
EXPECT_TOKEN(Tokens[5], tok::kw_requires, TT_RequiresClause);
[clang-format] Improve require and concept handling - Added an option where to put the requires clauses. - Renamed IndentRequires to IndentRequiresClause. - Changed BreakBeforeConceptDeclaration from bool to an enum. Fixes https://llvm.org/PR32165, and https://llvm.org/PR52401. Differential Revision: https://reviews.llvm.org/D113319
2021-11-05 21:10:09 +01:00
EXPECT_TOKEN(Tokens[7], tok::identifier, TT_Unknown);
EXPECT_EQ(Tokens[7]->FakeLParens.size(), 1u);
EXPECT_TOKEN(Tokens[11], tok::ampamp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[17], tok::pipepipe, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[22], tok::ampamp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[28], tok::ampamp, TT_BinaryOperator);
EXPECT_TOKEN(Tokens[32], tok::greater, TT_TemplateCloser);
EXPECT_EQ(Tokens[32]->FakeRParens, 1u);
EXPECT_TOKEN(Tokens[33], tok::r_paren, TT_Unknown);
EXPECT_TRUE(Tokens[33]->ClosesRequiresClause);
[clang-format] Further improve support for requires expressions Detect requires expressions in more unusable contexts. This is far from perfect, but currently we have no good metric to decide between a requires expression and a trailing requires clause. Differential Revision: https://reviews.llvm.org/D119138
2022-02-07 15:46:46 +01:00
Tokens = annotate("template <typename T>\n"
"void foo(T) noexcept requires Bar<T>;");
ASSERT_EQ(Tokens.size(), 18u) << Tokens;
EXPECT_TOKEN(Tokens[11], tok::kw_requires, TT_RequiresClause);
[clang-format] Disallow trailing return arrows to be operators In the following construction: `template <typename T> requires Foo<T> || Bar<T> auto func() -> int;` The `->` of the trailing return type was actually considered as an operator as part of the binary operation in the requires clause, with the precedence level of `PrecedenceArrowAndPeriod`, leading to fake parens being inserted in strange locations, that would never be closed. Fixes one part of https://github.com/llvm/llvm-project/issues/56213 (the rest will probably be in a separate patch) Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D134049
2022-09-19 02:47:42 +03:00
Tokens = annotate("template <typename T>\n"
"requires Bar<T> || Baz<T>\n"
"auto foo(T) -> int;");
ASSERT_EQ(Tokens.size(), 24u) << Tokens;
EXPECT_TOKEN(Tokens[5], tok::kw_requires, TT_RequiresClause);
EXPECT_EQ(Tokens[11]->FakeLParens.size(), 0u);
EXPECT_TRUE(Tokens[14]->ClosesRequiresClause);
EXPECT_TOKEN(Tokens[20], tok::arrow, TT_TrailingReturnArrow);
[clang-format] Look ahead before consuming `bool` in requires clause. The comment handling the bool case says: "bool is only allowed if it is directly followed by a paren for a cast" This change more closely follows this directive by looking ahead for the paren before consuming the bool keyword itself. Without a following paren, the bool would be part of something else, such as a return type for a function declaration Fixes https://github.com/llvm/llvm-project/issues/57538 Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay Differential Revision: https://reviews.llvm.org/D134325
2022-09-25 20:30:10 +03:00
Tokens = annotate("template <typename T>\n"
"requires Bar<T>\n"
"bool foo(T) { return false; }");
ASSERT_EQ(Tokens.size(), 21u) << Tokens;
EXPECT_TOKEN(Tokens[5], tok::kw_requires, TT_RequiresClause);
EXPECT_TRUE(Tokens[9]->ClosesRequiresClause);
EXPECT_TOKEN(Tokens[11], tok::identifier, TT_FunctionDeclarationName);
[clang-format] Disallow decltype in the middle of constraints If a function with a `requires` clause as a constraint has a decltype return type, such as `decltype(auto)`, the decltype was seen to be part of the constraint clause, rather than as part of the function declaration, causing it to be placed on the wrong line. This patch disallows decltype to be a part of these clauses Fixes https://github.com/llvm/llvm-project/issues/59578 Depends on D140339 Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay Differential Revision: https://reviews.llvm.org/D140312
2023-01-06 05:18:19 +02:00
Tokens = annotate("template <typename T>\n"
"requires Bar<T>\n"
"decltype(auto) foo(T) { return false; }");
ASSERT_EQ(Tokens.size(), 24u) << Tokens;
EXPECT_TOKEN(Tokens[5], tok::kw_requires, TT_RequiresClause);
EXPECT_TRUE(Tokens[9]->ClosesRequiresClause);
EXPECT_TOKEN(Tokens[14], tok::identifier, TT_FunctionDeclarationName);
[clang-format] Further improve support for requires expressions Detect requires expressions in more unusable contexts. This is far from perfect, but currently we have no good metric to decide between a requires expression and a trailing requires clause. Differential Revision: https://reviews.llvm.org/D119138
2022-02-07 15:46:46 +01:00
Tokens = annotate("template <typename T>\n"
"struct S {\n"
" void foo() const requires Bar<T>;\n"
" void bar() const & requires Baz<T>;\n"
" void bar() && requires Baz2<T>;\n"
" void baz() const & noexcept requires Baz<T>;\n"
" void baz() && noexcept requires Baz2<T>;\n"
"};\n"
"\n"
"void S::bar() const & requires Baz<T> { }");
ASSERT_EQ(Tokens.size(), 85u) << Tokens;
EXPECT_TOKEN(Tokens[13], tok::kw_requires, TT_RequiresClause);
[clang-format] Treat &/&& as reference when followed by requires clause Previously, the token annotator would get confused and annotate a member function's ref qualifier as a binary operator, if said function also had a requires clause after it. This patch accounts for that, treating requires clauses more similarly to `noexcept`, which also comes after the ref qualifier. Fixes https://github.com/llvm/llvm-project/issues/61270 Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D145656
2023-03-14 12:48:05 +02:00
EXPECT_TOKEN(Tokens[24], tok::amp, TT_PointerOrReference);
[clang-format] Further improve support for requires expressions Detect requires expressions in more unusable contexts. This is far from perfect, but currently we have no good metric to decide between a requires expression and a trailing requires clause. Differential Revision: https://reviews.llvm.org/D119138
2022-02-07 15:46:46 +01:00
EXPECT_TOKEN(Tokens[25], tok::kw_requires, TT_RequiresClause);
[clang-format] Treat &/&& as reference when followed by requires clause Previously, the token annotator would get confused and annotate a member function's ref qualifier as a binary operator, if said function also had a requires clause after it. This patch accounts for that, treating requires clauses more similarly to `noexcept`, which also comes after the ref qualifier. Fixes https://github.com/llvm/llvm-project/issues/61270 Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D145656
2023-03-14 12:48:05 +02:00
EXPECT_TOKEN(Tokens[35], tok::ampamp, TT_PointerOrReference);
[clang-format] Further improve support for requires expressions Detect requires expressions in more unusable contexts. This is far from perfect, but currently we have no good metric to decide between a requires expression and a trailing requires clause. Differential Revision: https://reviews.llvm.org/D119138
2022-02-07 15:46:46 +01:00
EXPECT_TOKEN(Tokens[36], tok::kw_requires, TT_RequiresClause);
[clang-format] Treat &/&& as reference when followed by requires clause Previously, the token annotator would get confused and annotate a member function's ref qualifier as a binary operator, if said function also had a requires clause after it. This patch accounts for that, treating requires clauses more similarly to `noexcept`, which also comes after the ref qualifier. Fixes https://github.com/llvm/llvm-project/issues/61270 Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D145656
2023-03-14 12:48:05 +02:00
EXPECT_TOKEN(Tokens[47], tok::amp, TT_PointerOrReference);
[clang-format] Further improve support for requires expressions Detect requires expressions in more unusable contexts. This is far from perfect, but currently we have no good metric to decide between a requires expression and a trailing requires clause. Differential Revision: https://reviews.llvm.org/D119138
2022-02-07 15:46:46 +01:00
EXPECT_TOKEN(Tokens[49], tok::kw_requires, TT_RequiresClause);
[clang-format] Treat &/&& as reference when followed by requires clause Previously, the token annotator would get confused and annotate a member function's ref qualifier as a binary operator, if said function also had a requires clause after it. This patch accounts for that, treating requires clauses more similarly to `noexcept`, which also comes after the ref qualifier. Fixes https://github.com/llvm/llvm-project/issues/61270 Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D145656
2023-03-14 12:48:05 +02:00
EXPECT_TOKEN(Tokens[59], tok::ampamp, TT_PointerOrReference);
[clang-format] Further improve support for requires expressions Detect requires expressions in more unusable contexts. This is far from perfect, but currently we have no good metric to decide between a requires expression and a trailing requires clause. Differential Revision: https://reviews.llvm.org/D119138
2022-02-07 15:46:46 +01:00
EXPECT_TOKEN(Tokens[61], tok::kw_requires, TT_RequiresClause);
[clang-format] Treat &/&& as reference when followed by requires clause Previously, the token annotator would get confused and annotate a member function's ref qualifier as a binary operator, if said function also had a requires clause after it. This patch accounts for that, treating requires clauses more similarly to `noexcept`, which also comes after the ref qualifier. Fixes https://github.com/llvm/llvm-project/issues/61270 Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D145656
2023-03-14 12:48:05 +02:00
EXPECT_TOKEN(Tokens[76], tok::amp, TT_PointerOrReference);
[clang-format] Further improve support for requires expressions Detect requires expressions in more unusable contexts. This is far from perfect, but currently we have no good metric to decide between a requires expression and a trailing requires clause. Differential Revision: https://reviews.llvm.org/D119138
2022-02-07 15:46:46 +01:00
EXPECT_TOKEN(Tokens[77], tok::kw_requires, TT_RequiresClause);
Tokens = annotate("void Class::member() && requires(Constant) {}");
ASSERT_EQ(Tokens.size(), 14u) << Tokens;
EXPECT_TOKEN(Tokens[7], tok::kw_requires, TT_RequiresClause);
Tokens = annotate("void Class::member() && requires(Constant<T>) {}");
ASSERT_EQ(Tokens.size(), 17u) << Tokens;
EXPECT_TOKEN(Tokens[7], tok::kw_requires, TT_RequiresClause);
Tokens =
annotate("void Class::member() && requires(Namespace::Constant<T>) {}");
ASSERT_EQ(Tokens.size(), 19u) << Tokens;
EXPECT_TOKEN(Tokens[7], tok::kw_requires, TT_RequiresClause);
Tokens = annotate("void Class::member() && requires(typename "
"Namespace::Outer<T>::Inner::Constant) {}");
ASSERT_EQ(Tokens.size(), 24u) << Tokens;
EXPECT_TOKEN(Tokens[7], tok::kw_requires, TT_RequiresClause);
[clang-format] Fixed handling of requires clauses followed by attributes Fixes https://github.com/llvm/llvm-project/issues/53820. Differential Revision: https://reviews.llvm.org/D119893
2022-02-15 22:59:23 +01:00
Tokens = annotate("struct [[nodiscard]] zero_t {\n"
" template<class T>\n"
" requires requires { number_zero_v<T>; }\n"
" [[nodiscard]] constexpr operator T() const { "
"return number_zero_v<T>; }\n"
"};");
[clang-format][NFC] Output tokens on test assert Reviewed By: rymiel Differential Revision: https://reviews.llvm.org/D148482
2023-04-16 23:47:55 +00:00
ASSERT_EQ(Tokens.size(), 44u) << Tokens;
[clang-format] Fixed handling of requires clauses followed by attributes Fixes https://github.com/llvm/llvm-project/issues/53820. Differential Revision: https://reviews.llvm.org/D119893
2022-02-15 22:59:23 +01:00
EXPECT_TOKEN(Tokens[13], tok::kw_requires, TT_RequiresClause);
EXPECT_TOKEN(Tokens[14], tok::kw_requires, TT_RequiresExpression);
EXPECT_TOKEN(Tokens[15], tok::l_brace, TT_RequiresExpressionLBrace);
EXPECT_TOKEN(Tokens[21], tok::r_brace, TT_Unknown);
EXPECT_EQ(Tokens[21]->MatchingParen, Tokens[15]);
EXPECT_TRUE(Tokens[21]->ClosesRequiresClause);
[clang-format] fix nested angle brackets parse inside concept definition Due to how parseBracedList always stopped on the first closing angle bracket and was used in parsing angle bracketed expression inside concept definition, nested brackets inside concepts were parsed incorrectly. nextToken() call before calling parseBracedList is required because we were processing opening angle bracket inside parseBracedList second time leading to incorrect logic after my fix. Fixes https://github.com/llvm/llvm-project/issues/54943 Fixes https://github.com/llvm/llvm-project/issues/54837 Reviewed By: HazardyKnusperkeks, curdeius Differential Revision: https://reviews.llvm.org/D123896
2022-05-11 13:38:35 +02:00
Tokens =
annotate("template <class A, class B> concept C ="
"std::same_as<std::iter_value_t<A>, std::iter_value_t<B>>;");
ASSERT_EQ(Tokens.size(), 31u) << Tokens;
EXPECT_TOKEN(Tokens[8], tok::kw_concept, TT_Unknown);
EXPECT_TOKEN(Tokens[14], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[18], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[20], tok::greater, TT_TemplateCloser);
EXPECT_TOKEN(Tokens[25], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[27], tok::greater, TT_TemplateCloser);
EXPECT_TOKEN(Tokens[28], tok::greater, TT_TemplateCloser);
[clang-format] Further improve requires clause detection If there is a typeish token before the requires, it can't be a requires expression. Fixes https://github.com/llvm/llvm-project/issues/56176 Differential Revision: https://reviews.llvm.org/D128496
2022-06-24 08:02:35 +02:00
Tokens = annotate("auto bar() -> int requires(is_integral_v<T>) {}");
ASSERT_EQ(Tokens.size(), 16u) << Tokens;
EXPECT_TOKEN(Tokens[6], tok::kw_requires, TT_RequiresClause);
Tokens = annotate("auto bar() -> void requires(is_integral_v<T>) {}");
ASSERT_EQ(Tokens.size(), 16u) << Tokens;
EXPECT_TOKEN(Tokens[6], tok::kw_requires, TT_RequiresClause);
Tokens = annotate("auto bar() -> MyType requires(is_integral_v<T>) {}");
ASSERT_EQ(Tokens.size(), 16u) << Tokens;
EXPECT_TOKEN(Tokens[6], tok::kw_requires, TT_RequiresClause);
Tokens =
annotate("auto bar() -> SOME_MACRO_TYPE requires(is_integral_v<T>) {}");
ASSERT_EQ(Tokens.size(), 16u) << Tokens;
EXPECT_TOKEN(Tokens[6], tok::kw_requires, TT_RequiresClause);
Tokens =
annotate("auto bar() -> qualified::type requires(is_integral_v<T>) {}");
ASSERT_EQ(Tokens.size(), 18u) << Tokens;
EXPECT_TOKEN(Tokens[8], tok::kw_requires, TT_RequiresClause);
Tokens =
annotate("auto bar() -> Template<type> requires(is_integral_v<T>) {}");
ASSERT_EQ(Tokens.size(), 19u) << Tokens;
EXPECT_TOKEN(Tokens[9], tok::kw_requires, TT_RequiresClause);
[clang-format] Preserve AmpAmpTokenType in nested parentheses When parsing a requires clause, the UnwrappedLineParser would delegate to parseParens with an AmpAmpTokenType set to BinaryOperator. However, parseParens would not carry this over into any nested parens, meaning it could assign a different token type to an && in a requires clause. This patch makes sure parseParens inherits its parameter when performing a recursive call. Fixes https://github.com/llvm/llvm-project/issues/63251 Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay Differential Revision: https://reviews.llvm.org/D153641
2023-06-26 12:35:47 +03:00
Tokens = annotate("void foo() requires((A<T>) && C) {}");
ASSERT_EQ(Tokens.size(), 18u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::kw_requires, TT_RequiresClause);
EXPECT_TOKEN(Tokens[12], tok::ampamp, TT_BinaryOperator);
Tokens = annotate("void foo() requires(((A<T>) && C)) {}");
ASSERT_EQ(Tokens.size(), 20u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::kw_requires, TT_RequiresClause);
EXPECT_TOKEN(Tokens[13], tok::ampamp, TT_BinaryOperator);
Tokens = annotate("void foo() requires([](T&&){}(t)) {}");
ASSERT_EQ(Tokens.size(), 21u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::kw_requires, TT_RequiresClause);
EXPECT_TOKEN(Tokens[10], tok::ampamp, TT_PointerOrReference);
Tokens = annotate("void foo() requires([](T&& u){}(t)) {}");
ASSERT_EQ(Tokens.size(), 22u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::kw_requires, TT_RequiresClause);
EXPECT_TOKEN(Tokens[10], tok::ampamp, TT_PointerOrReference);
[clang-format] Further improve support for requires expressions Detect requires expressions in more unusable contexts. This is far from perfect, but currently we have no good metric to decide between a requires expression and a trailing requires clause. Differential Revision: https://reviews.llvm.org/D119138
2022-02-07 15:46:46 +01:00
}
TEST_F(TokenAnnotatorTest, UnderstandsRequiresExpressions) {
auto Tokens = annotate("bool b = requires(int i) { i + 5; };");
ASSERT_EQ(Tokens.size(), 16u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::kw_requires, TT_RequiresExpression);
EXPECT_TOKEN(Tokens[4], tok::l_paren, TT_RequiresExpressionLParen);
EXPECT_TOKEN(Tokens[8], tok::l_brace, TT_RequiresExpressionLBrace);
Tokens = annotate("if (requires(int i) { i + 5; }) return;");
ASSERT_EQ(Tokens.size(), 17u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::kw_requires, TT_RequiresExpression);
EXPECT_TOKEN(Tokens[3], tok::l_paren, TT_RequiresExpressionLParen);
EXPECT_TOKEN(Tokens[7], tok::l_brace, TT_RequiresExpressionLBrace);
Tokens = annotate("if (func() && requires(int i) { i + 5; }) return;");
ASSERT_EQ(Tokens.size(), 21u) << Tokens;
EXPECT_TOKEN(Tokens[6], tok::kw_requires, TT_RequiresExpression);
EXPECT_TOKEN(Tokens[7], tok::l_paren, TT_RequiresExpressionLParen);
EXPECT_TOKEN(Tokens[11], tok::l_brace, TT_RequiresExpressionLBrace);
Tokens = annotate("foo(requires(const T t) {});");
ASSERT_EQ(Tokens.size(), 13u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::kw_requires, TT_RequiresExpression);
EXPECT_TOKEN(Tokens[3], tok::l_paren, TT_RequiresExpressionLParen);
EXPECT_TOKEN(Tokens[8], tok::l_brace, TT_RequiresExpressionLBrace);
Tokens = annotate("foo(requires(const int t) {});");
ASSERT_EQ(Tokens.size(), 13u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::kw_requires, TT_RequiresExpression);
EXPECT_TOKEN(Tokens[3], tok::l_paren, TT_RequiresExpressionLParen);
EXPECT_TOKEN(Tokens[8], tok::l_brace, TT_RequiresExpressionLBrace);
Tokens = annotate("foo(requires(const T t) {});");
ASSERT_EQ(Tokens.size(), 13u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::kw_requires, TT_RequiresExpression);
EXPECT_TOKEN(Tokens[3], tok::l_paren, TT_RequiresExpressionLParen);
EXPECT_TOKEN(Tokens[8], tok::l_brace, TT_RequiresExpressionLBrace);
Tokens = annotate("foo(requires(int const* volatile t) {});");
ASSERT_EQ(Tokens.size(), 15u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::kw_requires, TT_RequiresExpression);
EXPECT_TOKEN(Tokens[3], tok::l_paren, TT_RequiresExpressionLParen);
[clang-format] Set requires expression params as not an expression Previously, the parens of a requires expression's "parameters" were not explicitly set, meaning they ended up as whatever the outer scope was. This is a problem in some cases though, since the process of determining star/amp checks if the token is inside of an expression context This patch always makes sure the context between those parens are always set to not be an expression Fixes https://github.com/llvm/llvm-project/issues/59600 Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D140330
2022-12-23 02:22:10 +02:00
EXPECT_TOKEN(Tokens[6], tok::star, TT_PointerOrReference);
[clang-format] Further improve support for requires expressions Detect requires expressions in more unusable contexts. This is far from perfect, but currently we have no good metric to decide between a requires expression and a trailing requires clause. Differential Revision: https://reviews.llvm.org/D119138
2022-02-07 15:46:46 +01:00
EXPECT_TOKEN(Tokens[10], tok::l_brace, TT_RequiresExpressionLBrace);
Tokens = annotate("foo(requires(T const* volatile t) {});");
ASSERT_EQ(Tokens.size(), 15u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::kw_requires, TT_RequiresExpression);
EXPECT_TOKEN(Tokens[3], tok::l_paren, TT_RequiresExpressionLParen);
[clang-format] Set requires expression params as not an expression Previously, the parens of a requires expression's "parameters" were not explicitly set, meaning they ended up as whatever the outer scope was. This is a problem in some cases though, since the process of determining star/amp checks if the token is inside of an expression context This patch always makes sure the context between those parens are always set to not be an expression Fixes https://github.com/llvm/llvm-project/issues/59600 Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D140330
2022-12-23 02:22:10 +02:00
EXPECT_TOKEN(Tokens[6], tok::star, TT_PointerOrReference);
[clang-format] Further improve support for requires expressions Detect requires expressions in more unusable contexts. This is far from perfect, but currently we have no good metric to decide between a requires expression and a trailing requires clause. Differential Revision: https://reviews.llvm.org/D119138
2022-02-07 15:46:46 +01:00
EXPECT_TOKEN(Tokens[10], tok::l_brace, TT_RequiresExpressionLBrace);
[clang-format] Set requires expression params as not an expression Previously, the parens of a requires expression's "parameters" were not explicitly set, meaning they ended up as whatever the outer scope was. This is a problem in some cases though, since the process of determining star/amp checks if the token is inside of an expression context This patch always makes sure the context between those parens are always set to not be an expression Fixes https://github.com/llvm/llvm-project/issues/59600 Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D140330
2022-12-23 02:22:10 +02:00
Tokens = annotate("foo(requires(T& t) {});");
ASSERT_EQ(Tokens.size(), 13u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::kw_requires, TT_RequiresExpression);
EXPECT_TOKEN(Tokens[3], tok::l_paren, TT_RequiresExpressionLParen);
EXPECT_TOKEN(Tokens[5], tok::amp, TT_PointerOrReference);
EXPECT_TOKEN(Tokens[8], tok::l_brace, TT_RequiresExpressionLBrace);
Tokens = annotate("foo(requires(T&& t) {});");
ASSERT_EQ(Tokens.size(), 13u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::kw_requires, TT_RequiresExpression);
EXPECT_TOKEN(Tokens[3], tok::l_paren, TT_RequiresExpressionLParen);
EXPECT_TOKEN(Tokens[5], tok::ampamp, TT_PointerOrReference);
EXPECT_TOKEN(Tokens[8], tok::l_brace, TT_RequiresExpressionLBrace);
Tokens = annotate("bool foo = requires(T& t) {};");
ASSERT_EQ(Tokens.size(), 13u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::kw_requires, TT_RequiresExpression);
EXPECT_TOKEN(Tokens[4], tok::l_paren, TT_RequiresExpressionLParen);
EXPECT_TOKEN(Tokens[6], tok::amp, TT_PointerOrReference);
EXPECT_TOKEN(Tokens[9], tok::l_brace, TT_RequiresExpressionLBrace);
Tokens = annotate("bool foo = requires(T&& t) {};");
ASSERT_EQ(Tokens.size(), 13u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::kw_requires, TT_RequiresExpression);
EXPECT_TOKEN(Tokens[4], tok::l_paren, TT_RequiresExpressionLParen);
EXPECT_TOKEN(Tokens[6], tok::ampamp, TT_PointerOrReference);
EXPECT_TOKEN(Tokens[9], tok::l_brace, TT_RequiresExpressionLBrace);
[clang-format] Further improve support for requires expressions Detect requires expressions in more unusable contexts. This is far from perfect, but currently we have no good metric to decide between a requires expression and a trailing requires clause. Differential Revision: https://reviews.llvm.org/D119138
2022-02-07 15:46:46 +01:00
Tokens =
annotate("foo(requires(const typename Outer<T>::Inner * const t) {});");
ASSERT_EQ(Tokens.size(), 21u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::kw_requires, TT_RequiresExpression);
EXPECT_TOKEN(Tokens[3], tok::l_paren, TT_RequiresExpressionLParen);
[clang-format] Set requires expression params as not an expression Previously, the parens of a requires expression's "parameters" were not explicitly set, meaning they ended up as whatever the outer scope was. This is a problem in some cases though, since the process of determining star/amp checks if the token is inside of an expression context This patch always makes sure the context between those parens are always set to not be an expression Fixes https://github.com/llvm/llvm-project/issues/59600 Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D140330
2022-12-23 02:22:10 +02:00
EXPECT_TOKEN(Tokens[12], tok::star, TT_PointerOrReference);
[clang-format] Further improve support for requires expressions Detect requires expressions in more unusable contexts. This is far from perfect, but currently we have no good metric to decide between a requires expression and a trailing requires clause. Differential Revision: https://reviews.llvm.org/D119138
2022-02-07 15:46:46 +01:00
EXPECT_TOKEN(Tokens[16], tok::l_brace, TT_RequiresExpressionLBrace);
Tokens = annotate("template <typename T>\n"
"concept C = requires(T T) {\n"
" requires Bar<T> && Foo<T>;\n"
"};");
ASSERT_EQ(Tokens.size(), 28u) << Tokens;
EXPECT_TOKEN(Tokens[8], tok::kw_requires, TT_RequiresExpression);
EXPECT_TOKEN(Tokens[9], tok::l_paren, TT_RequiresExpressionLParen);
EXPECT_TOKEN(Tokens[13], tok::l_brace, TT_RequiresExpressionLBrace);
EXPECT_TOKEN(Tokens[14], tok::kw_requires,
TT_RequiresClauseInARequiresExpression);
Tokens = annotate("template <typename T>\n"
"concept C = requires(T T) {\n"
" { t.func() } -> std::same_as<int>;"
" requires Bar<T> && Foo<T>;\n"
"};");
ASSERT_EQ(Tokens.size(), 43u) << Tokens;
EXPECT_TOKEN(Tokens[8], tok::kw_requires, TT_RequiresExpression);
EXPECT_TOKEN(Tokens[9], tok::l_paren, TT_RequiresExpressionLParen);
EXPECT_TOKEN(Tokens[13], tok::l_brace, TT_RequiresExpressionLBrace);
EXPECT_TOKEN(Tokens[29], tok::kw_requires,
TT_RequiresClauseInARequiresExpression);
[clang-format] Fix crash on invalid requires expression Fixes https://github.com/llvm/llvm-project/issues/54350 Differential Revision: https://reviews.llvm.org/D121550
2022-03-13 11:55:24 +01:00
// Invalid Code, but we don't want to crash. See http://llvm.org/PR54350.
Tokens = annotate("bool r10 = requires (struct new_struct { int x; } s) { "
"requires true; };");
ASSERT_EQ(Tokens.size(), 21u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::kw_requires, TT_RequiresExpression);
EXPECT_TOKEN(Tokens[4], tok::l_paren, TT_RequiresExpressionLParen);
EXPECT_TOKEN(Tokens[14], tok::l_brace, TT_RequiresExpressionLBrace);
[clang-format] Improve require and concept handling - Added an option where to put the requires clauses. - Renamed IndentRequires to IndentRequiresClause. - Changed BreakBeforeConceptDeclaration from bool to an enum. Fixes https://llvm.org/PR32165, and https://llvm.org/PR52401. Differential Revision: https://reviews.llvm.org/D113319
2021-11-05 21:10:09 +01:00
}
[clang-format] Mark pragma region lines as StringLiterals In our code-base we auto-generate pragma regions the regions look like method signatures like: `#pragma region MYREGION(Foo: bar)` The problem here was that the rest of the line after region was not marked as stringliteral as in the case of pragma mark so clang-format tried to change the formatting based on the method signature. Added test and mark it similar as pragma mark. Reviewed By: owenpan Differential Revision: https://reviews.llvm.org/D136336
2022-10-25 09:59:10 +02:00
TEST_F(TokenAnnotatorTest, UnderstandsPragmaRegion) {
// Everything after #pragma region should be ImplicitStringLiteral
auto Tokens = annotate("#pragma region Foo(Bar: Hello)");
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[5], tok::identifier, TT_ImplicitStringLiteral);
EXPECT_TOKEN(Tokens[6], tok::colon, TT_ImplicitStringLiteral);
EXPECT_TOKEN(Tokens[7], tok::identifier, TT_ImplicitStringLiteral);
// Make sure it's annotated correctly inside a function as well
Tokens = annotate("void test(){\n#pragma region Foo(Bar: Hello)\n}");
ASSERT_EQ(Tokens.size(), 16u) << Tokens;
EXPECT_TOKEN(Tokens[10], tok::identifier, TT_ImplicitStringLiteral);
EXPECT_TOKEN(Tokens[11], tok::colon, TT_ImplicitStringLiteral);
EXPECT_TOKEN(Tokens[12], tok::identifier, TT_ImplicitStringLiteral);
}
[clang-format] Improve require and concept handling - Added an option where to put the requires clauses. - Renamed IndentRequires to IndentRequiresClause. - Changed BreakBeforeConceptDeclaration from bool to an enum. Fixes https://llvm.org/PR32165, and https://llvm.org/PR52401. Differential Revision: https://reviews.llvm.org/D113319
2021-11-05 21:10:09 +01:00
TEST_F(TokenAnnotatorTest, RequiresDoesNotChangeParsingOfTheRest) {
[clang-format][NFC] Refactor RequiresDoesNotChangeParsingOfTheRest Differential Revision: https://reviews.llvm.org/D129982
2022-07-19 01:22:31 -07:00
const char *BaseCode = nullptr;
const char *ConstrainedCode = nullptr;
auto BaseTokenCount = 0u;
auto RequiresTokenCount = 0u;
auto PrefixTokenCount = 0u;
auto TestRequires = [&](int Line) {
const auto BaseTokens = annotate(BaseCode);
const auto ConstrainedTokens = annotate(ConstrainedCode);
#define LINE " (Line " << Line << ')'
ASSERT_EQ(BaseTokens.size(), BaseTokenCount) << BaseTokens << LINE;
ASSERT_EQ(ConstrainedTokens.size(), BaseTokenCount + RequiresTokenCount)
<< LINE;
for (auto I = 0u; I < BaseTokenCount; ++I) {
EXPECT_EQ(
*BaseTokens[I],
*ConstrainedTokens[I < PrefixTokenCount ? I : I + RequiresTokenCount])
<< I << LINE;
[clang-format][NFC] Format unit tests with insert/remove braces This patch is the result of running clang-format version 753fe33 in clang/unittests/Format/: clang-format -style="{InsertBraces: true, RemoveBracesLLVM: true}" -i *.cpp *.h Differential Revision: https://reviews.llvm.org/D125510
2022-05-12 18:03:24 -07:00
}
[clang-format] Improve require and concept handling - Added an option where to put the requires clauses. - Renamed IndentRequires to IndentRequiresClause. - Changed BreakBeforeConceptDeclaration from bool to an enum. Fixes https://llvm.org/PR32165, and https://llvm.org/PR52401. Differential Revision: https://reviews.llvm.org/D113319
2021-11-05 21:10:09 +01:00
[clang-format][NFC] Refactor RequiresDoesNotChangeParsingOfTheRest Differential Revision: https://reviews.llvm.org/D129982
2022-07-19 01:22:31 -07:00
#undef LINE
};
BaseCode = "template<typename T>\n"
"T Pi = 3.14;";
ConstrainedCode = "template<typename T>\n"
" requires Foo<T>\n"
"T Pi = 3.14;";
BaseTokenCount = 11;
RequiresTokenCount = 5;
PrefixTokenCount = 5;
TestRequires(__LINE__);
BaseCode = "template<typename T>\n"
"struct Bar;";
ConstrainedCode = "template<typename T>\n"
" requires Foo<T>\n"
"struct Bar;";
BaseTokenCount = 9;
TestRequires(__LINE__);
BaseCode = "template<typename T>\n"
"struct Bar {\n"
" T foo();\n"
" T bar();\n"
"};";
ConstrainedCode = "template<typename T>\n"
" requires Foo<T>\n"
"struct Bar {\n"
" T foo();\n"
" T bar();\n"
"};";
BaseTokenCount = 21;
TestRequires(__LINE__);
BaseCode = "template<typename T>\n"
"Bar(T) -> Bar<T>;";
ConstrainedCode = "template<typename T>\n"
" requires Foo<T>\n"
"Bar(T) -> Bar<T>;";
BaseTokenCount = 16;
TestRequires(__LINE__);
BaseCode = "template<typename T>\n"
"T foo();";
ConstrainedCode = "template<typename T>\n"
" requires Foo<T>\n"
"T foo();";
BaseTokenCount = 11;
TestRequires(__LINE__);
BaseCode = "template<typename T>\n"
"T foo() {\n"
" auto bar = baz();\n"
" return bar + T{};\n"
"}";
ConstrainedCode = "template<typename T>\n"
" requires Foo<T>\n"
"T foo() {\n"
" auto bar = baz();\n"
" return bar + T{};\n"
"}";
BaseTokenCount = 26;
TestRequires(__LINE__);
BaseCode = "template<typename T>\n"
"T foo();";
ConstrainedCode = "template<typename T>\n"
"T foo() requires Foo<T>;";
BaseTokenCount = 11;
PrefixTokenCount = 9;
TestRequires(__LINE__);
BaseCode = "template<typename T>\n"
"T foo() {\n"
" auto bar = baz();\n"
" return bar + T{};\n"
"}";
ConstrainedCode = "template<typename T>\n"
"T foo() requires Foo<T> {\n"
" auto bar = baz();\n"
" return bar + T{};\n"
"}";
BaseTokenCount = 26;
TestRequires(__LINE__);
[clang-format] Disallow requires clauses to become function declarations There already exists logic to disallow requires *expressions* to be treated as function declarations, but this expands it to include requires *clauses*, when they happen to also be parenthesized. Previously, in the following case: ``` template <typename T> requires(Foo<T>) T foo(); ``` The line with the requires clause was actually being considered as the line with the function declaration due to the parentheses, and the *real* function declaration on the next line became a trailing annotation (Together with https://reviews.llvm.org/D134049) Fixes https://github.com/llvm/llvm-project/issues/56213 Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D134052
2022-09-19 02:49:58 +03:00
BaseCode = "template<typename T>\n"
"T foo();";
ConstrainedCode = "template<typename T>\n"
" requires(Foo<T>)\n"
"T foo();";
BaseTokenCount = 11;
RequiresTokenCount = 7;
PrefixTokenCount = 5;
TestRequires(__LINE__);
[clang-format][NFC] Refactor RequiresDoesNotChangeParsingOfTheRest Differential Revision: https://reviews.llvm.org/D129982
2022-07-19 01:22:31 -07:00
BaseCode = "template<typename T>\n"
"Bar(T) -> Bar<typename T::I>;";
ConstrainedCode = "template<typename T>\n"
" requires requires(T &&t) {\n"
" typename T::I;\n"
" }\n"
"Bar(T) -> Bar<typename T::I>;";
BaseTokenCount = 19;
RequiresTokenCount = 14;
PrefixTokenCount = 5;
TestRequires(__LINE__);
BaseCode = "struct [[nodiscard]] zero_t {\n"
" template<class T>\n"
" [[nodiscard]] constexpr operator T() const { return v<T>; }\n"
"};";
ConstrainedCode =
"struct [[nodiscard]] zero_t {\n"
" template<class T>\n"
" requires requires { v<T>; }\n"
" [[nodiscard]] constexpr operator T() const { return v<T>; }\n"
"};";
BaseTokenCount = 35;
RequiresTokenCount = 9;
PrefixTokenCount = 13;
TestRequires(__LINE__);
BaseCode = "constexpr Foo(Foo const &other)\n"
" : value{other.value} {\n"
" do_magic();\n"
" do_more_magic();\n"
"}";
ConstrainedCode = "constexpr Foo(Foo const &other)\n"
" requires std::is_copy_constructible<T>\n"
" : value{other.value} {\n"
" do_magic();\n"
" do_more_magic();\n"
"}";
BaseTokenCount = 26;
RequiresTokenCount = 7;
PrefixTokenCount = 8;
TestRequires(__LINE__);
BaseCode = "constexpr Foo(Foo const &other)\n"
" : value{other.value} {\n"
" do_magic();\n"
" do_more_magic();\n"
"}";
ConstrainedCode = "constexpr Foo(Foo const &other)\n"
" requires (std::is_copy_constructible<T>)\n"
" : value{other.value} {\n"
" do_magic();\n"
" do_more_magic();\n"
"}";
RequiresTokenCount = 9;
TestRequires(__LINE__);
[clang-format] Improve require and concept handling - Added an option where to put the requires clauses. - Renamed IndentRequires to IndentRequiresClause. - Changed BreakBeforeConceptDeclaration from bool to an enum. Fixes https://llvm.org/PR32165, and https://llvm.org/PR52401. Differential Revision: https://reviews.llvm.org/D113319
2021-11-05 21:10:09 +01:00
}
[clang-format] Fix crash on asm block with label Fixes https://github.com/llvm/llvm-project/issues/54349 Differential Revision: https://reviews.llvm.org/D121559
2022-03-13 21:25:11 +01:00
TEST_F(TokenAnnotatorTest, UnderstandsAsm) {
auto Tokens = annotate("__asm{\n"
"a:\n"
"};");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::kw_asm, TT_Unknown);
EXPECT_TOKEN(Tokens[1], tok::l_brace, TT_InlineASMBrace);
EXPECT_TOKEN(Tokens[4], tok::r_brace, TT_InlineASMBrace);
}
[clang-format] Fix crash with ObjC Blocks Fixes https://github.com/llvm/llvm-project/issues/54367 Fixes https://github.com/llvm/llvm-project/issues/54368 Differential Revision: https://reviews.llvm.org/D121596
2022-03-14 13:19:08 +01:00
TEST_F(TokenAnnotatorTest, UnderstandsObjCBlock) {
auto Tokens = annotate("int (^)() = ^ ()\n"
" external_source_symbol() { //\n"
" return 1;\n"
"};");
ASSERT_EQ(Tokens.size(), 21u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::l_paren, TT_ObjCBlockLParen);
EXPECT_TOKEN(Tokens[13], tok::l_brace, TT_ObjCBlockLBrace);
Tokens = annotate("int *p = ^int*(){ //\n"
" return nullptr;\n"
"}();");
ASSERT_EQ(Tokens.size(), 19u) << Tokens;
EXPECT_TOKEN(Tokens[9], tok::l_brace, TT_ObjCBlockLBrace);
}
[clang-format] Don't misannotate left squares as lambda introducers A left square can start a lambda only if it's not preceded by an identifier other than return and co-wait/co-yield/co-return. Fixes #54245. Fixes #61786. Differential Revision: https://reviews.llvm.org/D147295
2023-03-30 20:16:52 -07:00
TEST_F(TokenAnnotatorTest, UnderstandsObjCMethodExpr) {
auto Tokens = annotate("void f() {\n"
" //\n"
" BOOL a = [b.c n] > 1;\n"
"}");
EXPECT_EQ(Tokens.size(), 20u) << Tokens;
EXPECT_TOKEN(Tokens[9], tok::l_square, TT_ObjCMethodExpr);
EXPECT_TOKEN(Tokens[15], tok::greater, TT_BinaryOperator);
}
[clang-format] Mark constexpr lambdas as lambda Otherwise the brace was detected as a function brace, not wrong per se, but when directly calling the lambda the calling parens were put on the next line. Differential Revision: https://reviews.llvm.org/D129946
2022-07-16 23:46:18 +02:00
TEST_F(TokenAnnotatorTest, UnderstandsLambdas) {
auto Tokens = annotate("[]() constexpr {}");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[5], tok::l_brace, TT_LambdaLBrace);
[clang-format] FIX: Misannotation 'auto' as trailing return type in lambdas Lambdas with trailing return type 'auto' are annotated incorrectly. It causes a misformatting. The simpliest code to reproduce is: ``` auto list = {[]() -> auto { return 0; }}; ``` Fixes https://github.com/llvm/llvm-project/issues/54798 Reviewed By: HazardyKnusperkeks, owenpan, curdeius Differential Revision: https://reviews.llvm.org/D130299
2022-07-27 22:19:08 +03:00
[clang-format] Correctly annotate static and consteval lambdas `P1169` "static operator()" (https://wg21.link/P1169) is accepted to C++23 and while clang itself doesn't exactly support it yet, clang-format could quite easily. This simply allows the keyword `static` to be a part of lambdas as specified by the addition to [expr.prim.lambda.general] While adding this, I noticed `consteval` lambdas also aren't handled, so that keyword is now allowed to be a part of lambdas as well Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay Differential Revision: https://reviews.llvm.org/D134587
2022-09-25 20:29:34 +03:00
Tokens = annotate("[]() consteval {}");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[5], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[]() mutable {}");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[5], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[]() static {}");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[5], tok::l_brace, TT_LambdaLBrace);
[clang-format] FIX: Misannotation 'auto' as trailing return type in lambdas Lambdas with trailing return type 'auto' are annotated incorrectly. It causes a misformatting. The simpliest code to reproduce is: ``` auto list = {[]() -> auto { return 0; }}; ``` Fixes https://github.com/llvm/llvm-project/issues/54798 Reviewed By: HazardyKnusperkeks, owenpan, curdeius Differential Revision: https://reviews.llvm.org/D130299
2022-07-27 22:19:08 +03:00
Tokens = annotate("[]() -> auto {}");
ASSERT_EQ(Tokens.size(), 9u) << Tokens;
[clang-format] Change heuristic for locating lambda template arguments Previously, the heuristic was simply to look for template argument- specific keywords, such as typename, class, template and auto that are preceded by a left angle bracket <. This changes the heuristic to instead look for a left angle bracket < preceded by a right square bracket ], since according to the C++ grammar, the template arguments must *directly* follow the introducer. (This sort of check might just end up being *too* aggressive) This patch also adds a bunch more token annotator tests for lambdas, specifically for some of the stranger forms of lambdas now allowed as of C++20 or soon-to-be-allowed as part of C++23. Fixes https://github.com/llvm/llvm-project/issues/57093 This does NOT resolve the FIXME regarding explicit template lists, but perhaps it gets closer Differential Revision: https://reviews.llvm.org/D132295
2022-09-06 12:22:34 +02:00
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
[clang-format] FIX: Misannotation 'auto' as trailing return type in lambdas Lambdas with trailing return type 'auto' are annotated incorrectly. It causes a misformatting. The simpliest code to reproduce is: ``` auto list = {[]() -> auto { return 0; }}; ``` Fixes https://github.com/llvm/llvm-project/issues/54798 Reviewed By: HazardyKnusperkeks, owenpan, curdeius Differential Revision: https://reviews.llvm.org/D130299
2022-07-27 22:19:08 +03:00
EXPECT_TOKEN(Tokens[4], tok::arrow, TT_LambdaArrow);
EXPECT_TOKEN(Tokens[6], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[]() -> auto & {}");
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
[clang-format] Change heuristic for locating lambda template arguments Previously, the heuristic was simply to look for template argument- specific keywords, such as typename, class, template and auto that are preceded by a left angle bracket <. This changes the heuristic to instead look for a left angle bracket < preceded by a right square bracket ], since according to the C++ grammar, the template arguments must *directly* follow the introducer. (This sort of check might just end up being *too* aggressive) This patch also adds a bunch more token annotator tests for lambdas, specifically for some of the stranger forms of lambdas now allowed as of C++20 or soon-to-be-allowed as part of C++23. Fixes https://github.com/llvm/llvm-project/issues/57093 This does NOT resolve the FIXME regarding explicit template lists, but perhaps it gets closer Differential Revision: https://reviews.llvm.org/D132295
2022-09-06 12:22:34 +02:00
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
[clang-format] FIX: Misannotation 'auto' as trailing return type in lambdas Lambdas with trailing return type 'auto' are annotated incorrectly. It causes a misformatting. The simpliest code to reproduce is: ``` auto list = {[]() -> auto { return 0; }}; ``` Fixes https://github.com/llvm/llvm-project/issues/54798 Reviewed By: HazardyKnusperkeks, owenpan, curdeius Differential Revision: https://reviews.llvm.org/D130299
2022-07-27 22:19:08 +03:00
EXPECT_TOKEN(Tokens[4], tok::arrow, TT_LambdaArrow);
EXPECT_TOKEN(Tokens[7], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[]() -> auto * {}");
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
[clang-format] Change heuristic for locating lambda template arguments Previously, the heuristic was simply to look for template argument- specific keywords, such as typename, class, template and auto that are preceded by a left angle bracket <. This changes the heuristic to instead look for a left angle bracket < preceded by a right square bracket ], since according to the C++ grammar, the template arguments must *directly* follow the introducer. (This sort of check might just end up being *too* aggressive) This patch also adds a bunch more token annotator tests for lambdas, specifically for some of the stranger forms of lambdas now allowed as of C++20 or soon-to-be-allowed as part of C++23. Fixes https://github.com/llvm/llvm-project/issues/57093 This does NOT resolve the FIXME regarding explicit template lists, but perhaps it gets closer Differential Revision: https://reviews.llvm.org/D132295
2022-09-06 12:22:34 +02:00
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
[clang-format] FIX: Misannotation 'auto' as trailing return type in lambdas Lambdas with trailing return type 'auto' are annotated incorrectly. It causes a misformatting. The simpliest code to reproduce is: ``` auto list = {[]() -> auto { return 0; }}; ``` Fixes https://github.com/llvm/llvm-project/issues/54798 Reviewed By: HazardyKnusperkeks, owenpan, curdeius Differential Revision: https://reviews.llvm.org/D130299
2022-07-27 22:19:08 +03:00
EXPECT_TOKEN(Tokens[4], tok::arrow, TT_LambdaArrow);
EXPECT_TOKEN(Tokens[7], tok::l_brace, TT_LambdaLBrace);
[clang-format] Change heuristic for locating lambda template arguments Previously, the heuristic was simply to look for template argument- specific keywords, such as typename, class, template and auto that are preceded by a left angle bracket <. This changes the heuristic to instead look for a left angle bracket < preceded by a right square bracket ], since according to the C++ grammar, the template arguments must *directly* follow the introducer. (This sort of check might just end up being *too* aggressive) This patch also adds a bunch more token annotator tests for lambdas, specifically for some of the stranger forms of lambdas now allowed as of C++20 or soon-to-be-allowed as part of C++23. Fixes https://github.com/llvm/llvm-project/issues/57093 This does NOT resolve the FIXME regarding explicit template lists, but perhaps it gets closer Differential Revision: https://reviews.llvm.org/D132295
2022-09-06 12:22:34 +02:00
Tokens = annotate("[] {}");
ASSERT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] noexcept {}");
ASSERT_EQ(Tokens.size(), 6u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[3], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] -> auto {}");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::arrow, TT_LambdaArrow);
EXPECT_TOKEN(Tokens[4], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] <typename T> () {}");
ASSERT_EQ(Tokens.size(), 11u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[8], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] <typename T> {}");
ASSERT_EQ(Tokens.size(), 9u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[6], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] <typename... T> () {}");
ASSERT_EQ(Tokens.size(), 12u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[9], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] <typename... T> {}");
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[7], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] <int... T> () {}");
ASSERT_EQ(Tokens.size(), 12u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[9], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] <int... T> {}");
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[7], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] <Foo... T> () {}");
ASSERT_EQ(Tokens.size(), 12u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[9], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] <Foo... T> {}");
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[7], tok::l_brace, TT_LambdaLBrace);
[clang-format] Annotate lambdas with requires clauses. The C++ grammar allows lambdas to have a *requires-clause* in two places, either directly after the *template-parameter-list*, such as: `[] <typename T> requires foo<T> (T t) { ... };` Or, at the end of the *lambda-declarator* (before the lambda's body): `[] <typename T> (T t) requires foo<T> { ... };` Previously, these cases weren't handled at all, resulting in weird results. Note that this commit only handles token annotation, so the actual formatting still ends up suboptimal. This is mostly because I do not yet know how to approach making the requires clause formatting of lambdas match the formatting for functions. Fixes https://github.com/llvm/llvm-project/issues/61269 Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D145642
2023-03-26 04:37:59 +03:00
// Lambdas with a requires-clause
Tokens = annotate("[] <typename T> (T t) requires Bar<T> {}");
ASSERT_EQ(Tokens.size(), 18u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[10], tok::kw_requires, TT_RequiresClause);
EXPECT_TRUE(Tokens[14]->ClosesRequiresClause);
EXPECT_TOKEN(Tokens[15], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] <typename T> (T &&t) requires Bar<T> {}");
ASSERT_EQ(Tokens.size(), 19u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[8], tok::ampamp, TT_PointerOrReference);
EXPECT_TOKEN(Tokens[11], tok::kw_requires, TT_RequiresClause);
EXPECT_TRUE(Tokens[15]->ClosesRequiresClause);
EXPECT_TOKEN(Tokens[16], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] <typename T> (T t) requires Foo<T> || Bar<T> {}");
ASSERT_EQ(Tokens.size(), 23u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[10], tok::kw_requires, TT_RequiresClause);
EXPECT_TRUE(Tokens[19]->ClosesRequiresClause);
EXPECT_TOKEN(Tokens[20], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] <typename T> (T t) -> T requires Bar<T> {}");
ASSERT_EQ(Tokens.size(), 20u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[10], tok::arrow, TT_LambdaArrow);
EXPECT_TOKEN(Tokens[12], tok::kw_requires, TT_RequiresClause);
EXPECT_TRUE(Tokens[16]->ClosesRequiresClause);
EXPECT_TOKEN(Tokens[17], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] <typename T> requires Bar<T> (T t) {}");
ASSERT_EQ(Tokens.size(), 18u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[6], tok::kw_requires, TT_RequiresClause);
EXPECT_TRUE(Tokens[10]->ClosesRequiresClause);
EXPECT_TOKEN(Tokens[15], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] <typename T> requires Bar<T> (T &&t) {}");
ASSERT_EQ(Tokens.size(), 19u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[6], tok::kw_requires, TT_RequiresClause);
EXPECT_TRUE(Tokens[10]->ClosesRequiresClause);
EXPECT_TOKEN(Tokens[13], tok::ampamp, TT_PointerOrReference);
EXPECT_TOKEN(Tokens[16], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] <typename T> requires Foo<T> || Bar<T> (T t) {}");
ASSERT_EQ(Tokens.size(), 23u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[6], tok::kw_requires, TT_RequiresClause);
EXPECT_TRUE(Tokens[15]->ClosesRequiresClause);
EXPECT_TOKEN(Tokens[20], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] <typename T> requires true (T&& t) {}");
ASSERT_EQ(Tokens.size(), 16u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[6], tok::kw_requires, TT_RequiresClause);
EXPECT_TRUE(Tokens[7]->ClosesRequiresClause);
EXPECT_TOKEN(Tokens[10], tok::ampamp, TT_PointerOrReference);
EXPECT_TOKEN(Tokens[13], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] <typename T> requires Bar<T> {}");
ASSERT_EQ(Tokens.size(), 14u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[6], tok::kw_requires, TT_RequiresClause);
EXPECT_TRUE(Tokens[10]->ClosesRequiresClause);
EXPECT_TOKEN(Tokens[11], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] <typename T> requires Bar<T> noexcept {}");
ASSERT_EQ(Tokens.size(), 15u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[6], tok::kw_requires, TT_RequiresClause);
EXPECT_TRUE(Tokens[10]->ClosesRequiresClause);
EXPECT_TOKEN(Tokens[12], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] <typename T> requires Bar<T> -> T {}");
ASSERT_EQ(Tokens.size(), 16u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[6], tok::kw_requires, TT_RequiresClause);
EXPECT_TRUE(Tokens[10]->ClosesRequiresClause);
EXPECT_TOKEN(Tokens[11], tok::arrow, TT_LambdaArrow);
EXPECT_TOKEN(Tokens[13], tok::l_brace, TT_LambdaLBrace);
Tokens = annotate("[] <typename T> requires Foo<T> (T t) requires Bar<T> {}");
ASSERT_EQ(Tokens.size(), 23u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
EXPECT_TOKEN(Tokens[6], tok::kw_requires, TT_RequiresClause);
EXPECT_TRUE(Tokens[10]->ClosesRequiresClause);
EXPECT_TOKEN(Tokens[15], tok::kw_requires, TT_RequiresClause);
EXPECT_TRUE(Tokens[19]->ClosesRequiresClause);
EXPECT_TOKEN(Tokens[20], tok::l_brace, TT_LambdaLBrace);
[clang-format] Mark constexpr lambdas as lambda Otherwise the brace was detected as a function brace, not wrong per se, but when directly calling the lambda the calling parens were put on the next line. Differential Revision: https://reviews.llvm.org/D129946
2022-07-16 23:46:18 +02:00
}
[clang-format] Don't put `noexcept` on empty line following constructor With the AlwaysBreakTemplateDeclarations option, having a constructor template for a type consisting of all-uppercase letters with a noexcept specifier would put said noexcept specifier on its own blank line. This is because the all-uppercase type is understood as a macro-like attribute (such as DEPRECATED()), and noexcept is seen as the declaration. However, noexcept is a keyword and cannot be an identifier on its own. Fixes https://github.com/llvm/llvm-project/issues/56216 Differential Revision: https://reviews.llvm.org/D132189
2022-09-05 12:19:31 +02:00
TEST_F(TokenAnnotatorTest, UnderstandsFunctionAnnotations) {
auto Tokens = annotate("template <typename T>\n"
"DEPRECATED(\"Use NewClass::NewFunction instead.\")\n"
"string OldFunction(const string &parameter) {}");
ASSERT_EQ(Tokens.size(), 20u) << Tokens;
EXPECT_TOKEN(Tokens[8], tok::r_paren, TT_FunctionAnnotationRParen);
Tokens = annotate("template <typename T>\n"
"A(T) noexcept;");
ASSERT_EQ(Tokens.size(), 12u) << Tokens;
EXPECT_TOKEN(Tokens[8], tok::r_paren, TT_Unknown);
}
[clang-format] Correctly annotate function names before attributes Fixes #58827. Differential Revision: https://reviews.llvm.org/D137486
2022-11-05 04:09:13 -07:00
TEST_F(TokenAnnotatorTest, UnderstandsFunctionDeclarationNames) {
auto Tokens = annotate("void f [[noreturn]] ();");
ASSERT_EQ(Tokens.size(), 11u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::identifier, TT_FunctionDeclarationName);
Tokens = annotate("void f [[noreturn]] () {}");
ASSERT_EQ(Tokens.size(), 12u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::identifier, TT_FunctionDeclarationName);
Reland "[clang-format] Annotate constructor/destructor names" (0e63f1aacc00 was reverted by 7590b7657004 due to a crash.) Annotate constructor/destructor names as FunctionDeclarationName. Fixes #63046. Differential Revision: https://reviews.llvm.org/D157963
2023-08-28 14:14:40 -07:00
Tokens = annotate("class Foo { public: Foo(); };");
ASSERT_EQ(Tokens.size(), 12u) << Tokens;
EXPECT_TOKEN(Tokens[5], tok::identifier, TT_FunctionDeclarationName);
Tokens = annotate("class Foo { public: ~Foo(); };");
ASSERT_EQ(Tokens.size(), 13u) << Tokens;
EXPECT_TOKEN(Tokens[6], tok::identifier, TT_FunctionDeclarationName);
Tokens = annotate("struct Foo { [[deprecated]] Foo() {} };");
ASSERT_EQ(Tokens.size(), 16u) << Tokens;
EXPECT_TOKEN(Tokens[8], tok::identifier, TT_FunctionDeclarationName);
EXPECT_TOKEN(Tokens[11], tok::l_brace, TT_FunctionLBrace);
Tokens = annotate("struct Foo { [[deprecated]] ~Foo() {} };");
ASSERT_EQ(Tokens.size(), 17u) << Tokens;
EXPECT_TOKEN(Tokens[9], tok::identifier, TT_FunctionDeclarationName);
EXPECT_TOKEN(Tokens[12], tok::l_brace, TT_FunctionLBrace);
Tokens = annotate("struct Foo { Foo() [[deprecated]] {} };");
ASSERT_EQ(Tokens.size(), 16u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::identifier, TT_FunctionDeclarationName);
EXPECT_TOKEN(Tokens[11], tok::l_brace, TT_FunctionLBrace);
Tokens = annotate("struct Foo { ~Foo() [[deprecated]] {} };");
ASSERT_EQ(Tokens.size(), 17u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::identifier, TT_FunctionDeclarationName);
EXPECT_TOKEN(Tokens[12], tok::l_brace, TT_FunctionLBrace);
Tokens = annotate("struct Foo { [[deprecated]] explicit Foo() {} };");
ASSERT_EQ(Tokens.size(), 17u) << Tokens;
EXPECT_TOKEN(Tokens[9], tok::identifier, TT_FunctionDeclarationName);
EXPECT_TOKEN(Tokens[12], tok::l_brace, TT_FunctionLBrace);
Tokens = annotate("struct Foo { virtual [[deprecated]] ~Foo() {} };");
ASSERT_EQ(Tokens.size(), 18u) << Tokens;
EXPECT_TOKEN(Tokens[10], tok::identifier, TT_FunctionDeclarationName);
EXPECT_TOKEN(Tokens[13], tok::l_brace, TT_FunctionLBrace);
Tokens = annotate("Foo::Foo() {}");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::identifier, TT_FunctionDeclarationName);
EXPECT_TOKEN(Tokens[5], tok::l_brace, TT_FunctionLBrace);
Tokens = annotate("Foo::~Foo() {}");
ASSERT_EQ(Tokens.size(), 9u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::identifier, TT_FunctionDeclarationName);
EXPECT_TOKEN(Tokens[6], tok::l_brace, TT_FunctionLBrace);
Tokens = annotate("#define FOO Foo::\n"
"FOO Foo();");
ASSERT_EQ(Tokens.size(), 11u) << Tokens;
EXPECT_TOKEN(Tokens[6], tok::identifier, TT_FunctionDeclarationName);
[clang-format] Correctly annotate return type of function pointer (#66893) Fixes #66857.
2023-09-26 14:17:49 -07:00
Tokens = annotate("struct Foo {\n"
" Bar (*func)();\n"
"};");
ASSERT_EQ(Tokens.size(), 14u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::identifier, TT_Unknown);
EXPECT_TOKEN(Tokens[4], tok::l_paren, TT_FunctionTypeLParen);
[clang-format] Correctly annotate function names before attributes Fixes #58827. Differential Revision: https://reviews.llvm.org/D137486
2022-11-05 04:09:13 -07:00
}
[clang-format] Properly handle the C11 _Generic keyword. This patch properly recognizes the generic selection expression introduced in C11, by adding an additional token type for the colons present in such expressions. Previously, they would be recognized as "inline ASM colons" purely by the fact that those are the last thing checked for. I tried to avoid adding an addition token type, but since colons by default like having spaces around them, I chose to add a new type so that no space is added after the type selector. Currently, no aspect of the formatting of these expressions in able to be configured, as I'm not sure what could even be configured here. One notable thing is that association list is always formatted as either entirely on one line, if it can fit, or with line breaks after every comma in the expression (also after the controlling expr.) This visually makes them more similar to switch statements when long, matching the behaviour of the selection expression, being that of a sort of switch on types, but also allows for terseness when only selecting for a few things. Fixes https://github.com/llvm/llvm-project/issues/18080 Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay Differential Revision: https://reviews.llvm.org/D139211
2023-01-11 06:00:07 +02:00
TEST_F(TokenAnnotatorTest, UnderstandsC11GenericSelection) {
auto Tokens = annotate("_Generic(x, int: 1, default: 0)");
ASSERT_EQ(Tokens.size(), 13u) << Tokens;
EXPECT_TOKEN(Tokens[0], tok::kw__Generic, TT_Unknown);
EXPECT_TOKEN(Tokens[5], tok::colon, TT_GenericSelectionColon);
EXPECT_TOKEN(Tokens[9], tok::colon, TT_GenericSelectionColon);
}
[clang-format] Don't allow variable decls to have trailing return arrows The heuristic for determining if an arrow is a trailing return arrow looks for the auto keyword, along with parentheses. This isn't sufficient, since it also triggers on variable declarations with an auto type, and with an arrow operator. This patch makes sure a function declaration is being parsed, instead of any other declaration. Fixes https://github.com/llvm/llvm-project/issues/61469 Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay Differential Revision: https://reviews.llvm.org/D147377
2023-04-03 15:54:17 +03:00
TEST_F(TokenAnnotatorTest, UnderstandsTrailingReturnArrow) {
auto Tokens = annotate("auto f() -> int;");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::arrow, TT_TrailingReturnArrow);
Tokens = annotate("auto operator->() -> int;");
ASSERT_EQ(Tokens.size(), 9u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::arrow, TT_OverloadedOperator);
EXPECT_TOKEN(Tokens[5], tok::arrow, TT_TrailingReturnArrow);
Tokens = annotate("auto operator++(int) -> int;");
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[6], tok::arrow, TT_TrailingReturnArrow);
Tokens = annotate("auto operator=() -> int;");
ASSERT_EQ(Tokens.size(), 9u) << Tokens;
EXPECT_TOKEN(Tokens[5], tok::arrow, TT_TrailingReturnArrow);
Tokens = annotate("auto operator=(int) -> int;");
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[6], tok::arrow, TT_TrailingReturnArrow);
Tokens = annotate("auto foo() -> auto { return Val; }");
ASSERT_EQ(Tokens.size(), 12u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::arrow, TT_TrailingReturnArrow);
Tokens = annotate("struct S { auto bar() const -> int; };");
ASSERT_EQ(Tokens.size(), 14u) << Tokens;
EXPECT_TOKEN(Tokens[8], tok::arrow, TT_TrailingReturnArrow);
// Not trailing return arrows
Tokens = annotate("auto a = b->c;");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::arrow, TT_Unknown);
Tokens = annotate("auto a = (b)->c;");
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[6], tok::arrow, TT_Unknown);
Tokens = annotate("auto a = b()->c;");
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[6], tok::arrow, TT_Unknown);
Tokens = annotate("auto a = b->c();");
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::arrow, TT_Unknown);
Tokens = annotate("decltype(auto) a = b()->c;");
ASSERT_EQ(Tokens.size(), 13u) << Tokens;
EXPECT_TOKEN(Tokens[9], tok::arrow, TT_Unknown);
Tokens = annotate("void f() { auto a = b->c(); }");
ASSERT_EQ(Tokens.size(), 16u) << Tokens;
EXPECT_TOKEN(Tokens[9], tok::arrow, TT_Unknown);
Tokens = annotate("void f() { auto a = b()->c; }");
ASSERT_EQ(Tokens.size(), 16u) << Tokens;
EXPECT_TOKEN(Tokens[11], tok::arrow, TT_Unknown);
// Mixed
Tokens = annotate("auto f() -> int { auto a = b()->c; }");
ASSERT_EQ(Tokens.size(), 18u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::arrow, TT_TrailingReturnArrow);
EXPECT_TOKEN(Tokens[13], tok::arrow, TT_Unknown);
}
[clang-format] Handle Verilog numbers and operators Reviewed By: HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D126845
2022-07-28 23:17:19 +00:00
TEST_F(TokenAnnotatorTest, UnderstandsVerilogOperators) {
auto Annotate = [this](llvm::StringRef Code) {
return annotate(Code, getLLVMStyle(FormatStyle::LK_Verilog));
};
// Test that unary operators get labeled as such and that operators like '++'
// don't get split.
tok::TokenKind Unary[] = {tok::plus, tok::minus, tok::exclaim,
tok::tilde, tok::amp, tok::pipe,
tok::caret, tok::plusplus, tok::minusminus};
for (auto Kind : Unary) {
auto Tokens =
Annotate(std::string("x = ") + tok::getPunctuatorSpelling(Kind) + "x;");
ASSERT_EQ(Tokens.size(), 6u) << Tokens;
EXPECT_TOKEN(Tokens[2], Kind, TT_UnaryOperator);
}
// Operators formed by joining two operators like '^~'. For some of these
// joined operators, we don't have a separate type, so we only test for their
// precedence.
std::pair<prec::Level, std::string> JoinedBinary[] = {
{prec::Comma, "<->"}, {prec::Assignment, "+="},
{prec::Assignment, "-="}, {prec::Assignment, "*="},
{prec::Assignment, "/="}, {prec::Assignment, "%="},
{prec::Assignment, "&="}, {prec::Assignment, "^="},
{prec::Assignment, "<<="}, {prec::Assignment, ">>="},
{prec::Assignment, "<<<="}, {prec::Assignment, ">>>="},
{prec::LogicalOr, "||"}, {prec::LogicalAnd, "&&"},
{prec::Equality, "=="}, {prec::Equality, "!="},
{prec::Equality, "==="}, {prec::Equality, "!=="},
{prec::Equality, "==?"}, {prec::Equality, "!=?"},
{prec::ExclusiveOr, "~^"}, {prec::ExclusiveOr, "^~"},
};
for (auto Operator : JoinedBinary) {
auto Tokens = Annotate(std::string("x = x ") + Operator.second + " x;");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN_TYPE(Tokens[3], TT_BinaryOperator);
EXPECT_TOKEN_PRECEDENCE(Tokens[3], Operator.first);
}
// '~^' and '^~' can be unary as well as binary operators.
auto Tokens = Annotate("x = ~^x;");
ASSERT_EQ(Tokens.size(), 6u) << Tokens;
EXPECT_TOKEN_TYPE(Tokens[2], TT_UnaryOperator);
Tokens = Annotate("x = ^~x;");
ASSERT_EQ(Tokens.size(), 6u) << Tokens;
EXPECT_TOKEN_TYPE(Tokens[2], TT_UnaryOperator);
// The unary operators '~&' and '~|' can only be unary operators. The current
// implementation treats each of them as separate unary '~' and '&' or '|'
// operators, which is enough for formatting purposes. In FormatTestVerilog,
// there is a test that there is no space in between. And even if a new line
// is inserted between the '~' and '|', the semantic meaning is the same as
// the joined operator, so the CanBreakBefore property doesn't need to be
// false for the second operator.
Tokens = Annotate("x = ~&x;");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::tilde, TT_UnaryOperator);
EXPECT_TOKEN(Tokens[3], tok::amp, TT_UnaryOperator);
Tokens = Annotate("x = ~|x;");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::tilde, TT_UnaryOperator);
EXPECT_TOKEN(Tokens[3], tok::pipe, TT_UnaryOperator);
[clang-format] Handle Verilog blocks Now stuff inside begin-end blocks get indented. Some tests are moved into FormatTestVerilog.Block from FormatTestVerilog.If because they have nothing to do with if statements. Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D128711
2022-07-28 23:24:43 +00:00
// Test for block label colons.
Tokens = Annotate("begin : x\n"
"end : x");
[clang-format][NFC] Output tokens on test assert Reviewed By: rymiel Differential Revision: https://reviews.llvm.org/D148482
2023-04-16 23:47:55 +00:00
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
[clang-format] Handle Verilog blocks Now stuff inside begin-end blocks get indented. Some tests are moved into FormatTestVerilog.Block from FormatTestVerilog.If because they have nothing to do with if statements. Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D128711
2022-07-28 23:24:43 +00:00
EXPECT_TOKEN(Tokens[1], tok::colon, TT_VerilogBlockLabelColon);
EXPECT_TOKEN(Tokens[4], tok::colon, TT_VerilogBlockLabelColon);
[clang-format] Handle Verilog modules Now things inside hierarchies like modules and interfaces are indented. When the module header spans multiple lines, all except the first line are indented as continuations. We added the property `IsContinuation` to mark lines that should be indented this way. In order that the colons inside square brackets don't get labeled as `TT_ObjCMethodExpr`, we added a check to only use this type when the language is not Verilog. Differential Revision: https://reviews.llvm.org/D128712
2022-07-28 23:39:46 +00:00
// Test that the dimension colon is annotated correctly.
Tokens = Annotate("var [1 : 0] x;");
ASSERT_EQ(Tokens.size(), 9u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::colon, TT_BitFieldColon);
Tokens = Annotate("extern function [1 : 0] x;");
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::colon, TT_BitFieldColon);
[clang-format] Recognize Verilog type dimension in module header We had the function `verilogGroupDecl` for that. However, the type name would be incorrectly annotated in `isStartOfName` when it was not a C++ keyword and followed another identifier. Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay Differential Revision: https://reviews.llvm.org/D149352
2023-04-30 22:26:41 +00:00
Tokens = Annotate("module test\n"
" (input wire [7 : 0] a[7 : 0]);\n"
"endmodule");
ASSERT_EQ(Tokens.size(), 20u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::identifier, TT_VerilogDimensionedTypeName);
EXPECT_TOKEN(Tokens[7], tok::colon, TT_BitFieldColon);
EXPECT_TOKEN(Tokens[13], tok::colon, TT_BitFieldColon);
[clang-format] Handle Verilog case statements These statements are like switch statements in C, but without the 'case' keyword in labels. How labels are parsed. In UnwrappedLineParser, the program tries to parse a statement every time it sees a colon. In TokenAnnotator, a colon that isn't part of an expression is annotated as a label. The token type `TT_GotoLabelColon` is added. We did not include Verilog in the name because we thought we would eventually have to fix the problem that case labels in C can't contain ternary conditional expressions and we would use that token type. The style is like below. Labels are on separate lines and indented by default. The linked style guide also has examples where labels and the corresponding statements are on the same lines. They are not supported for now. https://github.com/lowRISC/style-guides/blob/master/VerilogCodingStyle.md ``` case (state_q) StIdle: state_d = StA; StA: begin state_d = StB; end endcase ``` Differential Revision: https://reviews.llvm.org/D128714
2022-07-29 00:12:46 +00:00
// Test case labels and ternary operators.
Tokens = Annotate("case (x)\n"
" x:\n"
" x;\n"
"endcase\n");
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
[clang-format] Correctly format goto labels followed by blocks There doesn't seem to be an issue on GitHub. But previously, a space would be inserted before the goto colon in the code below. switch (x) { case 0: goto_0: { action(); break; } } Previously, the colon following a goto label would be annotated as `TT_InheritanceColon`. A goto label followed by an opening brace wasn't recognized. It is easy to add another line to have `spaceRequiredBefore` function recognize the case, but I believed it is more proper to avoid doing the same thing in `UnwrappedLineParser` and `TokenAnnotator`. So now the label colons would be labeled in `UnwrappedLineParser`, and `spaceRequiredBefore` would rely on that. Previously we had the type `TT_GotoLabelColon` intended for both goto labels and case labels. But since handling of goto labels and case labels differ somewhat, I split it into separate types for goto and case labels. This patch doesn't change the behavior for case labels. I added the lines annotating case labels because they would previously be mistakenly annotated as `TT_InheritanceColon` just like goto labels. And since I added the annotations, the checks for the `case` and `default` keywords in `spaceRequiredBefore` are not necessary anymore. Reviewed By: MyDeveloperDay Differential Revision: https://reviews.llvm.org/D148484
2023-04-30 22:22:31 +00:00
EXPECT_TOKEN(Tokens[5], tok::colon, TT_CaseLabelColon);
[clang-format] Handle Verilog case statements These statements are like switch statements in C, but without the 'case' keyword in labels. How labels are parsed. In UnwrappedLineParser, the program tries to parse a statement every time it sees a colon. In TokenAnnotator, a colon that isn't part of an expression is annotated as a label. The token type `TT_GotoLabelColon` is added. We did not include Verilog in the name because we thought we would eventually have to fix the problem that case labels in C can't contain ternary conditional expressions and we would use that token type. The style is like below. Labels are on separate lines and indented by default. The linked style guide also has examples where labels and the corresponding statements are on the same lines. They are not supported for now. https://github.com/lowRISC/style-guides/blob/master/VerilogCodingStyle.md ``` case (state_q) StIdle: state_d = StA; StA: begin state_d = StB; end endcase ``` Differential Revision: https://reviews.llvm.org/D128714
2022-07-29 00:12:46 +00:00
Tokens = Annotate("case (x)\n"
" x ? x : x:\n"
" x;\n"
"endcase\n");
ASSERT_EQ(Tokens.size(), 14u) << Tokens;
EXPECT_TOKEN(Tokens[5], tok::question, TT_ConditionalExpr);
EXPECT_TOKEN(Tokens[7], tok::colon, TT_ConditionalExpr);
[clang-format] Correctly format goto labels followed by blocks There doesn't seem to be an issue on GitHub. But previously, a space would be inserted before the goto colon in the code below. switch (x) { case 0: goto_0: { action(); break; } } Previously, the colon following a goto label would be annotated as `TT_InheritanceColon`. A goto label followed by an opening brace wasn't recognized. It is easy to add another line to have `spaceRequiredBefore` function recognize the case, but I believed it is more proper to avoid doing the same thing in `UnwrappedLineParser` and `TokenAnnotator`. So now the label colons would be labeled in `UnwrappedLineParser`, and `spaceRequiredBefore` would rely on that. Previously we had the type `TT_GotoLabelColon` intended for both goto labels and case labels. But since handling of goto labels and case labels differ somewhat, I split it into separate types for goto and case labels. This patch doesn't change the behavior for case labels. I added the lines annotating case labels because they would previously be mistakenly annotated as `TT_InheritanceColon` just like goto labels. And since I added the annotations, the checks for the `case` and `default` keywords in `spaceRequiredBefore` are not necessary anymore. Reviewed By: MyDeveloperDay Differential Revision: https://reviews.llvm.org/D148484
2023-04-30 22:22:31 +00:00
EXPECT_TOKEN(Tokens[9], tok::colon, TT_CaseLabelColon);
[clang-format] Recognize Verilog non-blocking assignment Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D142891
2023-02-06 00:57:03 +00:00
// Non-blocking assignments.
Tokens = Annotate("a <= b;");
[clang-format][NFC] Output tokens on test assert Reviewed By: rymiel Differential Revision: https://reviews.llvm.org/D148482
2023-04-16 23:47:55 +00:00
ASSERT_EQ(Tokens.size(), 5u) << Tokens;
[clang-format] Recognize Verilog non-blocking assignment Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D142891
2023-02-06 00:57:03 +00:00
EXPECT_TOKEN(Tokens[1], tok::lessequal, TT_BinaryOperator);
EXPECT_TOKEN_PRECEDENCE(Tokens[1], prec::Assignment);
Tokens = Annotate("if (a <= b) break;");
[clang-format][NFC] Output tokens on test assert Reviewed By: rymiel Differential Revision: https://reviews.llvm.org/D148482
2023-04-16 23:47:55 +00:00
ASSERT_EQ(Tokens.size(), 9u) << Tokens;
[clang-format] Recognize Verilog non-blocking assignment Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D142891
2023-02-06 00:57:03 +00:00
EXPECT_TOKEN(Tokens[3], tok::lessequal, TT_BinaryOperator);
EXPECT_TOKEN_PRECEDENCE(Tokens[3], prec::Relational);
Tokens = Annotate("a <= b <= a;");
[clang-format][NFC] Output tokens on test assert Reviewed By: rymiel Differential Revision: https://reviews.llvm.org/D148482
2023-04-16 23:47:55 +00:00
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
[clang-format] Recognize Verilog non-blocking assignment Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D142891
2023-02-06 00:57:03 +00:00
EXPECT_TOKEN(Tokens[1], tok::lessequal, TT_BinaryOperator);
EXPECT_TOKEN_PRECEDENCE(Tokens[1], prec::Assignment);
EXPECT_TOKEN(Tokens[3], tok::lessequal, TT_BinaryOperator);
EXPECT_TOKEN_PRECEDENCE(Tokens[3], prec::Relational);
[clang-format] Add option for having one port per line in Verilog We added the option `VerilogBreakBetweenInstancePorts` to put ports on separate lines in module instantiations. We made it default to true because style guides mostly recommend it that way for example: https://github.com/lowRISC/style-guides/blob/master/VerilogCodingStyle.md#module-instantiation Reviewed By: HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D147327
2023-04-04 14:42:21 +00:00
// Port lists in module instantiation.
Tokens = Annotate("module_x instance_1(port_1), instance_2(port_2);");
[clang-format][NFC] Output tokens on test assert Reviewed By: rymiel Differential Revision: https://reviews.llvm.org/D148482
2023-04-16 23:47:55 +00:00
ASSERT_EQ(Tokens.size(), 12u) << Tokens;
[clang-format] Add option for having one port per line in Verilog We added the option `VerilogBreakBetweenInstancePorts` to put ports on separate lines in module instantiations. We made it default to true because style guides mostly recommend it that way for example: https://github.com/lowRISC/style-guides/blob/master/VerilogCodingStyle.md#module-instantiation Reviewed By: HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D147327
2023-04-04 14:42:21 +00:00
EXPECT_TOKEN(Tokens[2], tok::l_paren, TT_VerilogInstancePortLParen);
EXPECT_TOKEN(Tokens[7], tok::l_paren, TT_VerilogInstancePortLParen);
Tokens = Annotate("module_x #(parameter) instance_1(port_1), "
"instance_2(port_2);");
[clang-format][NFC] Output tokens on test assert Reviewed By: rymiel Differential Revision: https://reviews.llvm.org/D148482
2023-04-16 23:47:55 +00:00
ASSERT_EQ(Tokens.size(), 16u) << Tokens;
[clang-format] Add option for having one port per line in Verilog We added the option `VerilogBreakBetweenInstancePorts` to put ports on separate lines in module instantiations. We made it default to true because style guides mostly recommend it that way for example: https://github.com/lowRISC/style-guides/blob/master/VerilogCodingStyle.md#module-instantiation Reviewed By: HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D147327
2023-04-04 14:42:21 +00:00
EXPECT_TOKEN(Tokens[2], tok::l_paren, TT_VerilogInstancePortLParen);
EXPECT_TOKEN(Tokens[6], tok::l_paren, TT_VerilogInstancePortLParen);
EXPECT_TOKEN(Tokens[11], tok::l_paren, TT_VerilogInstancePortLParen);
[clang-format] Handle Verilog assertions and loops Assert statements in Verilog can optionally have an else part. We handle them like for `if` statements, except that an `if` statement in the else part of an `assert` statement doesn't get merged with the `else` keyword. Like this: assert (x) $info(); else if (y) $info(); else if (z) $info(); else $info(); `foreach` and `repeat` are now handled like for or while loops. We used the type `TT_ConditionLParen` to mark the condition part so they are handled in the same way as the condition part of an `if` statement. When the code being formatted is not in Verilog, it is only set for `if` statements, not loops. It's because loop conditions are currently handled slightly differently, and existing behavior is not supposed to change. We formatted all files ending in `.cpp` and `.h` in the repository with and without this change. It showed that setting the type for `if` statements doesn't change existing behavior. And we noticed that we forgot to make the program print the list of tokens when the number is not correct in `TokenAnnotatorTest`. It's fixed now. Reviewed By: HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D147895
2023-04-16 21:55:50 +00:00
// Condition parentheses.
Tokens = Annotate("assert (x);");
ASSERT_EQ(Tokens.size(), 6u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::l_paren, TT_ConditionLParen);
Tokens = Annotate("assert #0 (x);");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::l_paren, TT_ConditionLParen);
Tokens = Annotate("assert final (x);");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::l_paren, TT_ConditionLParen);
Tokens = Annotate("foreach (x[x]) continue;");
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::l_paren, TT_ConditionLParen);
Tokens = Annotate("repeat (x[x]) continue;");
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::l_paren, TT_ConditionLParen);
Tokens = Annotate("case (x) endcase;");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::l_paren, TT_ConditionLParen);
[clang-format] Recognize Verilog edge identifiers Previously the event expression would be misidentified as a port list. A line break would be added after the comma. The events can be separated with either a comma or the `or` keyword, and a line break would not be inserted if the `or` keyword was used. We changed the behavior of the comma to match the `or` keyword. Before: ``` always @(posedge x, posedge y) x <= x; always @(posedge x or posedge y) x <= x; ``` After: ``` always @(posedge x, posedge y) x <= x; always @(posedge x or posedge y) x <= x; ``` Reviewed By: HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D149561
2023-05-07 05:12:18 +00:00
// Sensitivity list. The TT_Unknown type is clearly not binding for the
// future, please adapt if those tokens get annotated. This test is only here
// to prevent the comma from being annotated as TT_VerilogInstancePortComma.
Tokens = Annotate("always @(posedge x, posedge y);");
ASSERT_EQ(Tokens.size(), 11u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::l_paren, TT_Unknown);
EXPECT_TOKEN(Tokens[5], tok::comma, TT_Unknown);
EXPECT_TOKEN(Tokens[8], tok::r_paren, TT_Unknown);
[clang-format] Break long string literals in C#, etc. Now strings that are too long for one line in C#, Java, JavaScript, and Verilog get broken into several lines. C# and JavaScript interpolated strings are not broken. A new subclass BreakableStringLiteralUsingOperators is used to handle the logic for adding plus signs and commas. The updateAfterBroken method was added because now parentheses or braces may be required after the parentheses or commas are added. In order to decide whether the added plus sign should be unindented in the BreakableToken object, the logic for it is taken out into a separate function shouldUnindentNextOperator. The logic for finding the continuation indentation when the option AlignAfterOpenBracket is set to DontAlign is not implemented yet. So in that case the new line may have the wrong indentation, and the parts may have the wrong length if the string needs to be broken more than once because finding where to break the string depends on where the string starts. The preambles for the C# and Java unit tests are changed to the newer style in order to allow the 3-argument verifyFormat macro. Some cases are changed from verifyFormat to verifyImcompleteFormat because those use incomplete code and the new verifyFormat function checks that the code is complete. The line in the doc was changed to being indented by 4 spaces, that is, the default continuation indentation. It has always been the case. It was probably a mistake that the doc showed 2 spaces previously. This commit was fist committed as 16ccba51072b. The tests caused assertion failures. Then it was reverted in 547bce36132a. Reviewed By: MyDeveloperDay Differential Revision: https://reviews.llvm.org/D154093
2023-06-29 15:23:36 +00:00
// String literals in concatenation.
Tokens = Annotate("x = {\"\"};");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::string_literal, TT_StringInConcatenation);
Tokens = Annotate("x = {\"\", \"\"};");
ASSERT_EQ(Tokens.size(), 9u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::string_literal, TT_StringInConcatenation);
EXPECT_TOKEN(Tokens[5], tok::string_literal, TT_StringInConcatenation);
Tokens = Annotate("x = '{{\"\"}};");
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[5], tok::string_literal, TT_StringInConcatenation);
// Cases where the string should not be annotated that type. Fix the
// `TT_Unknown` if needed in the future.
Tokens = Annotate("x = {\"\" == \"\"};");
ASSERT_EQ(Tokens.size(), 9u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::string_literal, TT_Unknown);
EXPECT_TOKEN(Tokens[5], tok::string_literal, TT_Unknown);
Tokens = Annotate("x = {(\"\")};");
ASSERT_EQ(Tokens.size(), 9u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::string_literal, TT_Unknown);
Tokens = Annotate("x = '{\"\"};");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::string_literal, TT_Unknown);
[clang-format] Handle Verilog numbers and operators Reviewed By: HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D126845
2022-07-28 23:17:19 +00:00
}
[clang-format] Don't misannotate in CTor init list They were annotated with TrailingAnnotation, which they are not. And that resulted in some quirky formatting in some cases. Differential Revision: https://reviews.llvm.org/D136635
2022-10-24 21:21:31 +02:00
TEST_F(TokenAnnotatorTest, UnderstandConstructors) {
auto Tokens = annotate("Class::Class() : BaseClass(), Member() {}");
// The TT_Unknown is clearly not binding for the future, please adapt if those
// tokens get annotated.
ASSERT_EQ(Tokens.size(), 16u) << Tokens;
EXPECT_TOKEN(Tokens[5], tok::colon, TT_CtorInitializerColon);
EXPECT_TOKEN(Tokens[6], tok::identifier, TT_Unknown);
EXPECT_TOKEN(Tokens[7], tok::l_paren, TT_Unknown);
EXPECT_TOKEN(Tokens[8], tok::r_paren, TT_Unknown);
EXPECT_TOKEN(Tokens[9], tok::comma, TT_CtorInitializerComma);
EXPECT_TOKEN(Tokens[10], tok::identifier, TT_Unknown);
EXPECT_TOKEN(Tokens[11], tok::l_paren, TT_Unknown);
EXPECT_TOKEN(Tokens[12], tok::r_paren, TT_Unknown);
EXPECT_TOKEN(Tokens[13], tok::l_brace, TT_FunctionLBrace);
Tokens = annotate("Class::Class() : BaseClass{}, Member{} {}");
ASSERT_EQ(Tokens.size(), 16u) << Tokens;
EXPECT_TOKEN(Tokens[5], tok::colon, TT_CtorInitializerColon);
EXPECT_TOKEN(Tokens[6], tok::identifier, TT_Unknown);
EXPECT_TOKEN(Tokens[7], tok::l_brace, TT_Unknown);
EXPECT_TOKEN(Tokens[8], tok::r_brace, TT_Unknown);
EXPECT_TOKEN(Tokens[9], tok::comma, TT_CtorInitializerComma);
EXPECT_TOKEN(Tokens[10], tok::identifier, TT_Unknown);
EXPECT_TOKEN(Tokens[11], tok::l_brace, TT_Unknown);
EXPECT_TOKEN(Tokens[12], tok::r_brace, TT_Unknown);
EXPECT_TOKEN(Tokens[13], tok::l_brace, TT_FunctionLBrace);
}
[clang-format] Handle Verilog assertions and loops Assert statements in Verilog can optionally have an else part. We handle them like for `if` statements, except that an `if` statement in the else part of an `assert` statement doesn't get merged with the `else` keyword. Like this: assert (x) $info(); else if (y) $info(); else if (z) $info(); else $info(); `foreach` and `repeat` are now handled like for or while loops. We used the type `TT_ConditionLParen` to mark the condition part so they are handled in the same way as the condition part of an `if` statement. When the code being formatted is not in Verilog, it is only set for `if` statements, not loops. It's because loop conditions are currently handled slightly differently, and existing behavior is not supposed to change. We formatted all files ending in `.cpp` and `.h` in the repository with and without this change. It showed that setting the type for `if` statements doesn't change existing behavior. And we noticed that we forgot to make the program print the list of tokens when the number is not correct in `TokenAnnotatorTest`. It's fixed now. Reviewed By: HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D147895
2023-04-16 21:55:50 +00:00
TEST_F(TokenAnnotatorTest, UnderstandsConditionParens) {
auto Tokens = annotate("if (x) {}");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::l_paren, TT_ConditionLParen);
Tokens = annotate("if constexpr (x) {}");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::l_paren, TT_ConditionLParen);
Tokens = annotate("if CONSTEXPR (x) {}");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::l_paren, TT_ConditionLParen);
Tokens = annotate("if (x) {} else if (x) {}");
ASSERT_EQ(Tokens.size(), 14u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::l_paren, TT_ConditionLParen);
EXPECT_TOKEN(Tokens[8], tok::l_paren, TT_ConditionLParen);
}
[clang-format] C# short ternary operator misinterpreted as a CSharpNullable Refactor the CSharpNullable assignment code to be a little easier to read (Honestly I don't like it when an if expression get really long and complicated). Handle the case where '?' is actually a ternary operator. Fixes: #58067 Reviewed By: owenpan, HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D148473
2023-04-18 10:17:28 +01:00
TEST_F(TokenAnnotatorTest, CSharpNullableTypes) {
FormatStyle Style = getGoogleStyle(FormatStyle::LK_CSharp);
auto Tokens = annotate("int? a;", Style);
EXPECT_EQ(Tokens.size(), 5u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::question, TT_CSharpNullable);
Tokens = annotate("int? a = 1;", Style);
EXPECT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::question, TT_CSharpNullable);
Tokens = annotate("int?)", Style);
EXPECT_EQ(Tokens.size(), 4u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::question, TT_CSharpNullable);
Tokens = annotate("int?>", Style);
EXPECT_EQ(Tokens.size(), 4u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::question, TT_CSharpNullable);
Tokens = annotate("cond? id : id2", Style);
EXPECT_EQ(Tokens.size(), 6u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::question, TT_ConditionalExpr);
Tokens = annotate("cond ? cond2 ? : id1 : id2", Style);
EXPECT_EQ(Tokens.size(), 9u) << Tokens;
EXPECT_TOKEN(Tokens[1], tok::question, TT_ConditionalExpr);
}
[clang-format] Correctly format goto labels followed by blocks There doesn't seem to be an issue on GitHub. But previously, a space would be inserted before the goto colon in the code below. switch (x) { case 0: goto_0: { action(); break; } } Previously, the colon following a goto label would be annotated as `TT_InheritanceColon`. A goto label followed by an opening brace wasn't recognized. It is easy to add another line to have `spaceRequiredBefore` function recognize the case, but I believed it is more proper to avoid doing the same thing in `UnwrappedLineParser` and `TokenAnnotator`. So now the label colons would be labeled in `UnwrappedLineParser`, and `spaceRequiredBefore` would rely on that. Previously we had the type `TT_GotoLabelColon` intended for both goto labels and case labels. But since handling of goto labels and case labels differ somewhat, I split it into separate types for goto and case labels. This patch doesn't change the behavior for case labels. I added the lines annotating case labels because they would previously be mistakenly annotated as `TT_InheritanceColon` just like goto labels. And since I added the annotations, the checks for the `case` and `default` keywords in `spaceRequiredBefore` are not necessary anymore. Reviewed By: MyDeveloperDay Differential Revision: https://reviews.llvm.org/D148484
2023-04-30 22:22:31 +00:00
TEST_F(TokenAnnotatorTest, UnderstandsLabels) {
auto Tokens = annotate("{ x: break; }");
ASSERT_EQ(Tokens.size(), 7u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::colon, TT_GotoLabelColon);
Tokens = annotate("{ case x: break; }");
ASSERT_EQ(Tokens.size(), 8u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::colon, TT_CaseLabelColon);
Tokens = annotate("{ x: { break; } }");
ASSERT_EQ(Tokens.size(), 9u) << Tokens;
EXPECT_TOKEN(Tokens[2], tok::colon, TT_GotoLabelColon);
Tokens = annotate("{ case x: { break; } }");
ASSERT_EQ(Tokens.size(), 10u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::colon, TT_CaseLabelColon);
}
[clang-format] Adjust braced list detection (reland 6dcde65) This is a retry of https://reviews.llvm.org/D114583, which was backed out for regressions. Clang Format is detecting a nested scope followed by another open brace as a braced initializer list due to incorrectly thinking it's matching a braced initializer at the end of a constructor initializer list which is followed by the body open brace. Unfortunately, UnwrappedLineParser isn't doing a very detailed parse, so it's not super straightforward to distinguish these cases given the current structure of calculateBraceTypes. My current hypothesis is that these can be disambiguated by looking at the token preceding the l_brace, as initializer list parameters will be preceded by an identifier, but a scope block generally will not (barring the MACRO wildcard). To this end, I am adding tracking of the previous token to the LBraceStack to help scope this particular case. TokenAnnotatorTests cherry picked from https://reviews.llvm.org/D150452. Fixes #33891. Fixes #52911. Differential Revision: https://reviews.llvm.org/D150403
2023-05-22 20:11:17 -07:00
TEST_F(TokenAnnotatorTest, UnderstandsNestedBlocks) {
// The closing braces are not annotated. It doesn't seem to cause a problem.
// So we only test for the opening braces.
auto Tokens = annotate("{\n"
" {\n"
" { int a = 0; }\n"
" }\n"
" {}\n"
"}");
ASSERT_EQ(Tokens.size(), 14u) << Tokens;
EXPECT_BRACE_KIND(Tokens[0], BK_Block);
EXPECT_BRACE_KIND(Tokens[1], BK_Block);
EXPECT_BRACE_KIND(Tokens[2], BK_Block);
EXPECT_BRACE_KIND(Tokens[10], BK_Block);
}
[clang-format] Correctly annotate designated initializer with PP if (#65409) When encountering braces, such as those of a designated initializer, clang-format scans ahead to see what is contained within the braces. If it found a statement, like an if-statement of for-loop, it would deem the braces as not an initializer, but as a block instead. However, this heuristic incorrectly included a preprocessor `#if` line as an if-statement. This manifested in strange results and discrepancies between `#ifdef` and `#if defined`. With this patch, `if` is now ignored if it is preceeded by `#`. Fixes most of https://github.com/llvm/llvm-project/issues/56685
2023-09-07 22:23:05 +03:00
TEST_F(TokenAnnotatorTest, UnderstandDesignatedInitializers) {
auto Tokens = annotate("SomeStruct { .a = 1 };");
ASSERT_EQ(Tokens.size(), 9u) << Tokens;
EXPECT_BRACE_KIND(Tokens[1], BK_BracedInit);
EXPECT_TOKEN(Tokens[2], tok::period, TT_DesignatedInitializerPeriod);
Tokens = annotate("SomeStruct { .a = 1, .b = 2 };");
ASSERT_EQ(Tokens.size(), 14u) << Tokens;
EXPECT_BRACE_KIND(Tokens[1], BK_BracedInit);
EXPECT_TOKEN(Tokens[2], tok::period, TT_DesignatedInitializerPeriod);
EXPECT_TOKEN(Tokens[7], tok::period, TT_DesignatedInitializerPeriod);
Tokens = annotate("SomeStruct {\n"
"#ifdef FOO\n"
" .a = 1,\n"
"#endif\n"
" .b = 2\n"
"};");
ASSERT_EQ(Tokens.size(), 19u) << Tokens;
EXPECT_BRACE_KIND(Tokens[1], BK_BracedInit);
EXPECT_TOKEN(Tokens[5], tok::period, TT_DesignatedInitializerPeriod);
EXPECT_TOKEN(Tokens[12], tok::period, TT_DesignatedInitializerPeriod);
Tokens = annotate("SomeStruct {\n"
"#if defined FOO\n"
" .a = 1,\n"
"#endif\n"
" .b = 2\n"
"};");
ASSERT_EQ(Tokens.size(), 20u) << Tokens;
EXPECT_BRACE_KIND(Tokens[1], BK_BracedInit);
EXPECT_TOKEN(Tokens[6], tok::period, TT_DesignatedInitializerPeriod);
EXPECT_TOKEN(Tokens[13], tok::period, TT_DesignatedInitializerPeriod);
}
[clang-format] Stop breaking unbreakable strings in JS (#66168) Dictionary literal keys and strings in TypeScript type declarations can not be broken. The problem was pointed out by @alexfh and @e-kud here: https://reviews.llvm.org/D154093#4644512
2023-09-13 15:04:04 +00:00
TEST_F(TokenAnnotatorTest, UnderstandsJavaScript) {
auto Annotate = [this](llvm::StringRef Code) {
return annotate(Code, getLLVMStyle(FormatStyle::LK_JavaScript));
};
// Dictionary.
auto Tokens = Annotate("var x = {'x' : 1, 'y' : 2};");
ASSERT_EQ(Tokens.size(), 14u) << Tokens;
EXPECT_TOKEN(Tokens[3], tok::l_brace, TT_DictLiteral);
EXPECT_TOKEN(Tokens[4], tok::string_literal, TT_SelectorName);
EXPECT_TOKEN(Tokens[5], tok::colon, TT_DictLiteral);
EXPECT_TOKEN(Tokens[8], tok::string_literal, TT_SelectorName);
EXPECT_TOKEN(Tokens[9], tok::colon, TT_DictLiteral);
// Change when we need to annotate these.
EXPECT_BRACE_KIND(Tokens[3], BK_Unknown);
EXPECT_BRACE_KIND(Tokens[11], BK_Unknown);
EXPECT_TOKEN(Tokens[11], tok::r_brace, TT_Unknown);
}
[clang-format] Fix misformatted macro definitions after D86959 After D86959 the code `#define lambda [](const decltype(x) &ptr) {}` was formatted as `#define lambda [](const decltype(x) & ptr) {}` due to now parsing the '&' token as a BinaryOperator. The problem was caused by the condition `Line.InPPDirective && (!Left->Previous || !Left->Previous->is(tok::identifier))) {` being matched and therefore not performing the checks for "previous token is one of decltype/_Atomic/etc.". This patch moves those checks after the existing if/else chain to ensure the left-parent token classification is always run after checking whether the contents of the parens is an expression or not. This change also introduces a new TokenAnnotatorTest that checks the token kind and Role of Tokens after analyzing them. This is used to check for TT_PointerOrReference, in addition to indirectly testing this based on the resulting formatting. Reviewed By: MyDeveloperDay Differential Revision: https://reviews.llvm.org/D88956
2020-10-27 10:05:55 +00:00
} // namespace
} // namespace format
} // namespace clang
Reference in New Issue Copy Permalink