summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaDecl.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [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
* [modules] Switch from inferring owning modules based on source location toRichard Smith2017-05-181-37/+28
| | | | | | | | | | | | | | | inferring based on the current module at the point of creation. This should result in no functional change except when building a preprocessed module (or more generally when using #pragma clang module begin/end to switch module in the middle of a file), in which case it allows us to correctly track the owning module for declarations. We can't map from FileID to module in the preprocessed module case, since all modules would have the same FileID. There are still a couple of remaining places that try to infer a module from a source location; I'll clean those up in follow-up changes. llvm-svn: 303322
* [modules] When creating a declaration, cache its owning module immediatelyRichard Smith2017-05-171-0/+15
| | | | | | | | | | | | | | | rather than waiting until it's queried. Currently this is only applied to local submodule visibility mode, as we don't yet allocate storage for the owning module in non-local-visibility modules compilations. This reinstates r302965, reverted in r303037, with a fix for the reported crash, which occurred when reparenting a local declaration to be a child of a hidden imported declaration (specifically during template instantiation). llvm-svn: 303224
* [OpenCL] Emit function-scope variable in constant address space as static ↵Yaxun Liu2017-05-151-11/+24
| | | | | | | | variable Differential Revision: https://reviews.llvm.org/D32977 llvm-svn: 303072
* Revert r302965 - [modules] When creating a declaration, cache its owningDaniel Jasper2017-05-151-15/+0
| | | | | | | | | module immediately Also revert dependent r302969. This is leading to crashes. Will provide more details reproduction instructions to Richard. llvm-svn: 303037
* Add LangOptions method to query whether we are tracking the owning module ↵Richard Smith2017-05-131-2/+2
| | | | | | | | for a local declaration. In preparation for expanding this behavior to cover additional cases. llvm-svn: 302969
* [modules] When creating a declaration, cache its owning module immediatelyRichard Smith2017-05-121-0/+15
| | | | | | | | | | rather than waiting until it's queried. Currently this is only applied to local submodule visibility mode, as we don't yet allocate storage for the owning module in non-local-visibility modules compilations. llvm-svn: 302965
* Remove unnecessary mapping from SourceLocation to Module.Richard Smith2017-05-111-7/+6
| | | | | | | | When we parse a redefinition of an entity for which we have a hidden existing declaration, make it visible in the current module instead of mapping the current source location to its containing module. llvm-svn: 302842
* [Sema] Improve redefinition errors pointing to the same headerBruno Cardoso Lopes2017-05-111-17/+82
| | | | | | | | | | | | | | | | | | Diagnostics related to redefinition errors that point to the same header file do not provide much information that helps users fixing the issue. - In the modules context, it usually happens because of non modular includes. - When modules aren't involved it might happen because of the lack of header guards. Enhance diagnostics in these scenarios. Differential Revision: https://reviews.llvm.org/D28832 rdar://problem/31669175 llvm-svn: 302765
* Improve diagnosis of unknown template name.Richard Smith2017-05-101-20/+60
| | | | | | | | | When an undeclared identifier in a context that requires a type is followed by '<', only look for type templates when typo-correcting, tweak the diagnostic text to say that a template name (not a type name) was undeclared, and parse the template arguments when recovering from the error. llvm-svn: 302732
* Don't mark a member as a member specialization until we know we're keeping ↵Richard Smith2017-05-091-3/+22
| | | | | | | | | | | | | | | | | | | | | | | | | the specialization. This improves our behavior in a few ways: * We now guarantee that if a member is marked as being a member specialization, there will actually be a member specialization declaration somewhere on its redeclaration chain. This fixes a crash in modules builds where we would try to check that there was a visible declaration of the member specialization and be surprised to not find any declaration of it at all. * We don't set the source location of the in-class declaration of the member specialization to the out-of-line declaration's location until we have actually finished merging them. This fixes some very silly looking diagnostics, where we'd point a "previous declaration is here" note at the same declaration we're complaining about. Ideally we wouldn't mess with the prior declaration's location at all, but too much code assumes that the first declaration of an entity is a reasonable thing to use as an indication of where it was declared, and that's not really true for a member specialization unless we fake it like this. llvm-svn: 302596
* Reland "Warn about unused static file scope function template declarations."Vassil Vassilev2017-05-091-5/+4
| | | | | | | This patch reinstates r299930, reverted in r299956, as a separate diagnostic option (-Wunused-template). llvm-svn: 302518
* [OpenCL] Check that global samplers are constSven van Haastregt2017-05-081-6/+18
| | | | | | | | Patch by Simon Perretta. Differential Revision: https://reviews.llvm.org/D32856 llvm-svn: 302411
* Add support for building modules from preprocessed source.Richard Smith2017-05-051-6/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To support this, an optional marker "#pragma clang module contents" is recognized in module map files, and the rest of the module map file from that point onwards is treated as the source of the module. Preprocessing a module map produces the input module followed by the marker and then the preprocessed contents of the module. Ignoring line markers, a preprocessed module might look like this: module A { header "a.h" } #pragma clang module contents #pragma clang module begin A // ... a.h ... #pragma clang module end The preprocessed output generates line markers, which are not accepted by the module map parser, so -x c++-module-map-cpp-output should be used to compile such outputs. A couple of major parts do not work yet: 1) The files that are listed in the module map must exist on disk, in order to build the on-disk header -> module lookup table in the PCM file. To fix this, we need the preprocessed output to track the file size and other stat information we might use to build the lookup table. 2) Declaration ownership semantics don't work properly yet, since mapping from a source location to a module relies on mapping from FileIDs to modules, which we can't do if module transitions can occur in the middle of a file. llvm-svn: 302309
* Reusing an existing attribute diagnosticOren Ben Simhon2017-05-031-1/+2
| | | | | | | | | In a previous patch, a new generic error diagnostic for inconsistent attributes was added. In this commit I reuse this diagnostic for ns_returns_retained attribute check. Differential Revision: https://reviews.llvm.org/D32697 llvm-svn: 302024
* [Sema] Avoid an invalid redefinition error that was presented forAlex Lorenz2017-04-281-0/+11
| | | | | | | | | | of a function whose previous definition was typo-corrected rdar://28550928 Differential Revision: https://reviews.llvm.org/D25113 llvm-svn: 301643
* [X86] Support of no_caller_saved_registers attributeOren Ben Simhon2017-04-271-0/+14
| | | | | | | | | Implements the Clang part for no_caller_saved_registers attribute as appears here: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5ed3cc7b66af4758f7849ed6f65f4365be8223be. Differential Revision: https://reviews.llvm.org/D31871 llvm-svn: 301535
* [Sema] Avoid using a null type pointer (fixes PR32750)Vedant Kumar2017-04-261-1/+1
| | | | | | | | | | isMicrosoftMissingTypename() uses a Type pointer without first checking that it's non-null. PR32750 reports a case where the pointer is in fact null. This patch adds in a defensive check and a regression test. Differential Revision: https://reviews.llvm.org/D32519 llvm-svn: 301420
* [modules ts] Diagnose 'export' declarations outside of a module interface.Richard Smith2017-04-241-0/+6
| | | | llvm-svn: 301271
* P0629R0: Switch to latest proposal for distinguishing module interface from ↵Richard Smith2017-04-211-16/+27
| | | | | | | | | | | | implementation. This switches from the prototype syntax in P0273R0 ('module' and 'module implementation') to the consensus syntax 'export module' and 'module'. In passing, drop the "module declaration must be first" enforcement, since EWG seems to have changed its mind on that. llvm-svn: 301056
* [ms] Give -Wmicrosoft-enum-forward-reference a chance to fire in clang-cl, ↵Nico Weber2017-04-211-1/+2
| | | | | | | | | | | | | | | | | | PR32736 clang-cl sets MicrosoftCompat. In that mode, we always give enums a fixed underlying type, and for enums with fixed underlying type we never enter the block that tries to emit ext_ms_forward_ref_enum. Fix this by requiring an explicit underlying type when we're skipping this diagnostic. We had a test for this warning, but it only ran in C++98 mode. clang-cl always enables -std=c++14, so MicrosoftCompatibiliy-cxx98.cpp is a fairly useless test. Fold it into MicrosoftCompatibility.cpp -- that way, the test checks if -Wmicrosoft-enum-forward-reference can fire in clang-cl builds. https://reviews.llvm.org/D32369 llvm-svn: 301032
* Add support for editor placeholders to ClangAlex Lorenz2017-04-191-0/+3
| | | | | | | | | | | | | | | | | | | | | This commit teaches Clang to recognize editor placeholders that are produced when an IDE like Xcode inserts a code-completion result that includes a placeholder. Now when the lexer sees a placeholder token, it emits an 'editor placeholder in source file' error and creates an identifier token that represents the placeholder. The parser/sema can now recognize the placeholders and can suppress the diagnostics related to the placeholders. This ensures that live issues in an IDE like Xcode won't get spurious diagnostics related to placeholders. This commit also adds a new compiler option named '-fallow-editor-placeholders' that silences the 'editor placeholder in source file' error. This is useful for an IDE like Xcode as we don't want to display those errors in live issues. rdar://31581400 Differential Revision: https://reviews.llvm.org/D32081 llvm-svn: 300667
* Add #pragma clang attributeAlex Lorenz2017-04-181-0/+2
| | | | | | | | | | | | | | | | | This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
* Revert r300539 - Add #pragma clang attributeAlex Lorenz2017-04-181-2/+0
| | | | | | | Some tests fail on the Windows buildbots. I will have to investigate more. This commit reverts r300539, r300540 and r300542. llvm-svn: 300543
* Add #pragma clang attributeAlex Lorenz2017-04-181-0/+2
| | | | | | | | | | | | | | The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300539
* [ODRHash] Improve handling of hash valuesRichard Trieu2017-04-111-3/+1
| | | | | | | | | | | Calculating the hash in Sema::ActOnTagFinishDefinition could happen before all sub-Decls were parsed or processed, which would produce the wrong hash value. Change to calculating the hash on the first use and storing the value instead. Also, avoid using the macros that were only for Boolean fields and use an explicit checker during the DefintionData merge. No functional change, but was this blocking other ODRHash patches. llvm-svn: 299989
* Revert temporarily D29877 "Warn about unused static file scope function ↵Vassil Vassilev2017-04-111-4/+5
| | | | | | | | | | | | | template declarations." We need to address cases (breaking libc++) such as template <class _Up> static int __test(...); template<typename _Tp> auto v = __test<_Tp>(0); llvm-svn: 299956
* Warn about unused static file scope function template declarations.Vassil Vassilev2017-04-111-5/+4
| | | | | | Reviewed by Richard Smith (D29877)! llvm-svn: 299930
* Simplify. NFC.George Burgess IV2017-04-061-8/+4
| | | | | | | | | | | | Two simplifications: - We check `!Previous.empty()` above and only use `Previous` in const contexts after that check, so the `!Previous.empty()` check seems redundant. - The null check looks pointless, as well: AFAICT, `LookupResults` should never contain null entries, and `OldDecl` should always be non-null if `Redeclaration` is true. llvm-svn: 299601
* Don't issue a warning if the shadowing declaration is in a classStephan Bergmann2017-04-051-0/+4
| | | | | | | | | | | Follow-up to r299363 "Enhance -Wshadow to warn when shadowing typedefs or type aliases". Patch by Ahmed Asadi. Differential Revision: https://reviews.llvm.org/D31235 llvm-svn: 299522
OpenPOWER on IntegriCloud