summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST
Commit message (Collapse)AuthorAgeFilesLines
...
* [AST] Fix some Clang-tidy modernize and Include What You Use warnings; other ↵Eugene Zelenko2017-11-141-32/+40
| | | | | | minor fixes (NFC). llvm-svn: 318221
* [AST] Fix some Clang-tidy modernize and Include What You Use warnings; other ↵Eugene Zelenko2017-11-141-46/+62
| | | | | | minor fixes (NFC). llvm-svn: 318216
* [ASTImporter] TypeAliasTemplate and PackExpansion importing capabilityGabor Horvath2017-11-141-0/+83
| | | | | | | | Patch by: Zoltan Gera! Differential Revision: https://reviews.llvm.org/D39247 llvm-svn: 318147
* [AST] Fix some Clang-tidy modernize and Include What You Use warnings; other ↵Eugene Zelenko2017-11-131-40/+62
| | | | | | minor fixes (NFC). llvm-svn: 318101
* Handle lambda captures of variable length arrays in profiling and printing.Richard Trieu2017-11-112-0/+6
| | | | | | | | From http://reviews.llvm.org/D4368 these cases were thought to not be reachable and the checks removed before the rest of the code was committed in r216649. However, these cases are reachable and the checks are added back. llvm-svn: 317957
* [AST] Fix some Clang-tidy modernize and Include What You Use warnings; other ↵Eugene Zelenko2017-11-103-12/+23
| | | | | | minor fixes (NFC). llvm-svn: 317854
* Moved QualTypeNames.h from Tooling to AST.Ilya Biryukov2017-11-082-0/+467
| | | | | | | | | | | | | | | | | Summary: For code reuse in SemaCodeComplete. Note that the tests for QualTypeNames are still in Tooling as they use Tooling's common testing code. Reviewers: rsmith, saugustine, rnk, klimek, bkramer Reviewed By: rnk Subscribers: cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D39224 llvm-svn: 317676
* [AST] Fix some Clang-tidy modernize and Include What You Use warnings; other ↵Eugene Zelenko2017-11-082-15/+34
| | | | | | minor fixes (NFC). llvm-svn: 317644
* Add default calling convention support for regcall.Erich Keane2017-11-021-0/+5
| | | | | | | | | | | Added support for regcall as default calling convention. Also added code to exclude main when applying default calling conventions. Patch-By: eandrews Differential Revision: https://reviews.llvm.org/D39210 llvm-svn: 317268
* Make helper function static. NFC.Benjamin Kramer2017-10-311-1/+1
| | | | llvm-svn: 317052
* [modules] Retain multiple using-directives in the same scope even if they ↵Richard Smith2017-10-301-8/+0
| | | | | | | | | | | | name the same namespace. They might have different visibility, and thus discarding all but one of them can result in rejecting valid code. Also fix name lookup to cope with multiple using-directives being found that denote the same namespace, where some are not visible -- don't cache an "already visited" state for a using-directive that we didn't visit because it was hidden. llvm-svn: 316965
* Allow StmtPrinter to supress implicit 'this' and 'self' base expressionsAlex Lorenz2017-10-261-9/+33
| | | | | | | | This will be useful for certain refactoring actions. rdar://34202062 llvm-svn: 316631
* Correct behavior of fastcall when default CC is set.Erich Keane2017-10-241-1/+1
| | | | | | | | | | | Fastcall doesn't support variadic function calls, so setting the default calling convention to Fastcall would result in incorrect code being emitted for these conditions. This patch adds a 'variadic' test to the default calling conv test, as well as fixes the behavior of fastcall. llvm-svn: 316528
* Replaced unicode characters with ASCII, as introduced in r316518.Erich Keane2017-10-241-5/+4
| | | | llvm-svn: 316521
* mplement __has_unique_object_representationsErich Keane2017-10-241-0/+146
| | | | | | | | | | | | A helper builtin to facilitate implementing the std::has_unique_object_representations type trait. Requested here: https://bugs.llvm.org/show_bug.cgi?id=34942 Also already exists in GCC and MSVC. Differential Revision: https://reviews.llvm.org/D39064 llvm-svn: 316518
* Unnamed bitfields don't block constant evaluation of constexpr ctorsJordan Rose2017-10-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | | C++14 [dcl.constexpr]p4 states that in the body of a constexpr constructor, > every non-variant non-static data member and base class sub-object shall be initialized However, [class.bit]p2 notes that > Unnamed bit-fields are not members and cannot be initialized. Therefore, we should make sure to filter them out of the check that all fields are initialized. Fixing this makes the constant evaluator a bit smarter, and specifically allows constexpr constructors to avoid tripping -Wglobal-constructors when the type contains unnamed bitfields. Reviewed at https://reviews.llvm.org/D39035. llvm-svn: 316408
* For better compatibility with C++11 and C++14, emit a nondiscardable definitionRichard Smith2017-10-231-3/+3
| | | | | | | of a static constexpr data member if it's defined 'constexpr' out of line, not only if it's defined 'constexpr' in the class. llvm-svn: 316310
* Implement current CWG direction for support of arrays of unknown bounds inRichard Smith2017-10-201-27/+66
| | | | | | | | | | | | | | | | | constant expressions. We permit array-to-pointer decay on such arrays, but disallow pointer arithmetic (since we do not know whether it will have defined behavior). This is based on r311970 and r301822 (the former by me and the latter by Robert Haberlach). Between then and now, two things have changed: we have committee feedback indicating that this is indeed the right direction, and the code broken by this change has been fixed. This is necessary in C++17 to continue accepting certain forms of non-type template argument involving arrays of unknown bound. llvm-svn: 316245
* Fix nodiscard for volatile referencesErich Keane2017-10-191-1/+2
| | | | | | | | | | As reported here https://bugs.llvm.org/show_bug.cgi?id=34988 [[nodiscard]] warnings were not being suppressed for volatile-ref return values. Differential Revision: https://reviews.llvm.org/D39075 llvm-svn: 316166
* [ASTImporter] Import SubStmt of CaseStmtGabor Horvath2017-10-181-3/+7
| | | | | | | | Patch by: Rafael Stahl! Differential Revision: https://reviews.llvm.org/D38943 llvm-svn: 316069
* Enable support for the [[nodiscard]] attribute from WG14 N2050 when enabling ↵Aaron Ballman2017-10-171-1/+2
| | | | | | double square bracket attributes in C code. llvm-svn: 316026
* [OpenMP] Implement omp_is_initial_device() as builtinJonas Hahnfeld2017-10-171-0/+3
| | | | | | | | This allows to return the static value that we know at compile time. Differential Revision: https://reviews.llvm.org/D38968 llvm-svn: 316001
* Convert clang::LangAS to a strongly typed enumAlexander Richardson2017-10-154-19/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Convert clang::LangAS to a strongly typed enum Currently both clang AST address spaces and target specific address spaces are represented as unsigned which can lead to subtle errors if the wrong type is passed. It is especially confusing in the CodeGen files as it is not possible to see what kind of address space should be passed to a function without looking at the implementation. I originally made this change for our LLVM fork for the CHERI architecture where we make extensive use of address spaces to differentiate between capabilities and pointers. When merging the upstream changes I usually run into some test failures or runtime crashes because the wrong kind of address space is passed to a function. By converting the LangAS enum to a C++11 we can catch these errors at compile time. Additionally, it is now obvious from the function signature which kind of address space it expects. I found the following errors while writing this patch: - ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address space to TargetInfo::getPointer{Width,Align}() - TypePrinter::printAttributedAfter() prints the numeric value of the clang AST address space instead of the target address space. However, this code is not used so I kept the current behaviour - initializeForBlockHeader() in CGBlocks.cpp was passing LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}() - CodeGenFunction::EmitBlockLiteral() was passing a AST address space to TargetInfo::getPointerWidth() - CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space to Qualifiers::addAddressSpace() - CGOpenMPRuntimeNVPTX::getParameterAddress() was using llvm::Type::getPointerTo() with a AST address space - clang_getAddressSpace() returns either a LangAS or a target address space. As this is exposed to C I have kept the current behaviour and added a comment stating that it is probably not correct. Other than this the patch should not cause any functional changes. Reviewers: yaxunl, pcc, bader Reviewed By: yaxunl, bader Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits Differential Revision: https://reviews.llvm.org/D38816 llvm-svn: 315871
* Hide "#pragma optimize("", off)" from clang when it pretends to be MSVC 2017Reid Kleckner2017-10-131-2/+2
| | | | | | | These pragmas work around a bug in VC 1911 that isn't present in clang, and clang warns about them. llvm-svn: 315699
* [OpenCL] Add LangAS::opencl_private to represent private address space in ASTYaxun Liu2017-10-134-22/+30
| | | | | | | | | | | | | | | | | | | | | | | | Currently Clang uses default address space (0) to represent private address space for OpenCL in AST. There are two issues with this: Multiple address spaces including private address space cannot be diagnosed. There is no mangling for default address space. For example, if private int* is emitted as i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as Pi instead. This patch attempts to represent OpenCL private address space explicitly in AST. It adds a new enum LangAS::opencl_private and adds it to the variable types which are implicitly private: automatic variables without address space qualifier function parameter pointee type without address space qualifier (OpenCL 1.2 and below) Differential Revision: https://reviews.llvm.org/D35082 llvm-svn: 315668
* Support for destroying operator delete, per C++2a proposal P0722.Richard Smith2017-10-133-2/+41
| | | | | | | | | | This feature is not (yet) approved by the C++ committee, so this is liable to be reverted or significantly modified based on committee feedback. No functionality change intended for existing code (a new type must be defined in namespace std to take advantage of this feature). llvm-svn: 315662
* [Modules TS] Module ownership semantics for redeclarations.Richard Smith2017-10-103-7/+18
| | | | | | | | | | | | | | | | | When declaring an entity in the "purview" of a module, it's never a redeclaration of an entity in the purview of a default module or in no module ("in the global module"). Don't consider those other declarations as possible redeclaration targets if they're not visible, and reject any cases where we pick a prior visible declaration that violates this rule. This reinstates r315251 and r315256, reverted in r315309 and r315308 respectively, tweaked to avoid triggering a linkage calculation when declaring implicit special members (this exposed our pre-existing issue with typedef names for linkage changing the linkage of types whose linkage has already been computed and cached in more cases). A testcase for that regression has been added in r315366. llvm-svn: 315379
* Revert "[Modules TS] Module ownership semantics for redeclarations."Eric Liu2017-10-103-16/+7
| | | | | | This reverts commit r315251. See the original commit thread for reason. llvm-svn: 315309
* Revert "[Modules TS] Avoid computing the linkage of the enclosing ↵Eric Liu2017-10-101-3/+1
| | | | | | | | DeclContext for a declaration in the global module." This reverts commit r315256. See the original commit thread for reason. llvm-svn: 315308
* [Modules TS] Avoid computing the linkage of the enclosing DeclContext for a ↵Richard Smith2017-10-101-1/+3
| | | | | | | | | | declaration in the global module. This works around a language issue where adding a typedef name for linkage purposes changes the linkage of an already-defined class after it becomes complete. llvm-svn: 315256
* [Modules TS] Module ownership semantics for redeclarations.Richard Smith2017-10-093-7/+16
| | | | | | | | | | When declaring an entity in the "purview" of a module, it's never a redeclaration of an entity in the purview of a default module or in no module ("in the global module"). Don't consider those other declarations as possible redeclaration targets if they're not visible, and reject any cases where we pick a prior visible declaration that violates this rule. llvm-svn: 315251
* Remove unused variables. No functionality change.Benjamin Kramer2017-10-082-3/+0
| | | | llvm-svn: 315196
* Remove unused variables. No functionality change.Benjamin Kramer2017-10-081-1/+0
| | | | llvm-svn: 315185
* -Wdocumentation should allow '...' params in variadic function type aliasesAlex Lorenz2017-10-061-1/+9
| | | | | | rdar://34811344 llvm-svn: 315103
* [ExprConstant] Allow constexpr ctor to modify non static data membersErik Pilkington2017-10-041-3/+30
| | | | | | | | Fixes PR19741. Differential revision: https://reviews.llvm.org/D38483 llvm-svn: 314865
* R34811: Allow visibilities other than 'default' for VisibleNoLinkage entities.Richard Smith2017-10-031-2/+2
| | | | llvm-svn: 314754
* [OPENMP] Capture argument of `device` clause for target-basedAlexey Bataev2017-10-021-1/+2
| | | | | | | | | | directives. The argument of the `device` clause in target-based executable directives must be captured to support codegen for the `target` directives with the `depend` clauses. llvm-svn: 314686
* Dependent Address Space SupportAndrew Gozillon2017-10-026-8/+152
| | | | | | | | | | | | | | This patch relates to: https://reviews.llvm.org/D33666 This adds support for template parameters to be passed to the address_space attribute. The main goal is to add further flexibility to the attribute and allow for it to be used easily with templates. The main additions are a new type (DependentAddressSpaceType) alongside its TypeLoc and its mangling. As well as the logic required to support dependent address spaces which mainly resides in TreeTransform.h and SemaType.cpp. llvm-svn: 314649
* [ODRHash] Add base classes to hashing CXXRecordDecl.Richard Trieu2017-09-301-0/+8
| | | | llvm-svn: 314581
* [Sema] Correct IUnknown to support Unknwnbase.h Header.Erich Keane2017-09-291-3/+15
| | | | | | | | | | | | | | Apparently, the MSVC SDK has a strange implementation that causes a number of implicit functions as well as a template member function of the IUnknown type. This patch allows these as InterfaceLike types as well. Additionally, it corrects the behavior where extern-C++ wrapped around an Interface-Like type would permit an interface-like type to exist in a namespace. Differential Revision: https://reviews.llvm.org/D38303 llvm-svn: 314557
* [Sema] Suppress warnings for C's zero initializerDaniel Marjamaki2017-09-291-0/+11
| | | | | | | | Patch by S. Gilles! Differential Revision: https://reviews.llvm.org/D28148 llvm-svn: 314499
* [clang] Add getUnsignedPointerDiffType methodAlexander Shaposhnikov2017-09-281-0/+7
| | | | | | | | | | | | | | | | | C11 standard refers to the unsigned counterpart of the type ptrdiff_t in the paragraph 7.21.6.1p7 where it defines the format specifier %tu. In Clang (in PrintfFormatString.cpp, lines 508-510) there is a FIXME for this case, in particular, Clang didn't diagnose %tu issues at all, i.e. it didn't emit any warnings on the code printf("%tu", 3.14). In this diff we add a method getUnsignedPointerDiffType for getting the corresponding type similarly to how it's already done in the other analogous cases (size_t, ssize_t, ptrdiff_t etc) and fix -Wformat diagnostics for %tu plus the emitted fix-it as well. Test plan: make check-all Differential revision: https://reviews.llvm.org/D38270 llvm-svn: 314470
* Fix -Wcast-qual warning after r314336.Nico Weber2017-09-281-1/+1
| | | | llvm-svn: 314424
* Add support for remembering origins to ExternalASTMergerSean Callanan2017-09-271-93/+309
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
* Allow IUnknown/IInterface types to come from extern C++ Erich Keane2017-09-261-1/+2
| | | | | | | | | | | | It was brought up in response to my last implementation for this struct-as-interface features that at least 1 header in the MS SDK uses "extern C++" around an IUnknown declaration. The previous implementation demanded that this type exist in the TranslationUnit DeclContext. This small change simply also allows in the situation where we're extern "C++". llvm-svn: 314235
* Allow specifying sanitizers in blacklistsVlad Tsyrklevich2017-09-251-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the follow-up patch to D37924. This change refactors clang to use the the newly added section headers in SpecialCaseList to specify which sanitizers blacklists entries should apply to, like so: [cfi-vcall] fun:*bad_vcall* [cfi-derived-cast|cfi-unrelated-cast] fun:*bad_cast* The SanitizerSpecialCaseList class has been added to allow querying by SanitizerMask, and SanitizerBlacklist and its downstream users have been updated to provide that information. Old blacklists not using sections will continue to function identically since the blacklist entries will be placed into a '[*]' section by default matching against all sanitizers. Reviewers: pcc, kcc, eugenis, vsk Reviewed By: eugenis Subscribers: dberris, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D37925 llvm-svn: 314171
* Correctly compute linkage for members of internal linkage classes.Richard Smith2017-09-231-5/+4
| | | | | | | We used to give such members no linkage instead of giving them the linkage of the class. llvm-svn: 314054
* DR1113: anonymous namespaces formally give their contents internal linkage.Richard Smith2017-09-222-7/+13
| | | | | | | | | | | | | | | | | | | | This doesn't affect our code generation in any material way -- we already give such declarations internal linkage from a codegen perspective -- but it has some subtle effects on code validity. We suppress the 'L' (internal linkage) marker for mangled names in anonymous namespaces, because it is redundant (the information is already carried by the namespace); this deviates from GCC's behavior if a variable or function in an anonymous namespace is redundantly declared 'static' (where GCC does include the 'L'), but GCC's behavior is incoherent because such a declaration can be validly declared with or without the 'static'. We still deviate from the standard in one regard here: extern "C" declarations in anonymous namespaces are still granted external linkage. Changing those does not appear to have been an intentional consequence of the standard change in DR1113. llvm-svn: 314037
* Fix unused variable warning. NFCI.Simon Pilgrim2017-09-221-2/+1
| | | | llvm-svn: 313991
* Add Cross Translation Unit support libraryGabor Horvath2017-09-221-0/+15
| | | | | | | | | | | | | | | | | | This patch introduces a class that can help to build tools that require cross translation unit facilities. This class allows function definitions to be loaded from external AST files based on an index. In order to use this functionality an index is required. The index format is a flat text file but it might be replaced with a different solution in the near future. USRs are used as names to look up the functions definitions. This class also does caching to avoid redundant loading of AST files. Right now only function defnitions can be loaded using this API because this is what the in progress cross translation unit feature of the Static Analyzer requires. In to future this might be extended to classes, types etc. Differential Revision: https://reviews.llvm.org/D34512 llvm-svn: 313975
OpenPOWER on IntegriCloud