summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaDecl.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [Sema] Avoid -Wshadow warnings for shadowed variables thatAlex Lorenz2016-11-101-9/+37
| | | | | | | | | | | | | | | | | aren't captured by lambdas with a default capture specifier This commit is a follow-up to r286354. It avoids the -Wshadow warning for variables which shadow variables that aren't captured by lambdas with a default capture specifier. It provides an additional note that points to location of the capture. The old behaviour is preserved with -Wshadow-all or -Wshadow-uncaptured-local. rdar://14984176 Differential Revision: https://reviews.llvm.org/D26448 llvm-svn: 286465
* [Sema] Avoid -Wshadow warnings for shadowed variables that aren't capturedAlex Lorenz2016-11-091-1/+30
| | | | | | | | | | | | | | | | by lambdas with an explicit capture list This commit avoids the -Wshadow warning for variables which shadow variables that aren't captured by lambdas with an explicit capture list. It provides an additional note that points to location of the explicit capture. The old behaviour is preserved with -Wshadow-all or -Wshadow-uncaptured-local. rdar://17135966 Differential Revision: https://reviews.llvm.org/D26278 llvm-svn: 286354
* Add a note that points to the linkage specifier for the C++ linkage errorsAlex Lorenz2016-11-021-1/+1
| | | | | | | | | | | | This commit improves the "must have C++ linkage" error diagnostics that are emitted for C++ declarations like templates and literal operators by adding an additional note that points to the appropriate extern "C" linkage specifier. rdar://19021120 Differential Revision: https://reviews.llvm.org/D26189 llvm-svn: 285823
* More forcibly resolve exception specifications when checking a functionRichard Smith2016-11-021-0/+9
| | | | | | | redeclaration in C++1z mode. We need the exception specification in order for the function's type to be complete. llvm-svn: 285779
* [CUDA] [AST] Allow isInlineDefinitionExternallyVisible to be called on ↵Justin Lebar2016-10-281-17/+6
| | | | | | | | | | | | | | | | | | | | | | | | | functions without bodies. Summary: In CUDA compilation, we call isInlineDefinitionExternallyVisible (via getGVALinkageForFunction) on functions while parsing their definitions. At the point in time when we call getGVALinkageForFunction, we haven't yet added the body to the function, so we trip this assert. But as far as I can tell, this is harmless. To work around this, we add a new flag to FunctionDecl, "WillHaveBody". There was other code that was working around the existing assert with a really awful hack -- this change lets us get rid of that hack. Reviewers: rsmith, tra Subscribers: aemerson, cfe-commits Differential Revision: https://reviews.llvm.org/D25640 llvm-svn: 285410
* [OpenCL] Diagnose variadic argumentsAnastasia Stulova2016-10-281-11/+0
| | | | | | | | | | | | | | OpenCL disallows using variadic arguments (s6.9.e and s6.12.5 OpenCL v2.0) apart from some exceptions: - printf - enqueue_kernel This change adds error diagnostic for variadic functions but accepts printf and any compiler internal function (which should cover __enqueue_kernel_XXX cases). It also unifies diagnostic with block prototype and adds missing uncaught cases for blocks. llvm-svn: 285395
* [Sema] -Wunused-variable warning for array variables should behaveAlex Lorenz2016-10-271-1/+5
| | | | | | | | | | | | | | similarly to scalar variables. This commit makes the -Wunused-variable warning behaviour more consistent: Now clang won't warn for array variables where it doesn't warn for scalar variables. rdar://24158862 Differential Revision: https://reviews.llvm.org/D25937 llvm-svn: 285289
* Mark invalid RecordDecls as completed.Erik Verbruggen2016-10-271-1/+8
| | | | | | | | | | | | | | | Sema::ActOnTag creates TagDecls for records. However, if those record declarations are invalid, and the parser is in C++ mode, it would silently drop the TagDecl (and leave it as "beingDefined"). The problem is that other code (e.g. the ASTWriter) will serialize all types, and expects them to be complete. So, leaving them open would result in failing asserts. Fixes PR20320 Differential Revision: http://reviews.llvm.org/D21176 llvm-svn: 285275
* Implement name mangling proposal for exception specifications from ↵Richard Smith2016-10-261-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cxx-abi-dev 2016-10-11. This has the following ABI impact: 1) Functions whose parameter or return types are non-throwing function pointer types have different manglings in c++1z mode from prior modes. This is necessary because c++1z permits overloading on the noexceptness of function pointer parameter types. A warning is issued for cases that will change manglings in c++1z mode. 2) Functions whose parameter or return types contain instantiation-dependent exception specifications change manglings in all modes. This is necessary to support overloading on / SFINAE in these exception specifications, which a careful reading of the standard indicates has essentially always been permitted. Note that, in order to be affected by these changes, the code in question must specify an exception specification on a function pointer/reference type that is written syntactically within the declaration of another function. Such declarations are very rare, and I have so far been unable to find any code that would be affected by this. (Note that such things will probably become more common in C++17, since it's a lot easier to get a noexcept function type as a function parameter / return type there.) This change does not affect the set of symbols produced by a build of clang, libc++, or libc++abi. llvm-svn: 285150
* Reapply r284265: "[Sema] Refactor context checking for availability diagnostics"Erik Pilkington2016-10-251-26/+0
| | | | | | | | The problem with the original commit was that some of Apple's headers depended on an incorrect behaviour, this commit adds a temporary workaround until those headers are fixed. llvm-svn: 285098
* Remove accidentally checked in assert.Vassil Vassilev2016-10-211-3/+0
| | | | | | Thanks to Manman for spotting this. llvm-svn: 284877
* Removed unused function argument. NFC.Artem Belevich2016-10-211-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D25839 llvm-svn: 284843
* Don't try to use !Previous.empty() as a proxy for "Is this a redeclaration?" --Richard Smith2016-10-211-3/+1
| | | | | | | | | | | we don't collapse that down to a single entry if it's not a redeclaration. Instead, set the Redeclaration bit on the Declarator to indicate whether a function is a redeclaration (which may not have been linked into the redeclaration chain if it's a dependent context friend). Fixes a rejects-valid; see testcase. llvm-svn: 284802
* [modules] Do not report missing definitions of demoted constexpr variable ↵Vassil Vassilev2016-10-191-1/+5
| | | | | | | | | | | | | | templates. This is a followup to regression introduced in r284284. This should fix our libstdc++ modules builds. https://reviews.llvm.org/D25678 Reviewed by Richard Smith! llvm-svn: 284577
* Revert r284265 "[Sema] Refactor context checking for availability diagnostics"Erik Pilkington2016-10-181-0/+26
| | | | | | This has a bug in it, pointed out by Bob Wilson! llvm-svn: 284486
* P0012R1: Make exception specifications be part of the type system. ThisRichard Smith2016-10-161-5/+15
| | | | | | | implements the bulk of the change (modifying the type system to include exception specifications), but not all the details just yet. llvm-svn: 284337
* Reinstate r284008 reverted in r284081, with two fixes:Richard Smith2016-10-141-36/+39
| | | | | | | | | | | | | | | | | | | 1) Merge and demote variable definitions when we find a redefinition in MergeVarDecls, not only when we find one in AddInitializerToDecl (we only reach the second case if it's the addition of the initializer itself that converts an existing declaration into a definition). 2) When rebuilding a redeclaration chain for a variable, if we merge two definitions together, mark the definitions as merged so the retained definition is made visible whenever the demoted definition would have been. Original commit message (from r283882): [modules] PR28752: Do not instantiate variable declarations which are not visible. Original patch by Vassil Vassilev! Changes listed above are mine. llvm-svn: 284284
* [Sema] Refactor context checking for availability diagnosticsErik Pilkington2016-10-141-26/+0
| | | | | | | | | This commit combines a couple of redundant functions that do availability attribute context checking into a more correct/simpler one. Differential revision: https://reviews.llvm.org/D25283 llvm-svn: 284265
* [CUDA] Allow static variables in __host__ __device__ functions, so long as ↵Justin Lebar2016-10-131-6/+5
| | | | | | | | | | | | they're never codegen'ed for device. Reviewers: tra, rnk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D25150 llvm-svn: 284145
* Module: emit initializers for C/ObjC after r276159.Manman Ren2016-10-131-1/+7
| | | | | | | | | In r276159, we started to defer emitting initializers for VarDecls, but forgot to add the initializers for non-C++ language. rdar://28740482 llvm-svn: 284142
* Revert r284008. This is us to fail to instantiate static data members in someRichard Smith2016-10-121-16/+0
| | | | | | cases. I'm working on reducing a testcase. llvm-svn: 284081
* Reinstate r283887 and r283882.Vassil Vassilev2016-10-121-0/+16
| | | | | | | | | | | Original message: "[modules] PR28752: Do not instantiate variable declarations which are not visible. https://reviews.llvm.org/D24508 Patch developed in collaboration with Richard Smith!" llvm-svn: 284008
* Revert r283887 and r283882, until the issue is understood and fixed.Vassil Vassilev2016-10-111-17/+0
| | | | llvm-svn: 283890
* r283882 followup. Don't demote ParmVarDecls. This should fix our module builds.Vassil Vassilev2016-10-111-14/+16
| | | | llvm-svn: 283887
* [modules] PR28752: Do not instantiate variable declarations which are not ↵Vassil Vassilev2016-10-111-0/+15
| | | | | | | | | | visible. https://reviews.llvm.org/D24508 Patch developed in collaboration with Richard Smith! llvm-svn: 283882
* Re-commit r283722, reverted in r283750, with a fix for a CUDA-specific use ofRichard Smith2016-10-101-0/+8
| | | | | | | | | | | past-the-end iterator. Original commit message: P0035R4: Semantic analysis and code generation for C++17 overaligned allocation. llvm-svn: 283789
* Revert "P0035R4: Semantic analysis and code generation for C++17 overaligned ↵Daniel Jasper2016-10-101-8/+0
| | | | | | | | | | | | allocation." This reverts commit r283722. Breaks: Clang.SemaCUDA.device-var-init.cu Clang.CodeGenCUDA.device-var-init.cu http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/884/ llvm-svn: 283750
* P0035R4: Semantic analysis and code generation for C++17 overalignedRichard Smith2016-10-101-0/+8
| | | | | | allocation. llvm-svn: 283722
* Do not find friend function definitions inside non-instantiated class.Serge Pavlov2016-10-041-5/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously if a file-level function was defined inside befriending template class, it always was treated as defined. For instance, the code like: ``` int func(int x); template<typename T> class C1 { friend int func(int x) { return x; } }; template<typename T> class C2 { friend int func(int x) { return x; } }; ``` could not be compiled due to function redefinition, although not of the templates is instantiated. Moreover, the body of friend function can contain use of template parameters, attempt to get definition of such function outside any instantiation causes compiler abnormal termination. Other compilers (gcc, icc) follow viewpoint that the body of the function defined in friend declaration becomes available when corresponding class is instantiated. This patch implements this viewpoint in clang. Definitions introduced by friend declarations in template classes are not added to the redeclaration chain of corresponding function. Only when the template is instantiated, instantiation of the function definition is placed to the chain. The fix was made in collaboration with Richard Smith. This change fixes PR8035, PR17923, PR22307 and PR25848. Differential Revision: http://reviews.llvm.org/D16989 llvm-svn: 283207
* Factor out a diagnostic kind enum for use in two %select expressionsReid Kleckner2016-10-031-10/+18
| | | | | | NFC llvm-svn: 283131
* [coroutines] Rename driver flag -fcoroutines to -fcoroutines-tsGor Nishanov2016-10-021-1/+1
| | | | | | | | | | | | | | | Summary: Also makes -fcoroutines_ts to be both a Driver and CC1 flag. Patch mostly by EricWF. Reviewers: rnk, cfe-commits, rsmith, EricWF Subscribers: mehdi_amini Differential Revision: https://reviews.llvm.org/D25130 llvm-svn: 283064
* P0035R4: add std::align_val_t overloads of operator new/delete in C++17 mode.Richard Smith2016-09-291-7/+17
| | | | llvm-svn: 282800
* [Modules TS] Diagnose 'export' declaration within 'export' declaration.Richard Smith2016-09-261-2/+5
| | | | llvm-svn: 282443
* [OpenCL] Allow half type kernel argument when cl_khr_fp16 is enabledYaxun Liu2016-09-191-5/+11
| | | | llvm-svn: 281915
* Add some MS aliases for existing intrinsicsAlbert Gutowski2016-09-141-1/+3
| | | | | | | | | | Reviewers: thakis, compnerd, majnemer, rsmith, rnk Subscribers: alexshap, cfe-commits Differential Revision: https://reviews.llvm.org/D24330 llvm-svn: 281540
* [CUDA] Do not merge CUDA target attributes.Artem Belevich2016-09-131-1/+7
| | | | | | | | | | | | CUDA target attributes are used for function overloading and must not be merged. This fixes a bug where attributes were inherited during function template specialization in CUDA and made it impossible for specialized function to provide its own target attributes. Differential Revision: https://reviews.llvm.org/D24522 llvm-svn: 281406
* Reverse commit 281375 (breaks building Chromium)Albert Gutowski2016-09-131-3/+1
| | | | llvm-svn: 281399
* Add some MS aliases for existing intrinsicsAlbert Gutowski2016-09-131-1/+3
| | | | | | | | | | Reviewers: thakis, compnerd, majnemer, rsmith, rnk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D24330 llvm-svn: 281375
* [clang-cl] Diagnose duplicate uuids.Nico Weber2016-09-131-0/+10
| | | | | | | | | | | | This mostly behaves cl.exe's behavior, even though clang-cl is stricter in some corner cases and more lenient in others (see the included test). To make the uuid declared previously here diagnostic work correctly, tweak stripTypeAttributesOffDeclSpec() to keep attributes in the right order. https://reviews.llvm.org/D24469 llvm-svn: 281367
* Allow register variables in naked functions.Nikola Smiljanic2016-09-131-0/+15
| | | | llvm-svn: 281298
* C++ Modules TS: Add parsing and some semantic analysis support forRichard Smith2016-09-081-0/+30
| | | | | | | export-declarations. These don't yet have an effect on name visibility; we still export everything by default. llvm-svn: 280999
* Implement __attribute__((require_constant_initialization)) for safe static ↵Eric Fiselier2016-09-021-24/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | initialization. Summary: This attribute specifies expectations about the initialization of static and thread local variables. Specifically that the variable has a [constant initializer](http://en.cppreference.com/w/cpp/language/constant_initialization) according to the rules of [basic.start.static]. Failure to meet this expectation will result in an error. Static objects with constant initializers avoid hard-to-find bugs caused by the indeterminate order of dynamic initialization. They can also be safely used by other static constructors across translation units. This attribute acts as a compile time assertion that the requirements for constant initialization have been met. Since these requirements change between dialects and have subtle pitfalls it's important to fail fast instead of silently falling back on dynamic initialization. ```c++ // -std=c++14 #define SAFE_STATIC __attribute__((require_constant_initialization)) static struct T { constexpr T(int) {} ~T(); }; SAFE_STATIC T x = {42}; // OK. SAFE_STATIC T y = 42; // error: variable does not have a constant initializer // copy initialization is not a constant expression on a non-literal type. ``` This attribute can only be applied to objects with static or thread-local storage duration. Reviewers: majnemer, rsmith, aaron.ballman Subscribers: jroelofs, cfe-commits Differential Revision: https://reviews.llvm.org/D23385 llvm-svn: 280525
* Revert r280516 since it contained accidental changes.Eric Fiselier2016-09-021-50/+24
| | | | llvm-svn: 280521
* Implement __attribute__((require_constant_initialization)) for safe static ↵Eric Fiselier2016-09-021-24/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | initialization. Summary: This attribute specifies expectations about the initialization of static and thread local variables. Specifically that the variable has a [constant initializer](http://en.cppreference.com/w/cpp/language/constant_initialization) according to the rules of [basic.start.static]. Failure to meet this expectation will result in an error. Static objects with constant initializers avoid hard-to-find bugs caused by the indeterminate order of dynamic initialization. They can also be safely used by other static constructors across translation units. This attribute acts as a compile time assertion that the requirements for constant initialization have been met. Since these requirements change between dialects and have subtle pitfalls it's important to fail fast instead of silently falling back on dynamic initialization. ```c++ // -std=c++14 #define SAFE_STATIC __attribute__((require_constant_initialization)) static struct T { constexpr T(int) {} ~T(); }; SAFE_STATIC T x = {42}; // OK. SAFE_STATIC T y = 42; // error: variable does not have a constant initializer // copy initialization is not a constant expression on a non-literal type. ``` This attribute can only be applied to objects with static or thread-local storage duration. Reviewers: majnemer, rsmith, aaron.ballman Subscribers: jroelofs, cfe-commits Differential Revision: https://reviews.llvm.org/D23385 llvm-svn: 280516
* When we reach the end of a #include of a header of a local submodule that weRichard Smith2016-09-011-7/+17
| | | | | | | | | | textually included, create an ImportDecl just as we would if we reached a #include of any other modular header. This is necessary in order to correctly determine the set of variables to initialize for an imported module. This should hopefully make the modules selfhost buildbot green again. llvm-svn: 280409
* [Sema] Don't diagnose an array type mismatch when the new or previousAkira Hatanaka2016-09-011-2/+2
| | | | | | | | | | | | declaration has a dependent type. This fixes a bug where clang errors out on a valid code. rdar://problem/28051467 Differential Revision: https://reviews.llvm.org/D24110 llvm-svn: 280330
* PR12298 et al: don't recursively instantiate a template specialization fromRichard Smith2016-08-311-1/+2
| | | | | | | | | | | | | | | within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
* C++ Modules TS: add frontend support for building pcm files from moduleRichard Smith2016-08-261-26/+62
| | | | | | | interface files. At the moment, all declarations (and no macros) are exported, and 'export' declarations are not supported yet. llvm-svn: 279794
* Fix regression introduced by r279164: only pass definitions as the PatternDefRichard Smith2016-08-231-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly determine whether a function definition is visible, and mark both the function and the template as visible when merging function template definitions to provide hasVisibleDefinition with the relevant information. The change to always pass the right declaration as the PatternDef to DiagnoseUninstantiableTemplate also caused those checks to happen before other diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the same situations, so I sunk the relevant diagnostics into DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes in reviews.llvm.org/D23492 by Vassil Vassilev. This reinstates r279486, reverted in r279500, with a fix to DiagnoseUninstantiableTemplate to only mark uninstantiable explicit instantiation declarations as invalid if we actually diagnosed them. (When we trigger an explicit instantiation of a class member from an explicit instantiation declaration for the class, it's OK if there is no corresponding definition and we certainly don't want to mark the member invalid in that case.) This previously caused a build failure during bootstrap. llvm-svn: 279557
* Revert r279486 "Fix regression introduced by r279164"Chandler Carruth2016-08-231-2/+3
| | | | | | | Build bots seem unhappy and as Richard was leaving he asked me to revert this for him. Doing so. llvm-svn: 279500
OpenPOWER on IntegriCloud