summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST
Commit message (Collapse)AuthorAgeFilesLines
...
* [c++20] P1327R1: Support for typeid applied to objects of polymorphicRichard Smith2019-05-171-6/+22
| | | | | | class type in constant evaluation. llvm-svn: 360977
* Refactor constant evaluation of typeid(T) to track a symbolic type_infoRichard Smith2019-05-172-12/+94
| | | | | | | | | | object rather than tracking the originating expression. This is groundwork for supporting polymorphic typeid expressions. (Note that this somewhat regresses our support for DR1968, but it turns out that that never actually worked anyway, at least in non-trivial cases.) llvm-svn: 360974
* Implement __builtin_LINE() et. al. to support source location capture.Eric Fiselier2019-05-169-9/+169
| | | | | | | | | | | | | | | | | Summary: This patch implements the source location builtins `__builtin_LINE(), `__builtin_FUNCTION()`, `__builtin_FILE()` and `__builtin_COLUMN()`. These builtins are needed to implement [`std::experimental::source_location`](https://rawgit.com/cplusplus/fundamentals-ts/v2/main.html#reflection.src_loc.creation). With the exception of `__builtin_COLUMN`, GCC also implements these builtins, and Clangs behavior is intended to match as closely as possible. Reviewers: rsmith, joerg, aaron.ballman, bogner, majnemer, shafik, martong Reviewed By: rsmith Subscribers: rnkovacs, loskutov, riccibruno, mgorny, kunitoki, alexr, majnemer, hfinkel, cfe-commits Differential Revision: https://reviews.llvm.org/D37035 llvm-svn: 360937
* [builtin] Fixed definitions of builtins that rely on the int/long long type ↵Karl-Johan Karlsson2019-05-161-6/+27
| | | | | | | | | | | | | | | | | | | | | | is 32/64 bits Summary: The definition of the builtins __builtin_bswap32, __builtin_bitreverse32, __builtin_rotateleft32 and __builtin_rotateright32 rely on that the int type is 32 bits wide on the target. The defintions of the builtins __builtin_bswap64, __builtin_bitreverse64, __builtin_rotateleft64, and __builtin_rotateright64 rely on that the long long type is 64 bits wide. On targets where this is not the case (e.g. AVR) clang will generate faulty code (wrong llvm assembler intrinsics). This patch add support for using 'Z' (the int32_t type) in Bultins.def. The builtins above are changed to be based on the int32_t type instead of the int type, and the int64_t type instead of the long long type. The AVR backend (experimental) have a native int type that is only 16 bits wide. The supplied testcase will therefore fail if running the testcase on trunk as clang will convert e.g. __builtin_bitreverse32 into llvm.bitreverse.i16 on AVR. Reviewers: dylanmckay, spatel, rsmith, efriedma Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D61845 llvm-svn: 360863
* [c++20] For P1327R1: support dynamic_cast in constant expressionRichard Smith2019-05-151-54/+199
| | | | | | evaluation. llvm-svn: 360806
* [ASTImporter] Use llvm::Expected and Error in the importer APIGabor Marton2019-05-152-213/+84
| | | | | | | | | | | | | | | | | | | | | | Summary: This is the final phase of the refactoring towards using llvm::Expected and llvm::Error in the ASTImporter API. This involves the following: - remove old Import functions which returned with a pointer, - use the Import_New functions (which return with Err or Expected) everywhere and handle their return value - rename Import_New functions to Import This affects both Clang and LLDB. Reviewers: shafik, teemperor, aprantl, a_sidorin, balazske, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits, lldb-commits Tags: #clang, #lldb Differential Revision: https://reviews.llvm.org/D61438 llvm-svn: 360760
* Make getObjCEncodingForTypeImpl() take a bitmask instead of 8 boolsNico Weber2019-05-141-106/+78
| | | | | | | | | | | Slightly easier to read, uses slightly less stack space, and makes it impossible to mix up the order of all those bools. No behavior change. Differential Revision: https://reviews.llvm.org/D61788 llvm-svn: 360668
* Revert r360637 "PR41817: Fix regression in r359260 that caused the MS ↵Hans Wennborg2019-05-141-35/+6
| | | | | | | | | | | | compatibility" > extension allowing a "static" declaration to follow an "extern" > declaration to stop working. It introduced asserts for some "static-following-extern" cases, breaking the Chromium build. See the cfe-commits thread for reproducer. llvm-svn: 360657
* PR41817: Fix regression in r359260 that caused the MS compatibilityRichard Smith2019-05-141-6/+35
| | | | | | | extension allowing a "static" declaration to follow an "extern" declaration to stop working. llvm-svn: 360637
* [c++20] P1064R0: Allow virtual function calls in constant expressionRichard Smith2019-05-132-24/+231
| | | | | | | | | | | | | evaluation. This reinstates r360559, reverted in r360580, with a fix to avoid crashing if evaluation-for-overflow mode encounters a virtual call on an object of a class with a virtual base class, and to generally not try to resolve virtual function calls to objects whose (notional) vptrs are not readable. (The standard rules are unclear here, but this seems like a reasonable approach.) llvm-svn: 360635
* Introduce the ability to dump the AST to JSON.Aaron Ballman2019-05-133-5/+796
| | | | | | This adds the -ast-dump=json cc1 flag (in addition to -ast-dump=default, which is the default if no dump format is specified), as well as some initial AST dumping functionality and tests. llvm-svn: 360622
* [clang][ASTContext] Call setAttached for comments attached to a declarationJan Korous2019-05-131-0/+2
| | | | | | | | | | | This is a bug affecting performance when compiling with -Wdocumentation. In Sema::ActOnDocumentable we're checking whether there are any comments unattached to declaration at the end of comment list whenever we encounter new documentable declaration. Since this property of RawComment was never set we were trying to find comments every time and that involves at least a couple expensive SourceLocation decompositions. Differential Revision: https://reviews.llvm.org/D61538 llvm-svn: 360607
* Revert r360559 "[c++20] P1064R0: Allow virtual function calls in constant ↵Hans Wennborg2019-05-132-218/+23
| | | | | | | | | expression evaluation." This caused Chromium builds to hit the new "can't handle virtual calls with virtual bases" assert. Reduced repro coming up. llvm-svn: 360580
* PR41854: Don't assert when constant-evaluating a member function call on an ↵Richard Smith2019-05-131-0/+3
| | | | | | invalid designator. llvm-svn: 360560
* [c++20] P1064R0: Allow virtual function calls in constant expressionRichard Smith2019-05-132-23/+218
| | | | | | evaluation. llvm-svn: 360559
* Reject attempts to call non-static member functions on objects outsideRichard Smith2019-05-121-33/+122
| | | | | | | | | | | | | | | | their lifetime in constant expressions. This is undefined behavior per [class.cdtor]p2. We continue to allow this for objects whose values are not visible within the constant evaluation, because there's no way we can tell whether the access is defined or not, existing code relies on the ability to make such calls, and every other compiler allows such calls. This reinstates r360499, reverted in r360531. llvm-svn: 360538
* Fix handling of objects under construction during constant expressionRichard Smith2019-05-122-93/+161
| | | | | | | | | | | | | evaluation. It's not enough to just track the LValueBase that we're evaluating, we need to also track the path to the objects whose constructors are running. This reinstates r360464 (reverted in r360531) with a workaround for an MSVC bug that previously caused the Windows bots to fail. llvm-svn: 360537
* Revert rL360499 and rL360464 from cfe/trunk:Simon Pilgrim2019-05-112-275/+118
| | | | | | | | | | | | | | | | | | | | | | | | Reject attempts to call non-static member functions on objects outside their lifetime in constant expressions. This is undefined behavior per [class.cdtor]p2. We continue to allow this for objects whose values are not visible within the constant evaluation, because there's no way we can tell whether the access is defined or not, existing code relies on the ability to make such calls, and every other compiler allows such calls. ........ Fix handling of objects under construction during constant expression evaluation. It's not enough to just track the LValueBase that we're evaluating, we need to also track the path to the objects whose constructors are running. ........ Fixes windows buildbots llvm-svn: 360531
* Reject attempts to call non-static member functions on objects outsideRichard Smith2019-05-111-33/+122
| | | | | | | | | | | | | | their lifetime in constant expressions. This is undefined behavior per [class.cdtor]p2. We continue to allow this for objects whose values are not visible within the constant evaluation, because there's no way we can tell whether the access is defined or not, existing code relies on the ability to make such calls, and every other compiler allows such calls. llvm-svn: 360499
* Fix handling of objects under construction during constant expressionRichard Smith2019-05-102-93/+161
| | | | | | | | | | evaluation. It's not enough to just track the LValueBase that we're evaluating, we need to also track the path to the objects whose constructors are running. llvm-svn: 360464
* Improve interface of APValuePathEntry.Richard Smith2019-05-102-45/+27
| | | | llvm-svn: 360463
* Fix and test for assertion error in P41835.Leonard Chan2019-05-101-0/+6
| | | | llvm-svn: 360448
* Add name comments for bools passed to getObjCEncodingForTypeImpl()Nico Weber2019-05-101-52/+85
| | | | | | | | No behavior change. Medium term, probably want to use a bitmask instead of 8 distinct bool parameters, but let's make the call sites easier to read first. llvm-svn: 360427
* Delete write-only HasQualifiers after rC360370Fangrui Song2019-05-101-2/+0
| | | | llvm-svn: 360408
* Added an assert in `isConstantInitializer`: initializer lists must be in ↵Dmitri Gribenko2019-05-101-0/+1
| | | | | | | | | | | | semantic form Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61485 llvm-svn: 360406
* DR1872: don't allow any calls to virtual functions in constantRichard Smith2019-05-091-6/+8
| | | | | | | | evaluation. Not even in cases where we would not actually perform virtual dispatch. llvm-svn: 360370
* [c++20] Add support for explicit(bool), as described in P0892R2.Richard Smith2019-05-095-51/+115
| | | | | | | | Patch by Tyker! Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360311
* [c++20] Implement P0846R0: allow (ADL-only) calls to template-ids whoseRichard Smith2019-05-096-2/+46
| | | | | | | | | | | | | | | | | | | | | | | | | template name is not visible to unqualified lookup. In order to support this without a severe degradation in our ability to diagnose typos in template names, this change significantly restructures the way we handle template-id-shaped syntax for which lookup of the template name finds nothing. Instead of eagerly diagnosing an undeclared template name, we now form a placeholder template-name representing a name that is known to not find any templates. When the parser sees such a name, it attempts to disambiguate whether we have a less-than comparison or a template-id. Any diagnostics or typo-correction for the name are delayed until its point of use. The upshot should be a small improvement of our diagostic quality overall: we now take more syntactic context into account when trying to resolve an undeclared identifier on the left hand side of a '<'. In fact, this works well enough that the backwards-compatible portion (for an undeclared identifier rather than a lookup that finds functions but no function templates) is enabled in all language modes. llvm-svn: 360308
* [ASTImporter] Fix inequivalence of unresolved exception specGabor Marton2019-05-082-17/+36
| | | | | | | | | | | | | | | | | | Summary: Structural equivalence of methods can falsely report false when the exception specifier is unresolved (i.e unevaluated or not instantiated). (This caused one assertion during bitcoin ctu-analysis.) Reviewers: a_sidorin, shafik, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61424 llvm-svn: 360261
* [OpenCL] Prevent mangling kernel functions.Anastasia Stulova2019-05-071-0/+2
| | | | | | | | | | | | Kernel function names have to be preserved as in the original source to be able to access them from the host API side. This commit also adds restriction to kernels that prevents them from being used in overloading, templates, etc. Differential Revision: https://reviews.llvm.org/D60454 llvm-svn: 360152
* [ASTImporter] Import TemplateParameterLists in function templates.Balazs Keri2019-05-071-0/+21
| | | | | | | | | | | | | | | | Summary: Correct missing import of TemplateParameterList in function decl. Reviewers: martong, a.sidorin, shafik Reviewed By: martong Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60461 llvm-svn: 360132
* Recommit r359859 "[Attribute/Diagnostics] Print macro if definition is an ↵Leonard Chan2019-05-076-1/+66
| | | | | | | | attribute declaration" Updated with fix for read of uninitialized memory. llvm-svn: 360109
* Revert r359949 "[clang] adding explicit(bool) from c++2a"Hans Wennborg2019-05-065-115/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [c++20] Implement P1009R2: allow omitting the array bound in an arrayRichard Smith2019-05-063-15/+28
| | | | | | | | | | new expression. This was voted into C++20 as a defect report resolution, so we retroactively apply it to all prior language modes (though it can never actually be used before C++11 mode). llvm-svn: 360006
* [clang] fixing -ast-print for variadic parameter pack in lambda captureNicolas Lesser2019-05-051-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: currently for: ``` template<typename ... T> void f(T... t) { auto l = [t...]{}; } ``` `clang -ast-print file.cpp` outputs: ``` template <typename ...T> void f(T ...t) { auto l = [t] { } ; } ``` notice that there is not `...` in the capture list of the lambda. this patch fixes this issue. and add test for it. Patch by Tyker Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61556 llvm-svn: 359980
* [c++20] Implement P0428R2 - Familiar template syntax for generic lambdasHamza Sood2019-05-046-17/+101
| | | | | | Differential Revision: https://reviews.llvm.org/D36527 llvm-svn: 359967
* Reduce amount of work ODR hashing does.Richard Trieu2019-05-041-4/+26
| | | | | | | | | | | | | | | When a FunctionProtoType is in the original type in a DecayedType, the decayed type is a PointerType which points back the original FunctionProtoType. The visitor for ODRHashing will attempt to process both Type's, doing double work. By chaining together multiple DecayedType's and FunctionProtoType's, this would result in 2^N Type's visited only N DecayedType's and N FunctionProtoType's exsit. Another bug where VisitDecayedType and VisitAdjustedType did redundant work doubled the work at each level, giving 4^N Type's visited. This patch removed the double work and detects when a FunctionProtoType decays to itself to only check the Type once. This lowers the exponential runtime to linear runtime. Fixes https://bugs.llvm.org/show_bug.cgi?id=41625 llvm-svn: 359960
* Disallow the operand of __builtin_constant_p from modifying enclosingRichard Smith2019-05-041-15/+28
| | | | | | | | | | | | | | state when it's encountered while evaluating a constexpr function. We attempt to follow GCC trunk's behavior here, but it is somewhat inscrutible, so our behavior is only approximately the same for now. Specifically, we only permit modification of objects whose lifetime began within the operand of the __builtin_constant_p. GCC appears to have effectively the same restriction, but also some unknown restriction based on where and how the local state of the constexpr function is mentioned within the operand (see added testcases). llvm-svn: 359958
* [clang] adding explicit(bool) from c++2aNicolas Lesser2019-05-045-51/+115
| | | | | | | | | | | | | | | | | | | | | 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
* CWG issue 727: Fix numerous bugs in support for class-scope explicitRichard Smith2019-05-031-39/+63
| | | | | | specializations for variable templates. llvm-svn: 359947
* Remove else-after-returnDavid Blaikie2019-05-031-5/+4
| | | | llvm-svn: 359913
* Added an AST matcher for declarations that are in the `std` namespaceDmitri Gribenko2019-05-031-1/+2
| | | | | | | | | | | | Reviewers: alexfh Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61480 llvm-svn: 359876
* Revert "[Attribute/Diagnostics] Print macro if definition is an attribute ↵Leonard Chan2019-05-036-66/+1
| | | | | | | | declaration" This reverts commit fc40cbd9d8c63e65eed3590ba925321afe782e1d. llvm-svn: 359859
* SemaOverload: Complete candidates before emitting the error, to ensure ↵David Blaikie2019-05-031-0/+14
| | | | | | | | | | | | | | | | | diagnostics emitted (or suppressed) during completion don't interfere with the overload notes Because diagnostics and their notes are not connected at the API level, if the error message for an overload is emitted, then the overload candidates are completed - if a diagnostic is emitted during that work, the notes related to overload candidates would be attached to the latter diagnostic, not the original error. Sort of worse, if the latter diagnostic was disabled, the notes are disabled. Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D61357 llvm-svn: 359854
* Fix -Wunsequenced false-positives in code controlled by a branch onRichard Smith2019-05-021-3/+6
| | | | | | | | | | __builtin_constant_p. If the operand of __builtin_constant_p is not constant and has side-effects, then code controlled by a branch on it is unreachable and we should not emit runtime behavior warnings in such code. llvm-svn: 359844
* [Attribute/Diagnostics] Print macro if definition is an attribute declarationLeonard Chan2019-05-026-1/+66
| | | | | | | | | | | | | If an address_space attribute is defined in a macro, print the macro instead when diagnosing a warning or error for incompatible pointers with different address_spaces. We allow this for all attributes (not just address_space), and for multiple attributes declared in the same macro. Differential Revision: https://reviews.llvm.org/D51329 llvm-svn: 359826
* Replace ad-hoc tracking of pattern for an instantiated class-scopeRichard Smith2019-05-023-77/+85
| | | | | | | | | | explicit function specialization with the MemberSpecializationInfo used everywhere else. Not NFC: the ad-hoc pattern tracking was not being serialized / deserialized properly. That's fixed here. llvm-svn: 359747
* [COFF, ARM64] Align global symbol by size for ARM64 MSVC ABITom Tan2019-05-021-3/+6
| | | | | | | | | | | | | | | | | According to alignment section in below ARM64 ABI document, MSVC could increase alignment of global data based on its total size. Clang doesn't do this. Compile the same symbol into different alignments by Clang and MSVC could cause link error because some instruction encodings, like 64-bit LDR/STR with immediate, require the target to be 8 bytes aligned, and linker could choose code stream with such LDR/STR instruction from MSVC and 4 bytes aligned data from Clang into final image, which actually cannot be linked together (see https://bugs.llvm.org/show_bug.cgi?id=41506 for more details). https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2019#alignment Differential Revision: https://reviews.llvm.org/D61225 llvm-svn: 359744
* [NFC] typoJF Bastien2019-04-301-1/+1
| | | | llvm-svn: 359523
* [ASTImporter] Add an ImportImpl method to allow customizing Import behavior.Raphael Isemann2019-04-291-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We are currently implementing support in LLDB that reconstructs the STL templates from the target program in the expression evaluator. This reconstruction happens during the import process from our debug info AST into the expression evaluation AST, which means we need a way to intercept the ASTImporter import process. This patch adds an protected ImportImpl method that we can overwrite in LLDB to implement our special importing logic (which is essentially just looking into a C++ module that is attached to the target context). Because ImportImpl has to call MapImported/AddToLookup for the decls it creates, this patch also exposes those via a new unified method and checks that we call it when importing decls. Reviewers: martong, balazske, a.sidorin, shafik, a_sidorin Reviewed By: martong, a_sidorin Subscribers: rnkovacs, cfe-commits, lldb-commits, aprantl Tags: #clang Differential Revision: https://reviews.llvm.org/D59485 llvm-svn: 359502
OpenPOWER on IntegriCloud