summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaDecl.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Now that C++17 is official (https://www.iso.org/standard/68564.html), start ↵Aaron Ballman2017-12-041-11/+11
| | | | | | changing the C++1z terminology over to C++17. NFC intended, these are all mechanical changes. llvm-svn: 319688
* [Modules TS] Added module re-export support.Hamza Sood2017-11-211-4/+9
| | | | | | | This implements [dcl.modules.export] from the C++ Modules TS, which lets a module re-export another module with the "export import" syntax. Differential Revision: https://reviews.llvm.org/D40270 llvm-svn: 318744
* [CodeGen] fix const-ness of cbrt and fmaSanjay Patel2017-11-131-7/+25
| | | | | | | | | | | cbrt() is always constant because it can't overflow or underflow. Therefore, it can't set errno. fma() is not always constant because it can overflow or underflow. Therefore, it can set errno. But we know that it never sets errno on GNU / MSVC, so make it constant in those environments. Differential Revision: https://reviews.llvm.org/D39641 llvm-svn: 318093
* Add default calling convention support for regcall.Erich Keane2017-11-021-0/+7
| | | | | | | | | | | 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
* Fix missing -Wregister warning when 'register' is applied to a function ↵Richard Smith2017-11-011-0/+8
| | | | | | parameter. llvm-svn: 317140
* [Sema] Fix an assert-on-invalid by avoiding function template specialisationAlex Lorenz2017-10-271-4/+4
| | | | | | | | | | | | | deduction for invalid functions The fabricated template parameters cause an assertion because their depth is invalid. rdar://34109988 Differential Revision: https://reviews.llvm.org/D37341 llvm-svn: 316778
* [Sema] Add support for flexible array members in Obj-C.Volodymyr Sapsai2017-10-231-52/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow Obj-C ivars with incomplete array type but only as the last ivar. Also add a requirement for ivars that contain a flexible array member to be at the end of class too. It is possible to add in a subclass another ivar at the end but we'll emit a warning in this case. Also we'll emit a warning if a variable sized ivar is declared in class extension or in implementation because subclasses won't know they should avoid adding new ivars. In ARC incomplete array objects are treated as __unsafe_unretained so require them to be marked as such. Prohibit synthesizing ivars with flexible array members because order of synthesized ivars is not obvious and tricky to control. Spelling out ivar explicitly gives control to developers and helps to avoid surprises with unexpected ivar ordering. For C and C++ changed diagnostic to tell explicitly a field is not the last one and point to the next field. It is not as useful as in Obj-C but it is an improvement and it is consistent with Obj-C. For C for unions emit more specific err_flexible_array_union instead of generic err_field_incomplete. rdar://problem/21054495 Reviewers: rjmccall, theraven Reviewed By: rjmccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D38773 llvm-svn: 316381
* [Sema] Fix assertion failure when checking for unused variables in a ↵Benjamin Kramer2017-10-191-1/+1
| | | | | | dependent context. llvm-svn: 316177
* Fix PR34981, a crash-on-invalid merging dllimport to an invalid redecl.Nico Weber2017-10-171-2/+3
| | | | | | This is basically like r288207, just the other way round. llvm-svn: 316032
* Convert clang::LangAS to a strongly typed enumAlexander Richardson2017-10-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Re-land r315787, "[Sema] Warn about unused variables if we can constant ↵Benjamin Kramer2017-10-141-1/+2
| | | | | | | | evaluate the initializer." The warnings in libc++ tests were fixed in the meantime. llvm-svn: 315811
* Revert rL315787, "[Sema] Warn about unused variables if we can constant ↵NAKAMURA Takumi2017-10-141-2/+1
| | | | | | | | evaluate the initializer." check-libcxx dislikes it. llvm-svn: 315806
* [Sema] Warn about unused variables if we can constant evaluate the initializer.Benjamin Kramer2017-10-141-1/+2
| | | | | | | | | | If the variable construction can be constant evaluated it doesn't have side effects, so removing it is always safe. We only try to evaluate variables that are unused, there should be no impact on compile time. Differential Revision: https://reviews.llvm.org/D38678 llvm-svn: 315787
* [OpenCL] Add LangAS::opencl_private to represent private address space in ASTYaxun Liu2017-10-131-13/+12
| | | | | | | | | | | | | | | | | | | | | | | | 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
* [Sema][ObjC] Complete merging ObjC methods before checking theirAkira Hatanaka2017-10-121-2/+0
| | | | | | | | | | | | | | | | | | | overriding methods. This should fix test case Analysis/retain-release.m that was failing on the reverse iteration bot: http://lab.llvm.org:8011/builders/reverse-iteration The test used to fail because the loop in CheckObjCMethodOverrides would merge attribute ns_returns_retained on methods while checking whether the overriding methods were compatible. Since OverrideSearch::Overridden is a SmallPtrSet and the order in which the elements of the set are visited is non-deterministic, the test would fail when method 'clone' of the protocol 'F18P' was visited before F18(Cat)'s method 'clone' was visited. llvm-svn: 315639
* [Modules TS] Diagnose missing/duplicate module-declaration.Richard Smith2017-10-111-5/+13
| | | | llvm-svn: 315397
* [Modules TS] Diagnose attempts to enter module implementation units without ↵Richard Smith2017-10-101-5/+7
| | | | | | the module interface being available. llvm-svn: 315381
* [Modules TS] Module ownership semantics for redeclarations.Richard Smith2017-10-101-16/+69
| | | | | | | | | | | | | | | | | 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
* For dllexport class templates, export specializations of member functions ↵Hans Wennborg2017-10-101-0/+16
| | | | | | | | | | (PR34849) (take 2) This is a re-commit of r315025, but making sure to only apply this to specializations of class template member functions; i.e. not when the function itself is a template. llvm-svn: 315330
* Revert "[Modules TS] Module ownership semantics for redeclarations."Eric Liu2017-10-101-69/+16
| | | | | | This reverts commit r315251. See the original commit thread for reason. llvm-svn: 315309
* [Modules TS] Module ownership semantics for redeclarations.Richard Smith2017-10-091-16/+69
| | | | | | | | | | 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-081-1/+0
| | | | llvm-svn: 315196
* Revert "For dllexport class templates, export specializations of member ↵Reid Kleckner2017-10-061-15/+0
| | | | | | | | functions (PR34849)" This reverts r315025, it caused http://crbug.com/772461 llvm-svn: 315111
* For dllexport class templates, export specializations of member functions ↵Hans Wennborg2017-10-051-0/+15
| | | | | | (PR34849) llvm-svn: 315025
* Fix 'section' warning behavior with tentatively-defined valuesErich Keane2017-10-041-1/+1
| | | | | | | | | As reported on cfe-commits, r314262 resulted in tentatively-defined variables not being excluded for the warning. Patch By: Elizabeth Andrews llvm-svn: 314939
* We allow implicit function declarations as an extension in all C dialects. ↵Richard Smith2017-10-041-5/+3
| | | | | | Remove OpenCL special case. llvm-svn: 314872
* PR34822: Fix a collection of related bugs with our handling of C89 implicit ↵Richard Smith2017-10-041-15/+29
| | | | | | | | | | | | | | | | | function declarations. We were injecting the function into the wrong semantic context, resulting in it failing to be registered as a global for redeclaration lookup. As a consequence, we accepted invalid code since r310616. Fixing that resulted in the "out-of-scope declaration" diagnostic firing a lot more often. It turned out that warning codepath was non-conforming, because it did not cause us to inject the implicitly-declared function into the enclosing block scope. We now only warn if the type of the out-of-scope declaration doesn't match the type of an implicitly-declared function; in all other cases, we produce the normal warning for an implicitly-declared function. llvm-svn: 314871
* PR33839: Fix -Wunused handling for structured binding declarations.Richard Smith2017-10-021-5/+21
| | | | | | | We warn about a structured binding declaration being unused only if none of its bindings are used. llvm-svn: 314733
* Dependent Address Space SupportAndrew Gozillon2017-10-021-1/+3
| | | | | | | | | | | | | | 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
* Consolidate std::move() detection code. No behavior change.Nico Weber2017-09-281-8/+3
| | | | llvm-svn: 314427
* Emit section information for extern variables. Erich Keane2017-09-261-0/+10
| | | | | | | | | | | | | | | | | Currently, if _attribute_((section())) is used for extern variables, section information is not emitted in generated IR when the variables are used. This is expected since sections are not generated for external linkage objects. However NiosII requires this information as it uses special GP-relative accesses for any objects that use attribute section (.sdata). GCC keeps this attribute in middle-end. This change emits the section information for all targets. Patch By: Elizabeth Andrews Differential Revision:https://reviews.llvm.org/D36487 llvm-svn: 314262
* Fix tracking of whether a destructor would be deleted.Richard Smith2017-09-221-1/+3
| | | | | | | | | | I've been unable to find any cases whose behavior is actually changed by this, but only because an implicitly deleted destructor also results in it being impossible to have a trivial (non-deleted) copy constructor, which the place where this really matters (choosing whether to pass a class in registers) happens to also check. llvm-svn: 313948
* [fixup][Sema] Allow in C to define tags inside enumerations.Volodymyr Sapsai2017-09-211-1/+2
| | | | | | | | | | | | | | | | Fix for too aggressive error err_type_defined_in_enum introduced in r313386. Defining tags inside enumerations is prohibited in C++ but allowed in C. Reviewers: aaron.ballman, rnk, doug.gregor Reviewed By: rnk Subscribers: alberto_magni, cfe-commits Differential Revision: https://reviews.llvm.org/D38109 llvm-svn: 313894
* Implement C++ [basic.link]p8.Richard Smith2017-09-201-13/+1
| | | | | | | | | | | | | | If a function or variable has a type with no linkage (and is not extern "C"), any use of it requires a definition within the same translation unit; the idea is that it is not possible to define the entity elsewhere, so any such use is necessarily an error. There is an exception, though: some types formally have no linkage but nonetheless can be referenced from other translation units (for example, this happens to anonymous structures defined within inline functions). For entities with those types, we suppress the diagnostic except under -pedantic. llvm-svn: 313729
* [Sema] Error out early for tags defined inside an enumeration.Volodymyr Sapsai2017-09-151-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | This fixes PR28903 by avoiding access check for inner enum constant. We are performing access check because one enum constant references another and because enum is defined in CXXRecordDecl. But access check doesn't work because FindDeclaringClass doesn't expect more than one EnumDecl and because inner enum has access AS_none due to not being an immediate child of a record. The change detects an enum is defined in wrong place and allows to skip parsing its body. Access check is skipped together with body parsing. There was no crash in C, added test case to cover the new error. rdar://problem/28530809 Reviewers: rnk, doug.gregor, rsmith Reviewed By: doug.gregor Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D37089 llvm-svn: 313386
* Recommit "Add _Float16 as a C/C++ source language type"Sjoerd Meijer2017-09-081-0/+1
| | | | | | | | This is a recommit of r312781; in some build configurations variable names are omitted, so changed the new regression test accordingly. llvm-svn: 312794
* Revert "Add _Float16 as a C/C++ source language type"Sjoerd Meijer2017-09-081-1/+0
| | | | | | | The clang-with-lto-ubuntu bot didn't like the new regression test, revert while I investigate the issue. llvm-svn: 312784
* Add _Float16 as a C/C++ source language typeSjoerd Meijer2017-09-081-0/+1
| | | | | | | | | | | This adds _Float16 as a source language type, which is a 16-bit floating point type defined in C11 extension ISO/IEC TS 18661-3. In follow up patches documentation and more tests will be added. Differential Revision: https://reviews.llvm.org/D33719 llvm-svn: 312781
* Add IDNS_Tag to C++ declarations that conflict with tag declarations.Richard Smith2017-09-071-10/+8
| | | | | | | Fixes some accepts-invalids with tags and other declarations declared in the same scope. llvm-svn: 312743
* Implement Itanium name mangling support for C++ Modules TS.Richard Smith2017-09-041-8/+12
| | | | | | | | | | | | This follows the scheme agreed with Nathan Sidwell, which can be found here: https://gcc.gnu.org/wiki/cxx-modules?action=AttachFile This will be proposed to the itanium-cxx-abi list once we have some experience with how well it works; the ABI for this TS should be considered unstable until it is part of the Itanium C++ ABI. llvm-svn: 312467
* Set the lexical context for dummy tag decl inside createTagFromNewDeclAlex Lorenz2017-08-141-1/+1
| | | | | | | This is a follow-up to r310706. This change has been recommended by Bruno Cardoso Lopes and Richard Smith. llvm-svn: 310829
* Rename cxx1z -> cxx17 across all diagnostic IDs.Richard Smith2017-08-131-1/+1
| | | | llvm-svn: 310805
* PR34163: Don't cache an incorrect key function for a class if queried betweenRichard Smith2017-08-121-2/+3
| | | | | | | | | | | the class becoming complete and its inline methods being parsed. This replaces the hack of using the "late parsed template" flag to track member functions with bodies we've not parsed yet; instead we now use the "will have body" flag, which carries the desired implication that the function declaration *is* a definition, and that we've just not parsed its body yet. llvm-svn: 310776
* [modules] Set the lexical DC for dummy tag decls that refer to hiddenAlex Lorenz2017-08-111-0/+1
| | | | | | | | | | | | | | declarations that are made visible after the dummy is parsed and ODR verified Prior to this commit the "(getContainingDC(DC) == CurContext && "The next DeclContext should be lexically contained in the current one.")," assertion failure was triggered during semantic analysis of the dummy tag declaration that was declared in another tag declaration because its lexical context did not point to the outer tag decl. rdar://32292196 llvm-svn: 310706
* Place implictly declared functions at block scopeMomchil Velikov2017-08-101-2/+6
| | | | | | | | | | | | Such implicitly declared functions behave as if the enclosing block contained the declaration extern int name() (C90, 6.3.3.2 Function calls), thus their names should have block scope (C90, 6.1.2.1 Scope of identifiers). This patch fixes https://bugs.llvm.org/show_bug.cgi?id=33224 Differential Revision: https://reviews.llvm.org/D33676 llvm-svn: 310616
* Fix -Wshadow false positives with function-local classes.Alexander Kornienko2017-07-311-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fixes http://llvm.org/PR33947. https://godbolt.org/g/54XRMT void f(int a) { struct A { void g(int a) {} A() { int a; } }; } 3 : <source>:3:16: warning: declaration shadows a local variable [-Wshadow] void g(int a) {} ^ 1 : <source>:1:12: note: previous declaration is here void f(int a) { ^ 4 : <source>:4:15: warning: declaration shadows a local variable [-Wshadow] A() { int a; } ^ 1 : <source>:1:12: note: previous declaration is here void f(int a) { ^ 2 warnings generated. The local variable `a` of the function `f` can't be accessed from a method of the function-local class A, thus no shadowing occurs and no diagnostic is needed. Reviewers: rnk, rsmith, arphaman, Quuxplusone Reviewed By: rnk, Quuxplusone Subscribers: Quuxplusone, cfe-commits Differential Revision: https://reviews.llvm.org/D35941 llvm-svn: 309569
* [modules ts] Declarations from a module interface unit are only visible outsideRichard Smith2017-07-051-12/+23
| | | | | | the module if declared in an export block. llvm-svn: 307115
* [modules] Teach clang how to merge typedef over anonymous structs in C mode.Vassil Vassilev2017-07-011-3/+2
| | | | | | | | | | In C mode clang fails to merge the textually included definition with the one imported from a module. The C lookup rules fail to find the imported definition because its linkage is internal in non C++ mode. This patch reinstates some of the ODR merging rules for typedefs of anonymous tags for languages other than C++. Patch by Raphael Isemann and me (D34510). llvm-svn: 306964
* fix trivial typos; NFCHiroshi Inoue2017-07-011-1/+1
| | | | llvm-svn: 306954
* [Modules] Implement ODR-like semantics for tag types in C/ObjCBruno Cardoso Lopes2017-07-011-6/+77
| | | | | | | | | | | | | | | | | | | | | | Allow ODR for ObjC/C in the sense that we won't keep more that one definition around (merge them). However, ensure the decl pass the structural compatibility check in C11 6.2.7/1, for that, reuse the structural equivalence checks used by the ASTImporter. Few other considerations: - Create error diagnostics for tag types mismatches and thread them into the structural equivalence checks. - Note that by doing this we only support redefinition between types that are considered "compatible types" by C. This is mixed approach of the suggestions discussed in http://lists.llvm.org/pipermail/cfe-dev/2017-March/053257.html Differential Revision: https://reviews.llvm.org/D31778 rdar://problem/31909368 llvm-svn: 306918
OpenPOWER on IntegriCloud