summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/Decl.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Revert 9007f06af0e "Revert "Allow system header to provide their own ↵Hans Wennborg2020-01-171-0/+8
| | | | | | | implementation of some builtin"" This should no longer be necessary after cd4c65f91d5 "Add __warn_memset_zero_len builtin as a workaround for glibc issue"
* Revert "Allow system header to provide their own implementation of some builtin"Amy Huang2020-01-171-8/+0
| | | | | | | | | This reverts commit 921f871ac438175ca8fcfcafdfcfac4d7ddf3905 because it causes libc++ code to trigger __warn_memset_zero_len. See https://reviews.llvm.org/D71082. (cherry picked from commit 3d210ed3d1880c615776b07d1916edb400c245a6)
* Allow system header to provide their own implementation of some builtinserge-sans-paille2020-01-101-0/+8
| | | | | | | | | | | | | | | | | | If a system header provides an (inline) implementation of some of their function, clang still matches on the function name and generate the appropriate llvm builtin, e.g. memcpy. This behavior is in line with glibc recommendation « users may not provide their own version of symbols » but doesn't account for the fact that glibc itself can provide inline version of some functions. It is the case for the memcpy function when -D_FORTIFY_SOURCE=1 is on. In that case an inline version of memcpy calls __memcpy_chk, a function that performs extra runtime checks. Clang currently ignores the inline version and thus provides no runtime check. This code fixes the issue by detecting functions whose name is a builtin name but also have an inline implementation. Differential Revision: https://reviews.llvm.org/D71082
* Improve support of GNU mempcpyserge-sans-paille2020-01-091-0/+7
| | | | | | | - Lower to the memcpy intrinsic - Raise warnings when size/bounds are known Differential Revision: https://reviews.llvm.org/D71374
* [Concepts] Function trailing requires clausesSaar Raz2020-01-091-17/+26
| | | | | | Function trailing requires clauses now parsed, supported in overload resolution and when calling, referencing and taking the address of functions or function templates. Differential Revision: https://reviews.llvm.org/D43357
* Adds fixit hints to the -Wrange-loop-analysisMark de Wever2020-01-011-0/+6
| | | | Differential Revision: https://reviews.llvm.org/D68913
* [c++20] Fix handling of unqualified lookups from a defaulted comparisonRichard Smith2019-12-091-7/+36
| | | | | | | | | | function. We need to perform unqualified lookups from the context of a defaulted comparison, but not until we implicitly define the function, at which point we can't do those lookups any more. So perform the lookup from the end of the class containing the =default declaration and store the lookup results on the defaulted function until we synthesize the body.
* Remove Expr.h include from ASTContext.h, NFCReid Kleckner2019-12-061-1/+2
| | | | | | | ASTContext.h is popular, prune its includes. Expr.h brings in Attr.h, which is also expensive. Move BlockVarCopyInit to Expr.h to accomplish this.
* [Concepts] Constraint Enforcement & DiagnosticsSaar Raz2019-12-061-1/+1
| | | | | | | | | Part of the C++20 concepts implementation effort. - Associated constraints (requires clauses, currently) are now enforced when instantiating/specializing templates and when considering partial specializations and function overloads. - Elaborated diagnostics give helpful insight as to why the constraints were not satisfied. Phabricator: D41569 Re-commit, after fixing some memory bugs.
* Reapply af57dbf12e54 "Add support for options -frounding-math, ↵Melanie Blower2019-12-051-0/+1
| | | | | | | | | | | | ftrapping-math, -ffp-model=, and -ffp-exception-behavior=" Patch was reverted because https://bugs.llvm.org/show_bug.cgi?id=44048 The original patch is modified to set the strictfp IR attribute explicitly in CodeGen instead of as a side effect of IRBuilder. In the 2nd attempt to reapply there was a windows lit test fail, the tests were fixed to use wildcard matching. Differential Revision: https://reviews.llvm.org/D62731
* Revert " Reapply af57dbf12e54 "Add support for options ↵Melanie Blower2019-12-041-1/+0
| | | | | | | -frounding-math, ftrapping-math, -ffp-model=, and -ffp-exception-behavior="" This reverts commit cdbed2dd856c14687efd741c2d8321686102acb8. Build break on Windows (lit fail)
* Reapply af57dbf12e54 "Add support for options -frounding-math, ↵Melanie Blower2019-12-041-0/+1
| | | | | | | | | | ftrapping-math, -ffp-model=, and -ffp-exception-behavior=" Patch was reverted because https://bugs.llvm.org/show_bug.cgi?id=44048 The original patch is modified to set the strictfp IR attribute explicitly in CodeGen instead of as a side effect of IRBuilder Differential Revision: https://reviews.llvm.org/D62731
* Add FunctionDecl::getParameterSourceRange()Nicolas Manichon2019-12-031-0/+16
| | | | | This source range covers the list of parameters of the function declaration, including the ellipsis for a variadic function.
* [OPENMP]Fix PR41826: symbols visibility in device code.Alexey Bataev2019-11-251-0/+4
| | | | | | | | | | | | | | | | | | Summary: Currently, we ignore all locality attributes/info when building for the device and thus all symblos are externally visible and can be preemted at the runtime. It may lead to incorrect results. We need to follow the same logic, compiler uses for static/pie builds. But in some cases changing of dso locality may lead to problems with codegen, so instead mark external symbols as hidden instead in the device code. Reviewers: jdoerfert Subscribers: guansong, caomhin, kkwli0, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70549
* Revert "[Concepts] Constraint Enforcement & Diagnostics"Vlad Tsyrklevich2019-10-281-1/+1
| | | | | This reverts commit ffa214ef22892d75340dc6720271863901dc2c90, it was causing ASAN test failures on sanitizer-x86_64-linux-bootstrap.
* [Concepts] Constraint Enforcement & DiagnosticsSaar Raz2019-10-251-1/+1
| | | | | | Part of the C++20 concepts implementation effort. - Associated constraints (requires clauses, currently) are now enforced when instantiating/specializing templates and when considering partial specializations and function overloads. - Elaborated diagnostics give helpful insight as to why the constraints were not satisfied. Phabricator: D41569
* [clang] New __attribute__((__clang_arm_mve_alias)).Simon Tatham2019-10-241-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows you to declare a function with a name of your choice (say `foo`), but have clang treat it as if it were a builtin function (say `__builtin_foo`), by writing static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_foo))) int foo(args); I'm intending to use this for the ACLE intrinsics for MVE, which have to be polymorphic on their argument types and also need to be implemented by builtins. To avoid having to implement the polymorphism with several layers of nested _Generic and make error reporting hideous, I want to make all the user-facing intrinsics correspond directly to clang builtins, so that after clang resolves __attribute__((overloadable)) polymorphism it's already holding the right BuiltinID for the intrinsic it selected. However, this commit itself just introduces the new attribute, and doesn't use it for anything. To avoid unanticipated side effects if this attribute is used to make aliases to other builtins, there's a restriction mechanism: only (BuiltinID, alias) pairs that are approved by the function ArmMveAliasValid() will be permitted. At present, that function doesn't permit anything, because the Tablegen that will generate its list of valid pairs isn't yet implemented. So the only test of this facility is one that checks that an unapproved builtin _can't_ be aliased. Reviewers: dmgreen, miyuki, ostannard Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67159
* [c++2a] Allow comparison functions to be explicitly defaulted.Richard Smith2019-10-221-14/+9
| | | | | | This adds some initial syntactic checking that only the appropriate function signatures can be defaulted. No implicit definitions are generated yet.
* [hip][cuda] Fix the extended lambda name mangling issue.Michael Liao2019-10-191-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - HIP/CUDA host side needs to use device kernel symbol name to match the device side binaries. Without a consistent naming between host- and device-side compilations, it's risky that wrong device binaries are executed. Consistent naming is usually not an issue until unnamed types are used, especially the lambda. In this patch, the consistent name mangling is addressed for the extended lambdas, i.e. the lambdas annotated with `__device__`. - In [Itanium C++ ABI][1], the mangling of the lambda is generally unspecified unless, in certain cases, ODR rule is required to ensure consisent naming cross TUs. The extended lambda is such a case as its name may be part of a device kernel function, e.g., the extended lambda is used as a template argument and etc. Thus, we need to force ODR for extended lambdas as they are referenced in both device- and host-side TUs. Furthermore, if a extended lambda is nested in other (extended or not) lambdas, those lambdas are required to follow ODR naming as well. This patch revises the current lambda mangle numbering to force ODR from an extended lambda to all its parent lambdas. - On the other side, the aforementioned ODR naming should not change those lambdas' original linkages, i.e., we cannot replace the original `internal` with `linkonce_odr`; otherwise, we may violate ODR in general. This patch introduces a new field `HasKnownInternalLinkage` in lambda data to decouple the current linkage calculation based on mangling number assigned. [1]: https://itanium-cxx-abi.github.io/cxx-abi/abi.html Reviewers: tra, rsmith, yaxunl, martong, shafik Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68818 llvm-svn: 375309
* For P0784R7: compute whether a variable has constant destruction if itRichard Smith2019-09-291-0/+12
| | | | | | | | | | has a constexpr destructor. For constexpr variables, reject if the variable does not have constant destruction. In all cases, do not emit runtime calls to the destructor for variables with constant destruction. llvm-svn: 373159
* [clang] [AST] Treat "inline gnu_inline" the same way as "extern inline ↵Martin Storsjo2019-09-271-3/+5
| | | | | | | | | | | | | | | | | gnu_inline" in C++ mode This matches how GCC handles it, see e.g. https://gcc.godbolt.org/z/HPplnl. GCC documents the gnu_inline attribute with "In C++, this attribute does not depend on extern in any way, but it still requires the inline keyword to enable its special behavior." The previous behaviour of gnu_inline in C++, without the extern keyword, can be traced back to the original commit that added support for gnu_inline, SVN r69045. Differential Revision: https://reviews.llvm.org/D67414 llvm-svn: 373078
* For P0784R7: add support for new (std::nothrow).Richard Smith2019-09-271-2/+1
| | | | llvm-svn: 373037
* Re-land r372863: [AST] Extract Decl::printNestedNameSpecifier helper from ↵Ilya Biryukov2019-09-251-8/+19
| | | | | | | | | | Decl::printQualifiedName Reverted in r372880 due to the test failure. Also contains a fix that adjusts printQualifiedName to return the same results as before in case of anonymous function locals and parameters. llvm-svn: 372889
* Revert r372863: [AST] Extract Decl::printNestedNameSpecifier helper from ↵Ilya Biryukov2019-09-251-14/+8
| | | | | | | Decl::printQualifiedName Reason: causes a test failure, will investigate and re-land with a fix. llvm-svn: 372880
* [AST] Extract Decl::printNestedNameSpecifier helper from ↵Ilya Biryukov2019-09-251-8/+14
| | | | | | | | | | | | | | | | | | | | | Decl::printQualifiedName Summary: To be used in clangd, e.g. in D66647. Currently the alternative to this function is doing string manipulation on results of `printQualifiedName`, which is hard-to-impossible to get right in presence of template arguments. Reviewers: kadircet, aaron.ballman Reviewed By: kadircet, aaron.ballman Subscribers: aaron.ballman, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67825 llvm-svn: 372863
* [Clang][CodeGen] support alias attribute w/ gnu_inlineNick Desaulniers2019-09-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: r369705 did not consider the addition of gnu_inline on function declarations of alias attributed functions. This resulted in a reported regression in the clang-9-rc4 release from the Zig developers building glibc, which was observable as a failed assertion: llvm-project/clang/lib/AST/Decl.cpp:3336: bool clang::FunctionDecl::isInlineDefinitionExternallyVisible() const: Assertion `(doesThisDeclarationHaveABody() || willHaveBody()) && "Must be a function definition"' failed. Alias function declarations do not have bodies, so allow us to proceed if we have the alias function attribute but no body/definition, and add a test case. The emitted symbols and their linkage matches GCC for the added test case. Link: https://bugs.llvm.org/show_bug.cgi?id=43268 Reviewers: aaron.ballman, rsmith, erichkeane, andrewrk Reviewed By: andrewrk Subscribers: cfe-commits, andrewrk, hans, srhines Tags: #clang Differential Revision: https://reviews.llvm.org/D67455 llvm-svn: 371766
* [Sema] Diagnose default-initialization, destruction, and copying ofAkira Hatanaka2019-09-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | non-trivial C union types This recommits r365985, which was reverted because it broke a few projects using unions containing non-trivial ObjC pointer fields in system headers. We now have a patch to fix the problem (see https://reviews.llvm.org/D65256). Original commit message: This patch diagnoses uses of non-trivial C unions and structs/unions containing non-trivial C unions in the following contexts, which require default-initialization, destruction, or copying of the union objects, instead of disallowing fields of non-trivial types in C unions, which is what we currently do: - function parameters. - function returns. - assignments. - compound literals. - block captures except capturing of `__block` variables by non-escaping blocks. - local and global variable definitions. - lvalue-to-rvalue conversions of volatile types. See the discussion in https://reviews.llvm.org/D62988 for more background. rdar://problem/50679094 Differential Revision: https://reviews.llvm.org/D63753 llvm-svn: 371275
* [c++20] P1143R2: Add support for the C++20 'constinit' keyword.Richard Smith2019-09-041-0/+16
| | | | | | | | | | | | | This is mostly the same as the [[clang::require_constant_initialization]] attribute, but has a couple of additional syntactic and semantic restrictions. In passing, I added a warning for the attribute form being added after we have already seen the initialization of the variable (but before we see the definition); that case previously slipped between the cracks and the attribute was silently ignored. llvm-svn: 370972
* Revert "[Sema] Diagnose default-initialization, destruction, and copying of"Akira Hatanaka2019-07-261-3/+0
| | | | | | | | | | | | | | | This reverts commit r365985. Prior to r365985, clang used to mark C union fields that have non-trivial ObjC ownership qualifiers as unavailable if the union was declared in a system header. r365985 stopped doing so, which caused the swift compiler to crash when it tried to import a non-trivial union. I have a patch that fixes the crash (https://reviews.llvm.org/D65256), but I'm temporarily reverting the original patch until we can decide on whether it's taking the right approach. llvm-svn: 367076
* Initialize the non-trivial C union bits I added to RecordDeclBitfieldsAkira Hatanaka2019-07-131-0/+3
| | | | | | | | | | in r365985 These bits weren't being initialized in the RecordDecl's constructor, which probably caused test/Modules/stress1.cpp to fail on a couple of bots. llvm-svn: 365989
* P0840R2: support for [[no_unique_address]] attributeRichard Smith2019-06-201-0/+33
| | | | | | | | | | | | | | | | | Summary: Add support for the C++2a [[no_unique_address]] attribute for targets using the Itanium C++ ABI. This depends on D63371. Reviewers: rjmccall, aaron.ballman Subscribers: dschuff, aheejin, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63451 llvm-svn: 363976
* Fix crash when checking a dependently-typed reference that isRichard Smith2019-06-171-1/+1
| | | | | | initialized from a non-value-dependent initializer. llvm-svn: 363622
* [C++20] add Basic consteval specifierGauthier Harnisch2019-06-141-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: this revision adds Lexing, Parsing and Basic Semantic for the consteval specifier as specified by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1073r3.html with this patch, the consteval specifier is treated as constexpr but can only be applied to function declaration. Changes: - add the consteval keyword. - add parsing of consteval specifier for normal declarations and lambdas expressions. - add the whether a declaration is constexpr is now represented by and enum everywhere except for variable because they can't be consteval. - adapt diagnostic about constexpr to print constexpr or consteval depending on the case. - add tests for basic semantic. Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: eraman, efriedma, rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61790 llvm-svn: 363362
* For DR712: store on a DeclRefExpr whether it constitutes an odr-use.Richard Smith2019-06-111-1/+21
| | | | | | | Begin restructuring to support the forms of non-odr-use reference permitted by DR712. llvm-svn: 363086
* Refactor: split Uninitialized state on APValue into an "Absent" stateRichard Smith2019-05-211-1/+1
| | | | | | | representing no such object, and an "Indeterminate" state representing an uninitialized object. The latter is not yet used, but soon will be. llvm-svn: 361328
* [c++20] P0780R2: Support pack-expansion of init-captures.Richard Smith2019-05-211-4/+4
| | | | | | | | | | | This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
* 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] Add support for explicit(bool), as described in P0892R2.Richard Smith2019-05-091-1/+0
| | | | | | | | Patch by Tyker! Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360311
* [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
* Revert r359949 "[clang] adding explicit(bool) from c++2a"Hans Wennborg2019-05-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [clang] adding explicit(bool) from c++2aNicolas Lesser2019-05-041-1/+0
| | | | | | | | | | | | | | | | | | | | | 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
* Replace ad-hoc tracking of pattern for an instantiated class-scopeRichard Smith2019-05-021-45/+74
| | | | | | | | | | 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
* C++ DR2387: a variable template declared wtih (or instantiated with) aRichard Smith2019-04-261-30/+51
| | | | | | | | | const-qualified type is not implicitly given internal linkage. But a variable template declared 'static' is. This reinstates part of r359048, reverted in r359076. llvm-svn: 359260
* Revert r359048: C++ DR2387: a variable template declared wthiIlya Biryukov2019-04-241-51/+30
| | | | | | | | | | | | | The change breaks libc++ with the follwing error: In file included from valarray:4: .../include/c++/v1/valarray:1062:60: error: explicit instantiation declaration of 'valarray<_Tp>' with internal linkage _LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::valarray(size_t)) ^ .../include/c++/v1/valarray:1063:60: error: explicit instantiation declaration of '~valarray<_Tp>' with internal linkage _LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::~valarray()) llvm-svn: 359076
* C++ DR2387: a variable template declared wtih (or instantiated with) aRichard Smith2019-04-231-30/+51
| | | | | | | const-qualified type is not implicitly given internal linkage. But a variable template declared 'static' is. llvm-svn: 359048
* Fix overly-long line after r358731.Richard Smith2019-04-191-2/+2
| | | | llvm-svn: 358733
* Fix typo in function name [NFC]Ali Tamur2019-04-191-3/+3
| | | | llvm-svn: 358731
* [c++2a] Add semantic support for private module fragments.Richard Smith2019-04-181-10/+18
| | | | llvm-svn: 358713
OpenPOWER on IntegriCloud