aboutsummaryrefslogtreecommitdiff
path: root/clang/unittests/AST/StructuralEquivalenceTest.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-08-09[clang] Improve nested name specifier AST representation (#147835)Matheus Izvekov1-6/+9
This is a major change on how we represent nested name qualifications in the AST. * The nested name specifier itself and how it's stored is changed. The prefixes for types are handled within the type hierarchy, which makes canonicalization for them super cheap, no memory allocation required. Also translating a type into nested name specifier form becomes a no-op. An identifier is stored as a DependentNameType. The nested name specifier gains a lightweight handle class, to be used instead of passing around pointers, which is similar to what is implemented for TemplateName. There is still one free bit available, and this handle can be used within a PointerUnion and PointerIntPair, which should keep bit-packing aficionados happy. * The ElaboratedType node is removed, all type nodes in which it could previously apply to can now store the elaborated keyword and name qualifier, tail allocating when present. * TagTypes can now point to the exact declaration found when producing these, as opposed to the previous situation of there only existing one TagType per entity. This increases the amount of type sugar retained, and can have several applications, for example in tracking module ownership, and other tools which care about source file origins, such as IWYU. These TagTypes are lazily allocated, in order to limit the increase in AST size. This patch offers a great performance benefit. It greatly improves compilation time for [stdexec](https://github.com/NVIDIA/stdexec). For one datapoint, for `test_on2.cpp` in that project, which is the slowest compiling test, this patch improves `-c` compilation time by about 7.2%, with the `-fsyntax-only` improvement being at ~12%. This has great results on compile-time-tracker as well: ![image](https://github.com/user-attachments/assets/700dce98-2cab-4aa8-97d1-b038c0bee831) This patch also further enables other optimziations in the future, and will reduce the performance impact of template specialization resugaring when that lands. It has some other miscelaneous drive-by fixes. About the review: Yes the patch is huge, sorry about that. Part of the reason is that I started by the nested name specifier part, before the ElaboratedType part, but that had a huge performance downside, as ElaboratedType is a big performance hog. I didn't have the steam to go back and change the patch after the fact. There is also a lot of internal API changes, and it made sense to remove ElaboratedType in one go, versus removing it from one type at a time, as that would present much more churn to the users. Also, the nested name specifier having a different API avoids missing changes related to how prefixes work now, which could make existing code compile but not work. How to review: The important changes are all in `clang/include/clang/AST` and `clang/lib/AST`, with also important changes in `clang/lib/Sema/TreeTransform.h`. The rest and bulk of the changes are mostly consequences of the changes in API. PS: TagType::getDecl is renamed to `getOriginalDecl` in this patch, just for easier to rebasing. I plan to rename it back after this lands. Fixes #136624 Fixes https://github.com/llvm/llvm-project/issues/43179 Fixes https://github.com/llvm/llvm-project/issues/68670 Fixes https://github.com/llvm/llvm-project/issues/92757
2025-05-02[C23] Implement WG14 N3037 (#132939)Aaron Ballman1-32/+58
This changes the type compatibility rules so that it is permitted to redefine tag types within the same TU so long as they are equivalent definitions. It is intentionally not being exposed as an extension in older C language modes. GCC does not do so and the feature doesn't seem compelling enough to warrant it.
2024-11-13[clang][AST] Add 'IgnoreTemplateParmDepth' to structural equivalence cache ↵Balázs Kéri1-7/+81
(#115518) Structural equivalence check uses a cache to store already found non-equivalent values. This cache can be reused for calls (ASTImporter does this). Value of "IgnoreTemplateParmDepth" can have an effect on the structural equivalence therefore it is wrong to reuse the same cache for checks with different values of 'IgnoreTemplateParmDepth'. The current change adds the 'IgnoreTemplateParmDepth' to the cache key to fix the problem.
2024-07-26[clang][ASTImporter][NFC] add unittests for unnamed EnumDecl (#100545)Ding Fei1-0/+14
These tests are for multiple anonymous EnumDecls structural eq test & importing. We found the anonymous enums importing issue a few days ago and tried to fix it but 0a6233a68c7b575d05bca0f0c708b7e97cc710d1 already did this. I think these tests are still useful for regressions.
2024-06-12[StructuralEquivalence] improve NTTP and CXXDependentScopeMemberExpr ↵Qizhi Hu1-2/+55
comparison (#95190) improve `ASTStructuralEquivalenceTest`: 1. compare the depth and index of NTTP 2. provide comparison of `CXXDependentScopeMemberExpr` to `StmtCompare`. Co-authored-by: huqizhi <836744285@qq.com>
2024-01-18[clang][ASTImporter] Improve structural equivalence of overloadable ↵Balázs Kéri1-0/+170
operators. (#72242) Operators that are overloadable may be parsed as `CXXOperatorCallExpr` or as `UnaryOperator` (or `BinaryOperator`). This depends on the context and can be different if a similar construct is imported into an existing AST. The two "forms" of the operator call AST nodes should be detected as equivalent to allow AST import of these cases. This fix has probably other consequences because if a structure is imported that has `CXXOperatorCallExpr` into an AST with an existing similar structure that has `UnaryOperator` (or binary), the additional data in the `CXXOperatorCallExpr` node is lost at the import (because the existing node will be used). I am not sure if this can cause problems.
2024-01-05[clang][ASTImporter][StructuralEquivalence] improve StructuralEquivalence on ↵Qizhi Hu1-0/+23
recordType (#76226) Types comparison in `StructuralEquivalence` ignores its `DeclContext` when they are generated by template specialization implicitly and this will produce incorrect result. Add comparison of `DeclContext` of ClassTemplateSpecializationDecl to improve result. fix [issue](https://github.com/llvm/llvm-project/issues/65913) Co-authored-by: huqizhi <836744285@qq.com>
2023-09-21[clang][AST] fix lack comparison of declRefExpr in ASTStructuralEquivalence ↵Sunrise1-0/+9
(#66041) Fixed #66047 Before fix,the following testcase expected true. ```cpp TEST_F(StructuralEquivalenceStmtTest, DeclRefENoEq) { std::string Prefix = "enum Test { AAA, BBB };"; auto t = makeStmts( Prefix + "void foo(int i) {if (i > 0) {i = AAA;} else {i = BBB;}}", Prefix + "void foo(int i) {if (i > 0) {i = BBB;} else {i = AAA;}}", Lang_CXX03, ifStmt()); EXPECT_FALSE(testStructuralMatch(t)); // EXPECT_TRUE } ```
2023-09-21[clang][AST][ASTImporter] improve AST comparasion on VarDecl & GotoStmt (#66976)Qizhi Hu1-2/+75
improve AST comparasion on VarDecl & GotoStmt: 1. VarDecl should not be ignored, 2. GotoStmt has no children, it should be handle explicitly. Reviewed By: donat.nagy Differential Revision: https://reviews.llvm.org/D159519 Co-authored-by: huqizhi <836744285@qq.com>
2023-09-08[ASTImport]CXXBoolLiteralExpr should be handled explicitly in statement ↵huqizhi1-0/+19
comparation In the comparation of return statement, return value(if it is CXXBoolLiteralExpr) should be handled explicitly, otherwise an incorrect result would be returned. Reviewed By: steakhal, donat.nagy Differential Revision: https://reviews.llvm.org/D159479
2023-08-22[clang][ASTImporter]Skip check depth of friend template parameterhuqizhi1-7/+48
Depth of the parameter of friend template class declaration in a template class is 1, while in the specialization the depth is 0. This will cause failure on 'IsStructurallyEquivalent' as a name conflict in 'VisitClassTemplateDecl'(see testcase of 'SkipComparingFriendTemplateDepth'). The patch fix it by ignore the depth only in this special case. Reviewed By: balazske Differential Revision: https://reviews.llvm.org/D156693
2023-08-11[ASTImporter][NFC] Fix typo in testcasedingfei1-2/+2
Differential Revision: https://reviews.llvm.org/D157637
2023-06-09[ASTStructuralEquivalence] Fix crash when ObjCCategoryDecl doesn't have ↵Volodymyr Sapsai1-0/+12
corresponding ObjCInterfaceDecl. When this happens, it is invalid code and there is diagnostic ``` error: cannot find interface declaration for '...' ``` But clang shouldn't crash even if code is invalid. Though subsequent diagnostic can be imperfect because without ObjCInterfaceDecl we don't have a type for error messages. rdar://108818430 Differential Revision: https://reviews.llvm.org/D151523
2023-02-10[NFC][TargetParser] Replace uses of llvm/Support/Host.hArchibald Elliott1-1/+1
The forwarding header is left in place because of its use in `polly/lib/External/isl/interface/extract_interface.cc`, but I have added a GCC warning about the fact it is deprecated, because it is used in `isl` from where it is included by Polly.
2023-01-26[unittests] Use GTEST_SKIP() instead of return when appropriatePaul Robinson1-2/+2
Basically NFC: A TEST/TEST_F/etc that bails out early (usually because setup failed or some other runtime condition wasn't met) generally should use GTEST_SKIP() to report its status correctly, unless it takes steps to report another status (e.g., FAIL()).
2022-12-21[clang][AST] Compare UnresolvedLookupExpr in structural equivalence.Balázs Kéri1-0/+123
Reviewed By: gamesh411 Differential Revision: https://reviews.llvm.org/D136848
2022-08-01Fixed a number of typosGabriel Ravier1-1/+1
I went over the output of the following mess of a command: (ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel --xargs -0 cat | aspell list --mode=none --ignore-case | grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less) and proceeded to spend a few days looking at it to find probable typos and fixed a few hundred of them in all of the llvm project (note, the ones I found are not anywhere near all of them, but it seems like a good start). Differential Revision: https://reviews.llvm.org/D130827
2022-04-22[ASTStructuralEquivalence] Add support for comparing ObjCCategoryDecl.Volodymyr Sapsai1-0/+181
Differential Revision: https://reviews.llvm.org/D121176
2021-11-26[clang][AST] Check context of record in structural equivalence.Balázs Kéri1-0/+122
The AST structural equivalence check did not differentiate between a struct and a struct with same name in different namespace. When type of a member is checked it is possible to encounter such a case and wrongly decide that the types are similar. This problem is fixed by check for the namespaces of a record declaration. Reviewed By: martong Differential Revision: https://reviews.llvm.org/D113118
2021-11-25Revert "[clang][AST] Check context of record in structural equivalence."Balázs Kéri1-130/+0
Revert commit 6b96b2a0bf65ff838d4dbf909a5120d4d1083e29 because Windows test failure.
2021-11-24[clang][AST] Check context of record in structural equivalence.Balázs Kéri1-0/+130
The AST structural equivalence check did not differentiate between a struct and a struct with same name in different namespace. When type of a member is checked it is possible to encounter such a case and wrongly decide that the types are similar. This problem is fixed by check for the namespaces of a record declaration. Reviewed By: martong Differential Revision: https://reviews.llvm.org/D113118
2021-10-30[ASTImporter] Remove ASTNodeImporter::IsStructuralMatch overload for ↵Raphael Isemann1-0/+42
EnumConstantDecl 1. Moves the check to ASTStructuralEquivalence.cpp like all the other checks. 2. Adds the missing checks for identifier and init expression. Also add the respective tests for that stuff. Reviewed By: martong Differential Revision: https://reviews.llvm.org/D112804
2020-12-16[ASTImporter] Add support for importing GenericSelectionExpr AST nodes.Tom Roeder1-0/+66
This allows ASTs to be merged when they contain GenericSelectionExpr nodes (this is _Generic from C11). This is needed, for example, for CTU analysis of C code that makes use of _Generic, like the Linux kernel. The node is already supported in the AST, but it didn't have a matcher in ASTMatchers. So, this change adds the matcher and adds support to ASTImporter. Additionally, this change adds support for structural equivalence of _Generic in the AST. Reviewed By: martong, aaron.ballman Differential Revision: https://reviews.llvm.org/D92600
2020-10-05[ASTImporter][AST] Fix structural equivalency crash on dependent FieldDeclGabor Marton1-0/+33
Differential Revision: https://reviews.llvm.org/D88665
2020-09-21[ASTImporter] Refactor IsStructurallyEquivalent's Decl overloads to be more ↵Raphael Isemann1-0/+16
consistent There are several `::IsStructurallyEquivalent` overloads for Decl subclasses that are used for comparing declarations. There is also one overload that takes just two Decl pointers which ends up queuing the passed Decls to be later compared in `CheckKindSpecificEquivalence`. `CheckKindSpecificEquivalence` implements the dispatch logic for the different Decl subclasses. It is supposed to hand over the queued Decls to the subclass-specific `::IsStructurallyEquivalent` overload that will actually compare the Decl instance. It also seems to implement a few pieces of actual node comparison logic inbetween the dispatch code. This implementation causes that the different overloads of `::IsStructurallyEquivalent` do different (and sometimes no) comparisons depending on which overload of `::IsStructurallyEquivalent` ends up being called. For example, if I want to compare two FieldDecl instances, then I could either call the `::IsStructurallyEquivalent` with `Decl *` or with `FieldDecl *` parameters. The overload that takes FieldDecls is doing a correct comparison. However, the `Decl *` overload just queues the Decl pair. `CheckKindSpecificEquivalence` has no dispatch logic for `FieldDecl`, so it always returns true and never does any actual comparison. On the other hand, if I try to compare two FunctionDecl instances the two possible overloads of `::IsStructurallyEquivalent` have the opposite behaviour: The overload that takes `FunctionDecl` pointers isn't comparing the names of the FunctionDecls while the overload taking a plain `Decl` ends up comparing the function names (as the comparison logic for that is implemented in `CheckKindSpecificEquivalence`). This patch tries to make this set of functions more consistent by making `CheckKindSpecificEquivalence` a pure dispatch function without any subclass-specific comparison logic. Also the dispatch logic is now autogenerated so it can no longer miss certain subclasses. The comparison code from `CheckKindSpecificEquivalence` is moved to the respective `::IsStructurallyEquivalent` overload so that the comparison result no longer depends if one calls the `Decl *` overload or the overload for the specific subclass. The only difference is now that the `Decl *` overload is queuing the parameter while the subclass-specific overload is directly doing the comparison. `::IsStructurallyEquivalent` is an implementation detail and I don't think the behaviour causes any bugs in the current implementation (as carefully calling the right overload for the different classes works around the issue), so the test for this change is that I added some new code for comparing `MemberExpr`. The new comparison code always calls the dispatching overload and it previously failed as the dispatch didn't support FieldDecls. Reviewed By: martong, a_sidorin Differential Revision: https://reviews.llvm.org/D87619
2020-09-13[ASTImporter] Add basic support for comparing Stmts and compare function bodiesRaphael Isemann1-16/+306
Right now the ASTImporter assumes for most Expr nodes that they are always equal which leads to non-compatible declarations ending up being merged. This patch adds the basic framework for comparing Stmts (and with that also Exprs) and implements the custom checks for a few Stmt subclasses. I'll implement the remaining subclasses in follow up patches (mostly because there are a lot of subclasses and some of them require further changes like having GNU language in the testing framework) The motivation for this is that in LLDB we try to import libc++ source code and some of the types we are importing there contain expressions (e.g. because they use `enable_if<expr>`), so those declarations are currently merged even if they are completely different (e.g. `enable_if<value> ...` and `enable_if<!value> ...` are currently considered equal which is clearly not true). Reviewed By: martong, balazske Differential Revision: https://reviews.llvm.org/D87444
2020-07-07[ASTImporter] Corrected import of repeated friend declarations.Balázs Kéri1-0/+21
Summary: Import declarations in correct order if a class contains multiple redundant friend (type or decl) declarations. If the order is incorrect this could cause false structural equivalences and wrong declaration chains after import. Reviewers: a.sidorin, shafik, a_sidorin Reviewed By: shafik Subscribers: dkrupp, Szelethus, gamesh411, teemperor, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D75740
2020-06-02Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20Dmitri Gribenko1-156/+111
Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-05-29Move unittest helpers to a shared locationDmitri Gribenko1-1/+1
Summary: unittests/AST/Language.h defines some helpers that we would like to reuse in other tests, for example, in tests for syntax trees. Reviewers: sammccall Reviewed By: sammccall Subscribers: mgorny, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D80792
2020-05-29Rename APIs in unittests/AST/Language.h in preparation to share themDmitri Gribenko1-13/+15
Summary: Declaring these helpers in the ast_matcher namespace in the clangAST unit test seems inappropriate -- neither these helpers, nor clangAST have anything to do with AST matchers. Therefore, I moved these helpers to the clang namespace. Declaring another typedef called "ArgVector" is not a good idea -- we already have both "ArgVector", "ArgsVector", and "ArgList". I expanded it into the underlying type. Declaring another enum called "Language" is not a good idea because we arleady have the "clang::Language" enum. I renamed it to "TestLanguage". Similarly, I renamed "getBasicRunOptionsForLanguage" to "getCommandLineArgsForTesting" to explain the semantics better (what are "run options"?) and not repeat types in the function name ("ForLanguage"). Reviewers: shafik, rengolin, sammccall Reviewed By: sammccall Subscribers: gribozavr2, sammccall, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D80786
2020-03-11Remove unused Endian.h includes, NFCReid Kleckner1-1/+2
Mainly avoids including Host.h everywhere: $ diff -u <(sort thedeps-before.txt) <(sort thedeps-after.txt) \ | grep '^[-+] ' | sort | uniq -c | sort -nr 3141 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/Host.h
2019-09-02[AST] AST structural equivalence to work internally with pairs.Balazs Keri1-0/+122
Summary: The structural equivalence check stores now pairs of nodes in the 'from' and 'to' context instead of only the node in 'from' context and a corresponding one in 'to' context. This is needed to handle cases when a Decl in the 'from' context is to be compared with multiple Decls in the 'to' context. Reviewers: martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66538 llvm-svn: 370639
2019-07-23[ASTImporter] Fix inequivalence of ClassTemplateInstantiationsGabor Marton1-0/+192
Summary: We falsely state inequivalence if the template parameter is a qualified/nonquialified template in the first/second instantiation. Also, different kinds of TemplateName should be equal if the template decl (if available) is equal (even if the name kind is different). Reviewers: a_sidorin, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64241 llvm-svn: 366818
2019-07-17[ASTImporter] Fix structural eq of lambdasGabor Marton1-0/+52
Summary: The structural equivalence check reported false eq between lambda classes with different parameters in their call signature. The solution is to check the methods for equality too in case of lambda classes. Reviewers: a_sidorin, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64075 llvm-svn: 366332
2019-07-02[ASTImporter] Structural eq: handle DependentScopeDeclRefExprGabor Marton1-0/+138
Summary: Structural equivalence did not handle dependent template args properly when the arg contained a DependentScopeDeclRefExpr. Reviewers: a_sidorin, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62329 llvm-svn: 364889
2019-05-20[ASTImporter] Enable disabled but passing testsGabor Marton1-2/+1
Reviewers: a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62066 llvm-svn: 361139
2019-05-09[c++20] Add support for explicit(bool), as described in P0892R2.Richard Smith1-0/+40
Patch by Tyker! Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360311
2019-05-06Revert r359949 "[clang] adding explicit(bool) from c++2a"Hans Wennborg1-40/+0
This caused Clang to start erroring on the following: struct S {   template <typename = int> explicit S(); }; struct T : S {}; struct U : T {   U(); }; U::U() {} $ clang -c /tmp/x.cc /tmp/x.cc:10:4: error: call to implicitly-deleted default constructor of 'T' U::U() {}    ^ /tmp/x.cc:5:12: note: default constructor of 'T' is implicitly deleted because base class 'S' has no default constructor struct T : S {};            ^ 1 error generated. See discussion on the cfe-commits email thread. This also reverts the follow-ups r359966 and r359968. > this patch adds support for the explicit bool specifier. > > Changes: > - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. > - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. > - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. > - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. > - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. > - Test for Semantic and Serialization were added. > > This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. > Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. > > Patch by Tyker > > Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360024
2019-05-04[clang] adding explicit(bool) from c++2aNicolas Lesser1-0/+40
this patch adds support for the explicit bool specifier. Changes: - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. - Test for Semantic and Serialization were added. This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. Patch by Tyker Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 359949
2019-02-08[AST] Fix structural inequivalence of operatorsGabor Marton1-0/+27
Summary: Operators kind was not checked, so we reported e.g. op- to be equal with op+ Reviewers: shafik, a_sidorin, aaron.ballman Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57902 llvm-svn: 353504
2019-02-02[ASTImporter] Fix up test that only works on X86.David Green1-3/+7
The test will fail if the default target triple is not X86, even if the host platform is. So move the check into the test at runtime. llvm-svn: 352956
2019-01-28[AST] Add structural eq tests for template argsGabor Marton1-0/+19
Summary: New tests added to verify equivalency of templates when their parameters are different. Reviewers: a_sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Differential Revision: https://reviews.llvm.org/D57235 llvm-svn: 352345
2019-01-24Fix failing buildbotsGabor Marton1-2/+2
Fix remaining unittest errors caused by __attribute__((no_caller_saved_registers)) Related commit which caused the buildbots to fail: rL352050 llvm-svn: 352060
2019-01-24Fix failing buildbotsGabor Marton1-1/+4
Related commit which caused the buildbots to fail: rL352050 llvm-svn: 352055
2019-01-24[ASTImporter] Fix inequality of functions with different attributesGabor Marton1-0/+25
Summary: FunctionType::ExtInfo holds such properties of a function which are needed mostly for code gen. We should not compare these bits when checking for structural equivalency. Checking ExtInfo caused false ODR errors during CTU analysis (of tmux). Reviewers: a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, cfe-commits Differential Revision: https://reviews.llvm.org/D53699 llvm-svn: 352050
2018-12-17[ASTImporter] Fix redecl chain of classes and class templatesGabor Marton1-0/+71
Summary: The crux of the issue that is being fixed is that lookup could not find previous decls of a friend class. The solution involves making the friend declarations visible in their decl context (i.e. adding them to the lookup table). Also, we simplify `VisitRecordDecl` greatly. This fix involves two other repairs (without these the unittests fail): (1) We could not handle the addition of injected class types properly when a redecl chain was involved, now this is fixed. (2) DeclContext::removeDecl failed if the lookup table in Vector form did not contain the to be removed element. This caused troubles in ASTImporter::ImportDeclContext. This is also fixed. Reviewers: a_sidorin, balazske, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, cfe-commits Differential Revision: https://reviews.llvm.org/D53655 llvm-svn: 349349
2018-08-09Fix structural inequivalency of forward EnumDeclGabor Marton1-0/+54
Summary: Currently we consider one forward declared RecordDecl and another with a definition equal. We have to do the same in case of enums. Reviewers: a_sidorin, r.stahl, xazax.hun Subscribers: rnkovacs, dkrupp, cfe-commits Differential Revision: https://reviews.llvm.org/D50444 llvm-svn: 339336
2018-08-08[AST] Check described template at structural equivalence check.Balazs Keri1-5/+28
Summary: When checking a class or function the described class or function template is checked too. Split StructuralEquivalenceContext::Finish into multiple functions. Improved test with symmetric check, added new tests. Reviewers: martong, a.sidorin, a_sidorin, bruno Reviewed By: martong, a.sidorin Subscribers: rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D49223 llvm-svn: 339256
2018-07-17[ASTImporter] Fix poisonous structural equivalence cacheGabor Marton1-1/+1
Summary: Implementation functions call into the member functions of ASTStructuralEquivalence, thus they can falsely alter the DeclsToCheck state (they add decls). This results that some leaf declarations can be stated as inequivalent as a side effect of one inequivalent element in the DeclsToCheck list. And since we store the non-equivalencies, any (otherwise independent) decls will be rendered as non-equivalent. Solution: I tried to clearly separate the implementation functions (the static ones) and the public interface. From now on, the implementation functions do not call any public member functions, only other implementation functions. Reviewers: a.sidorin, a_sidorin, r.stahl Subscribers: rnkovacs, dkrupp, cfe-commits Differential Revision: https://reviews.llvm.org/D49300 llvm-svn: 337275
2018-07-17[ASTImporter] Fix import of unnamed structsGabor Marton1-2/+86
Summary: D48773 simplified ASTImporter nicely, but it introduced a new error: Unnamed structs are not imported correctly, if they appear in a recursive context. This patch provides a fix for structural equivalency. Reviewers: a.sidorin, a_sidorin, balazske, gerazo Subscribers: rnkovacs, dkrupp, cfe-commits Differential Revision: https://reviews.llvm.org/D49296 llvm-svn: 337267