summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaDecl.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* [Sema] Allow unmarked overloadable functions.George Burgess IV2017-06-271-24/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch extends the `overloadable` attribute to allow for one function with a given name to not be marked with the `overloadable` attribute. The overload without the `overloadable` attribute will not have its name mangled. So, the following code is now legal: void foo(void) __attribute__((overloadable)); void foo(int); void foo(float) __attribute__((overloadable)); In addition, this patch fixes a bug where we'd accept code with `__attribute__((overloadable))` inconsistently applied. In other words, we used to accept: void foo(void); void foo(void) __attribute__((overloadable)); But we will do this no longer, since it defeats the original purpose of requiring `__attribute__((overloadable))` on all redeclarations of a function. This breakage seems to not be an issue in practice, since the only code I could find that had this pattern often looked like: void foo(void); void foo(void) __attribute__((overloadable)) __asm__("foo"); void foo(int) __attribute__((overloadable)); ...Which can now be simplified by simply removing the asm label and overloadable attribute from the redeclaration of `void foo(void);` Differential Revision: https://reviews.llvm.org/D32332 llvm-svn: 306467
* Check that the initializer of a non-dependent constexpr variable is constant ↵Richard Smith2017-06-261-3/+1
| | | | | | even within templates. llvm-svn: 306327
* [Sema] Fix a crash-on-invalid when a template parameter list has a classAkira Hatanaka2017-06-261-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | definition or non-reference class type. The crash occurs when there is a template parameter list in a class that is missing the closing angle bracket followed by a definition of a struct. For example: class C0 { public: template<typename T, typename T1 = T // missing closing angle bracket struct S0 {}; C0() : m(new S0<int>) {} S0<int> *m; }; This happens because the parsed struct is added to the scope of the enclosing class without having its access specifier set, which results in an assertion failure in SemaAccess.cpp later. This commit fixes the crash by adding the parsed struct to the enclosing file scope and marking structs as invalid if they are defined in template parameter lists. rdar://problem/31783961 rdar://problem/19570630 Differential Revision: https://reviews.llvm.org/D33606 llvm-svn: 306317
* PR33552: Distinguish between declarations that are owned by no module andRichard Smith2017-06-231-2/+6
| | | | | | | | | | | | | | | | | | | declarations that are owned but unconditionally visible. This allows us to set declarations as visible even if they have a local owning module, without losing information. In turn, that means that our Objective-C support can keep on incorrectly assuming the "hidden" bit on the declaration is the whole story with regard to name visibility. This will also be useful once we support the C++ Modules TS export semantics. Objective-C name visibility is still incorrect in any case where the "hidden" bit is not the complete story: for instance, in Objective-C++ the set of visible categories will be wrong during template instantiation, and with local submodule visibility enabled it will be wrong when building modules. Fixing that will require a major overhaul of how visibility is handled for Objective-C (and particularly for categories). llvm-svn: 306075
* Function with unparsed body is a definitionSerge Pavlov2017-06-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While a function body is being parsed, the function declaration is not considered as a definition because it does not have a body yet. In some cases it leads to incorrect interpretation, the case is presented in https://bugs.llvm.org/show_bug.cgi?id=14785: ``` template<typename T> struct Somewhat { void internal() const {} friend void operator+(int const &, Somewhat<T> const &) {} }; void operator+(int const &, Somewhat<char> const &x) { x.internal(); } ``` When statement `x.internal()` in the body of global `operator+` is parsed, the type of `x` must be completed, so the instantiation of `Somewhat<char>` is started. It instantiates the declaration of `operator+` defined inline, and makes a check for redefinition. The check does not detect another definition because the declaration of `operator+` is still not defining as does not have a body yet. To solves this problem the function `isThisDeclarationADefinition` considers a function declaration as a definition if it has flag `WillHaveBody` set. This change fixes PR14785. Differential Revision: https://reviews.llvm.org/D30375 This is a recommit of 305379, reverted in 305381, with small changes. llvm-svn: 305903
* [OpenCL] Diagnose scoped address-space qualified variablesAnastasia Stulova2017-06-201-2/+16
| | | | | | | | | | | | Produce an error if variables qualified with a local or a constant address space are not declared in the outermost scope of a kernel. Patch by Simon Perretta. Differential Revision: https://reviews.llvm.org/D34024 llvm-svn: 305798
* Reverted 305379 (Function with unparsed body is a definition)Serge Pavlov2017-06-141-1/+0
| | | | | | It broke clang-x86_64-linux-selfhost-modules-2 and some other buildbots. llvm-svn: 305381
* Function with unparsed body is a definitionSerge Pavlov2017-06-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | While a function body is being parsed, the function declaration is not considered as a definition because it does not have a body yet. In some cases it leads to incorrect interpretation, the case is presented in https://bugs.llvm.org/show_bug.cgi?id=14785: ``` template<typename T> struct Somewhat { void internal() const {} friend void operator+(int const &, Somewhat<T> const &) {} }; void operator+(int const &, Somewhat<char> const &x) { x.internal(); } ``` When statement `x.internal()` in the body of global `operator+` is parsed, the type of `x` must be completed, so the instantiation of `Somewhat<char>` is started. It instantiates the declaration of `operator+` defined inline, and makes a check for redefinition. The check does not detect another definition because the declaration of `operator+` is still not defining as does not have a body yet. To solves this problem the function `isThisDeclarationADefinition` considers a function declaration as a definition if it has flag `WillHaveBody` set. This change fixes PR14785. Differential Revision: https://reviews.llvm.org/D30375 llvm-svn: 305379
* Add support for #pragma clang sectionJaved Absar2017-06-051-0/+25
| | | | | | | | | | | | | | | This patch provides a means to specify section-names for global variables, functions and static variables, using #pragma directives. This feature is only defined to work sensibly for ELF targets. One can specify section names as: #pragma clang section bss="myBSS" data="myData" rodata="myRodata" text="myText" One can "unspecify" a section name with empty string e.g. #pragma clang section bss="" data="" text="" rodata="" Reviewers: Roger Ferrer, Jonathan Roelofs, Reid Kleckner Differential Revision: https://reviews.llvm.org/D33412 llvm-svn: 304705
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-06-031-0/+1
| | | | llvm-svn: 304651
* [OpenCL] Harden function pointer diagnostics.Alexey Bader2017-06-021-1/+1
| | | | | | | | | | | | | | Summary: Improve OpenCL type checking by rejecting function pointer types. Reviewers: Anastasia, yaxunl Reviewed By: Anastasia Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33821 llvm-svn: 304575
* [Sema] Improve -Wstrict-prototypes diagnostic message for blocks.Akira Hatanaka2017-06-021-1/+1
| | | | | | | | | | | Print "this block declaration is not a prototype" for non-prototype declarations of blocks instead of "this function declaration ...". rdar://problem/32461723 Differential Revision: https://reviews.llvm.org/D33739 llvm-svn: 304507
* [SemaCXX] Add diagnostics to require_constant_initializationKeno Fischer2017-06-011-0/+11
| | | | | | | | | | | | | Summary: This hooks up the detailed diagnostics of why constant initialization was not possible if require_constant_initialization reports an error. I have updated the test to account for the new notes. Reviewed By: EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D24371 llvm-svn: 304451
* [OpenCL] Added diagnostic for implicit declaration of function in OpenCLEgor Churaev2017-05-301-0/+3
| | | | | | | | | | | | Reviewers: Anastasia, cfe-commits Reviewed By: Anastasia Subscribers: bader, yaxunl Differential Revision: https://reviews.llvm.org/D31745 llvm-svn: 304193
* [OpenCL] reserve_id_t cannot be used as argument to kernel functionEgor Churaev2017-05-251-4/+1
| | | | | | | | | | | | Reviewers: Anastasia Reviewed By: Anastasia Subscribers: yaxunl, cfe-commits, bader Differential Revision: https://reviews.llvm.org/D33483 llvm-svn: 303846
* [coroutines] Fix fallthrough diagnostics for coroutinesEric Fiselier2017-05-251-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: This patch fixes a number of issues with the analysis warnings emitted when a coroutine may reach the end of the function w/o returning. * Fix bug where coroutines with `return_value` are incorrectly diagnosed as missing `co_return`'s. * Rework diagnostic message to no longer say "non-void coroutine", because that implies the coroutine doesn't have a void return type, which it might. In this case a non-void coroutine is one who's promise type does not contain `return_void()` As a side-effect of this patch, coroutine bodies that contain an invalid coroutine promise objects are marked as invalid. Reviewers: GorNishanov, rsmith, aaron.ballman, majnemer Reviewed By: GorNishanov Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33532 llvm-svn: 303831
* [OPENMP] Allow value of thread local variables in target regions.Alexey Bataev2017-05-241-3/+6
| | | | | | | | | If the variable is marked as TLS variable and target device does not support TLS, the error is emitted for the variable even if it is not used in target regions. Patch fixes this and allows to use the values of the TLS variables in target regions. llvm-svn: 303768
* [Modules] Fix overly conservative assertion for import diagnosticBruno Cardoso Lopes2017-05-231-1/+2
| | | | | | | | | | | | | | | | We currenltly assert when want to diagnose a missing import and the decl in question is already visible. It turns out that the decl in question might be visible because another decl from the same module actually made the module visible in a previous error diagnostic. Remove the assertion and avoid re-exporting the module if it's already visible. rdar://problem/27975402 Differential Revision: https://reviews.llvm.org/D32828 llvm-svn: 303705
* When we enter a module within a linkage specification, switch the linkageRichard Smith2017-05-181-5/+11
| | | | | | | | | | specification and the TU to the new module. This is necessary to get the module ownership correct for entities that we temporarily hang off the TranslationUnitDecl, such as template parameters and function parameters. llvm-svn: 303373
* CodeGen: Cast alloca to expected address spaceYaxun Liu2017-05-181-1/+6
| | | | | | | | | | | Alloca always returns a pointer in alloca address space, which may be different from the type defined by the language. For example, in C++ the auto variables are in the default address space. Therefore cast alloca to the expected address space when necessary. Differential Revision: https://reviews.llvm.org/D32248 llvm-svn: 303370
* Fix an assertion failure in FormatASTNodeDiagnosticArgument.Alexander Kornienko2017-05-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The test being added in this patch used to cause an assertion failure: /build/./bin/clang -cc1 -internal-isystem /build/lib/clang/5.0.0/include -nostdsysteminc -verify -fsyntax-only -std=c++11 -Wshadow-all /src/tools/clang/test/SemaCXX/warn-shadow.cpp -- Exit Code: 134 Command Output (stderr): -- clang: /src/tools/clang/lib/AST/ASTDiagnostic.cpp:424: void clang::FormatASTNodeDiagnosticArgument(DiagnosticsEngine::ArgumentKind, intptr_t, llvm::StringRef, llvm::StringRef, ArrayRef<DiagnosticsEngine::ArgumentValue>, SmallVectorImpl<char> &, void *, ArrayRef<intptr_t>): Assertion `isa<NamedDecl>(DC) && "Expected a NamedDecl"' failed. #0 0x0000000001c7a1b4 PrintStackTraceSignalHandler(void*) (/build/./bin/clang+0x1c7a1b4) #1 0x0000000001c7a4e6 SignalHandler(int) (/build/./bin/clang+0x1c7a4e6) #2 0x00007f30880078d0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0xf8d0) #3 0x00007f3087054067 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35067) #4 0x00007f3087055448 abort (/lib/x86_64-linux-gnu/libc.so.6+0x36448) #5 0x00007f308704d266 (/lib/x86_64-linux-gnu/libc.so.6+0x2e266) #6 0x00007f308704d312 (/lib/x86_64-linux-gnu/libc.so.6+0x2e312) #7 0x00000000035b7f22 clang::FormatASTNodeDiagnosticArgument(clang::DiagnosticsEngine::ArgumentKind, long, llvm::StringRef, llvm::StringRef, llvm::ArrayRef<std::pair<clang::DiagnosticsEngine::ArgumentKind, long> >, llvm::SmallVectorImpl<char>&, void*, llvm::ArrayRef<long>) (/build/ ./bin/clang+0x35b7f22) #8 0x0000000001ddbae4 clang::Diagnostic::FormatDiagnostic(char const*, char const*, llvm::SmallVectorImpl<char>&) const (/build/./bin/clang+0x1ddbae4) #9 0x0000000001ddb323 clang::Diagnostic::FormatDiagnostic(char const*, char const*, llvm::SmallVectorImpl<char>&) const (/build/./bin/clang+0x1ddb323) #10 0x00000000022878a4 clang::TextDiagnosticBuffer::HandleDiagnostic(clang::DiagnosticsEngine::Level, clang::Diagnostic const&) (/build/./bin/clang+0x22878a4) #11 0x0000000001ddf387 clang::DiagnosticIDs::ProcessDiag(clang::DiagnosticsEngine&) const (/build/./bin/clang+0x1ddf387) #12 0x0000000001dd9dea clang::DiagnosticsEngine::EmitCurrentDiagnostic(bool) (/build/./bin/clang+0x1dd9dea) #13 0x0000000002cad00c clang::Sema::EmitCurrentDiagnostic(unsigned int) (/build/./bin/clang+0x2cad00c) #14 0x0000000002d91cd2 clang::Sema::CheckShadow(clang::NamedDecl*, clang::NamedDecl*, clang::LookupResult const&) (/build/./bin/clang+0x2d91cd2) Stack dump: 0. Program arguments: /build/./bin/clang -cc1 -internal-isystem /build/lib/clang/5.0.0/include -nostdsysteminc -verify -fsyntax-only -std=c++11 -Wshadow-all /src/tools/clang/test/SemaCXX/warn-shadow.cpp 1. /src/tools/clang/test/SemaCXX/warn-shadow.cpp:214:23: current parser token ';' 2. /src/tools/clang/test/SemaCXX/warn-shadow.cpp:213:26: parsing function body 'handleLinkageSpec' 3. /src/tools/clang/test/SemaCXX/warn-shadow.cpp:213:26: in compound statement ('{}') /build/tools/clang/test/SemaCXX/Output/warn-shadow.cpp.script: line 1: 15595 Aborted (core dumped) /build/./bin/clang -cc1 -internal-isystem /build/lib/clang/5.0.0/include -nostdsysteminc -verify -fsyntax-only -std=c++11 -Wshadow-all /src/tools/clang/test/SemaCXX/warn-shadow.cpp Reviewers: rsmith Reviewed By: rsmith Subscribers: krytarowski, cfe-commits Differential Revision: https://reviews.llvm.org/D33207 llvm-svn: 303325
OpenPOWER on IntegriCloud