summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert "[OPENMP]Fix PR41767: diagnose DSA for variables in clauses with ↵Roman Lebedev2019-05-091-96/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | default(none)." This implementation isn't sound as per the standard. It erroneously diagnoses e.g. the following case: ``` $ cat test.cpp void f(int n) { #pragma omp parallel default(none) if(n) ; } ``` ``` $ ./bin/clang -fopenmp test.cpp test.cpp:2:40: error: variable 'n' must have explicitly specified data sharing attributes #pragma omp parallel default(none) if(n) ^ test.cpp:2:31: note: explicit data sharing attribute requested here #pragma omp parallel default(none) if(n) ^ 1 error generated. ``` As per OpenMP Application Programming Interface Version 5.0 November 2018: * 2.19.4.1default Clause The default clause explicitly determines the data-sharing attributes of variables that are referenced *in a parallel, teams, or task generating construct and would otherwise be implicitly determined (see Section 2.19.1.1 on page 270). * 2.6.1 Determining the Number of Threads for a parallel Region Using a variable in an if or num_threads clause expression of a parallel construct causes an implicit reference to the variable in all enclosing constructs. The if clause expression and the num_threads clause expression are evaluated in the context outside of the parallel construct, This reverts commit r360073. llvm-svn: 360326
* [c++20] Add support for explicit(bool), as described in P0892R2.Richard Smith2019-05-0910-161/+287
| | | | | | | | Patch by Tyker! Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360311
* [c++20] Implement P0846R0: allow (ADL-only) calls to template-ids whoseRichard Smith2019-05-097-73/+224
| | | | | | | | | | | | | | | | | | | | | | | | | template name is not visible to unqualified lookup. In order to support this without a severe degradation in our ability to diagnose typos in template names, this change significantly restructures the way we handle template-id-shaped syntax for which lookup of the template name finds nothing. Instead of eagerly diagnosing an undeclared template name, we now form a placeholder template-name representing a name that is known to not find any templates. When the parser sees such a name, it attempts to disambiguate whether we have a less-than comparison or a template-id. Any diagnostics or typo-correction for the name are delayed until its point of use. The upshot should be a small improvement of our diagostic quality overall: we now take more syntactic context into account when trying to resolve an undeclared identifier on the left hand side of a '<'. In fact, this works well enough that the backwards-compatible portion (for an undeclared identifier rather than a lookup that finds functions but no function templates) is enabled in all language modes. llvm-svn: 360308
* When typo-correcting a function name, consider correcting to a type nameRichard Smith2019-05-092-3/+12
| | | | | | for a function-style cast. llvm-svn: 360302
* [Sema][OpenCL] Make address space conversions a bit stricter.Anastasia Stulova2019-05-082-16/+55
| | | | | | | | | | | | | | | | | | | | | | | | The semantics for converting nested pointers between address spaces are not very well defined. Some conversions which do not really carry any meaning only produce warnings, and in some cases warnings hide invalid conversions, such as 'global int*' to 'local float*'! This patch changes the logic in checkPointerTypesForAssignment and checkAddressSpaceCast to fail properly on implicit conversions that should definitely not be permitted. We also dig deeper into the pointer types and warn on explicit conversions where the address space in a nested pointer changes, regardless of whether the address space is compatible with the corresponding pointer nesting level on the destination type. Fixes PR39674! Patch by ebevhan (Bevin Hansson)! Differential Revision: https://reviews.llvm.org/D58236 llvm-svn: 360258
* Allow 'static' storage specifier on an out-of-line class member template ↵Aaron Ballman2019-05-081-2/+5
| | | | | | | | declaration in MSVCCompat mode. Patch by Soumi Manna. llvm-svn: 360250
* Fix for the greendragon bots.Leonard Chan2019-05-081-1/+3
| | | | | | Adds extra checks for ObjC GC and Ownership. llvm-svn: 360225
* [Sema] Correct typos in return statements so the return types of 'auto' ↵Sam McCall2019-05-081-1/+7
| | | | | | | | | | | | | | | | | | | | | functions are always deduced. Summary: e.g. auto foo() { return no_such_thing; // Return value is a TypoExpr } using T = decltype(foo()); // Uh-oh, undeduced auto. Reviewers: rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61649 llvm-svn: 360224
* Split ActOnCallExpr into an ActOnCallExpr to be called by the parser,Richard Smith2019-05-089-23/+29
| | | | | | | and a BuildCallExpr to be called internally within Sema to build / rebuild calls. llvm-svn: 360217
* [OpenCL] Prevent mangling kernel functions.Anastasia Stulova2019-05-071-10/+24
| | | | | | | | | | | | Kernel function names have to be preserved as in the original source to be able to access them from the host API side. This commit also adds restriction to kernels that prevents them from being used in overloading, templates, etc. Differential Revision: https://reviews.llvm.org/D60454 llvm-svn: 360152
* [Sema] Add missing VisitMacroQualifiedTypeLoc to TypeSpecLocFillerLeonard Chan2019-05-071-0/+5
| | | | | | To hopefully fix greenbot failures llvm-svn: 360120
* Improve function / variable disambiguation.Richard Smith2019-05-071-2/+20
| | | | | | | | Keep looking for decl-specifiers after an unknown identifier. Don't issue diagnostics about an error type specifier conflicting with later type specifiers. llvm-svn: 360117
* Recommit r359859 "[Attribute/Diagnostics] Print macro if definition is an ↵Leonard Chan2019-05-074-10/+80
| | | | | | | | attribute declaration" Updated with fix for read of uninitialized memory. llvm-svn: 360109
* [Sema] Fix for P41774 where `ExpectNoDerefChunk` is assigned twiceLeonard Chan2019-05-061-5/+2
| | | | llvm-svn: 360089
* PR41183: Don't emit strict-prototypes warning for an implicit functionJames Y Knight2019-05-061-1/+4
| | | | | | | | | | | declaration. It should emit _only_ an implicit-function-declaration warning, not both of them. Differential Revision: https://reviews.llvm.org/D59711 llvm-svn: 360084
* [OPENMP]Fix PR41767: diagnose DSA for variables in clauses withAlexey Bataev2019-05-061-3/+96
| | | | | | | | | | | default(none). If the combined directive has default(none) clause and has clauses for inner directive that reference some variables, for which data-sharing attributes are not specified, the error messages should be emitted for such variables. llvm-svn: 360073
* [OPENMP]Fix PR41768: check DSA for globals with `default(none)` clauses.Alexey Bataev2019-05-061-1/+7
| | | | | | | | If the `default(none)` was specified for the construct, we might miss diagnostic for the globals without explicitly specified data-sharing attributes. Patch fixes this problem. llvm-svn: 360061
* [CodeComplete] Add a trailing semicolons to some pattern completionsIlya Biryukov2019-05-061-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Where semicolon is required in any case. Here's a list of completions that now have a semicolon: - namespace <name> = <target>; - using namespace <name>; - using <qualifier>::<name>; - continue; - break; - goto <label>; - return; - return <expression>; Reviewers: gribozavr Reviewed By: gribozavr Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61589 llvm-svn: 360042
* Revert r359949 "[clang] adding explicit(bool) from c++2a"Hans Wennborg2019-05-0610-293/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused Clang to start erroring on the following: struct S {   template <typename = int> explicit S(); }; struct T : S {}; struct U : T {   U(); }; U::U() {} $ clang -c /tmp/x.cc /tmp/x.cc:10:4: error: call to implicitly-deleted default constructor of 'T' U::U() {}    ^ /tmp/x.cc:5:12: note: default constructor of 'T' is implicitly deleted because base class 'S' has no default constructor struct T : S {};            ^ 1 error generated. See discussion on the cfe-commits email thread. This also reverts the follow-ups r359966 and r359968. > this patch adds support for the explicit bool specifier. > > Changes: > - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. > - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. > - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. > - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. > - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. > - Test for Semantic and Serialization were added. > > This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. > Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. > > Patch by Tyker > > Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360024
* P1286R2: Remove restriction that the exception specification of aRichard Smith2019-05-062-67/+19
| | | | | | defaulted special member matches the implicit exception specification. llvm-svn: 360011
* Use DiagRuntimeBehavior for -Wunsequenced to weed out false positivesRichard Smith2019-05-063-18/+27
| | | | | | | | | where either the modification or the other access is unreachable. This reverts r359984 (which reverted r359962). The bug in clang-tidy's test suite exposed by the original commit was fixed in r360009. llvm-svn: 360010
* [c++20] Implement P1009R2: allow omitting the array bound in an arrayRichard Smith2019-05-062-34/+60
| | | | | | | | | | new expression. This was voted into C++20 as a defect report resolution, so we retroactively apply it to all prior language modes (though it can never actually be used before C++11 mode). llvm-svn: 360006
* Revert rL359962 : Use DiagRuntimeBehavior for -Wunsequenced to weed out ↵Simon Pilgrim2019-05-053-27/+18
| | | | | | | | | | false positives where either the modification or the other access is unreachable. ........ Try to fix buildbots llvm-svn: 359984
* [c++20] Implement P0428R2 - Familiar template syntax for generic lambdasHamza Sood2019-05-043-22/+42
| | | | | | Differential Revision: https://reviews.llvm.org/D36527 llvm-svn: 359967
* Use DiagRuntimeBehavior for -Wunsequenced to weed out false positivesRichard Smith2019-05-043-18/+27
| | | | | | where either the modification or the other access is unreachable. llvm-svn: 359962
* [clang] adding explicit(bool) from c++2aNicolas Lesser2019-05-0410-161/+293
| | | | | | | | | | | | | | | | | | | | | this patch adds support for the explicit bool specifier. Changes: - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. - Test for Semantic and Serialization were added. This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. Patch by Tyker Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 359949
* CWG issue 727: Fix numerous bugs in support for class-scope explicitRichard Smith2019-05-033-97/+108
| | | | | | specializations for variable templates. llvm-svn: 359947
* [COFF, ARM64] Fix ABI implementation of struct returnsMandeep Singh Grang2019-05-031-1/+4
| | | | | | | | | | | | | | | | | | Summary: Related llvm patch: D60348. Patch co-authored by Sanjin Sijaric. Reviewers: rnk, efriedma, TomTan, ssijaric, ostannard Reviewed By: efriedma Subscribers: dmajor, richard.townsend.arm, ostannard, javed.absar, kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60349 llvm-svn: 359932
* [Sema][ObjC] Disable -Wunused-parameter for ObjC methodsAkira Hatanaka2019-05-031-2/+0
| | | | | | | | | | The warning isn't very useful when the function is an ObjC method. rdar://problem/41561853 Differential Revision: https://reviews.llvm.org/D61147 llvm-svn: 359864
* Revert "[Attribute/Diagnostics] Print macro if definition is an attribute ↵Leonard Chan2019-05-034-57/+10
| | | | | | | | declaration" This reverts commit fc40cbd9d8c63e65eed3590ba925321afe782e1d. llvm-svn: 359859
* Revert r359814 "[Sema] Emit warning for visibility attribute on ↵Nico Weber2019-05-031-8/+0
| | | | | | | | internal-linkage declaration" See cfe-commits thread for r359814. llvm-svn: 359858
* SemaOverload: Complete candidates before emitting the error, to ensure ↵David Blaikie2019-05-035-173/+269
| | | | | | | | | | | | | | | | | diagnostics emitted (or suppressed) during completion don't interfere with the overload notes Because diagnostics and their notes are not connected at the API level, if the error message for an overload is emitted, then the overload candidates are completed - if a diagnostic is emitted during that work, the notes related to overload candidates would be attached to the latter diagnostic, not the original error. Sort of worse, if the latter diagnostic was disabled, the notes are disabled. Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D61357 llvm-svn: 359854
* [Attribute/Diagnostics] Print macro if definition is an attribute declarationLeonard Chan2019-05-024-10/+57
| | | | | | | | | | | | | If an address_space attribute is defined in a macro, print the macro instead when diagnosing a warning or error for incompatible pointers with different address_spaces. We allow this for all attributes (not just address_space), and for multiple attributes declared in the same macro. Differential Revision: https://reviews.llvm.org/D51329 llvm-svn: 359826
* [Sema] Emit warning for visibility attribute on internal-linkage declarationScott Linder2019-05-021-0/+8
| | | | | | | | GCC warns on these cases, but we currently just silently ignore the attribute. Differential Revision: https://reviews.llvm.org/D61097 llvm-svn: 359814
* Do not warn on switches over enums that do not use [[maybe_unused]] enumeratorsDavid Blaikie2019-05-021-0/+3
| | | | | | | | | | PR36231, [dcl.attr.unused]p3 Reviewers: aaron.ballman Differential Revision: https://reviews.llvm.org/D61444 llvm-svn: 359800
* [OpenCL] Fix initialisation of this via pointer.Anastasia Stulova2019-05-021-5/+5
| | | | | | | | | | | | | | | When the expression used to initialise 'this' has a pointer type, check the address space of the pointee type instead of the pointer type to decide whether an address space cast is required. It is the pointee type that carries the address space qualifier. Fixing PR41674. Patch by kpet (Kevin Petit)! Differential Revision: https://reviews.llvm.org/D61319 llvm-svn: 359798
* [OpenCL] Deduce static data members to __global addr space.Anastasia Stulova2019-05-021-2/+4
| | | | | | | | | Similarly to static variables in OpenCL, static class data members should be deduced to __global addr space. Differential Revision: https://reviews.llvm.org/D61304 llvm-svn: 359789
* Replace ad-hoc tracking of pattern for an instantiated class-scopeRichard Smith2019-05-023-48/+32
| | | | | | | | | | explicit function specialization with the MemberSpecializationInfo used everywhere else. Not NFC: the ad-hoc pattern tracking was not being serialized / deserialized properly. That's fixed here. llvm-svn: 359747
* Diagnose non-dependent qualified friend function template declarationsRichard Smith2019-05-022-2/+2
| | | | | | | that don't match any existing declaration. Don't get confused and treat such declarations as template *specializations*. llvm-svn: 359746
* [NFC] typoJF Bastien2019-04-301-2/+2
| | | | llvm-svn: 359524
* Simplify exclusion of nested classes from extern template instantiation, NFCReid Kleckner2019-04-291-8/+7
| | | | | | | | | | | | | | | | | | | | | Summary: This simplifies three checks for MS ABI, Win Itanium, or Win GNU to just "is Windows". The question remains, however, if this is really the correct thing to do. We could, for example, only not consider inner classes to be externally available if the outer class has a dllexport annotation. However, I will leave that as future work. Reviewers: hans, mstorsjo Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61278 llvm-svn: 359507
* [OPENMP]Fix PR41617: crash on template instantiation.Alexey Bataev2019-04-291-1/+1
| | | | | | | Fixed the crash on the template instantiation when trying to check the data locality in the current instantiation scope. llvm-svn: 359459
* Reinstate r359059, reverted in r359361, with a fix to properly preventRichard Smith2019-04-271-1/+5
| | | | | | | | | | | | | | | | | | | | | | | us emitting the operand of __builtin_constant_p if it has side-effects. Original commit message: Fix interactions between __builtin_constant_p and constexpr to match current trunk GCC. GCC permits information from outside the operand of __builtin_constant_p (but in the same constant evaluation context) to be used within that operand; clang now does so too. A few other minor deviations from GCC's behavior showed up in my testing and are also fixed (matching GCC): * Clang now supports nullptr_t as the argument type for __builtin_constant_p * Clang now returns true from __builtin_constant_p if called with a null pointer * Clang now returns true from __builtin_constant_p if called with an integer cast to pointer type llvm-svn: 359367
* Revert Fix interactions between __builtin_constant_p and constexpr to match ↵Jorge Gorbe Moya2019-04-271-5/+1
| | | | | | | | current trunk GCC. This reverts r359059 (git commit 0b098754b73f3b96d00ecb1c7605760b11c90298) llvm-svn: 359361
* [AArch64] Add support for MTE intrinsicsJaved Absar2019-04-261-0/+164
| | | | | | | | | | | | This provides intrinsics support for Memory Tagging Extension (MTE), which was introduced with the Armv8.5-a architecture. These intrinsics are available when __ARM_FEATURE_MEMORY_TAGGING is defined. Each intrinsic is described in detail in the ACLE Q1 2019 documentation: https://developer.arm.com/docs/101028/latest Reviewed By: Tim Nortover, David Spickett Differential Revision: https://reviews.llvm.org/D60485 llvm-svn: 359348
* [MinGW] Do dllexport inline methods in template instantiationMartin Storsjo2019-04-261-2/+5
| | | | | | | | | | | | | | | | | | Normally, in MinGW mode, inline methods aren't dllexported. However, in the case of a dllimported template instantiation, the inline methods aren't instantiated locally, but referenced from the instantiation. Therefore, those methods also need to be dllexported, in the case of an instantiation. GCC suffers from the same issue, reported at [1], but the issue is still unresolved there. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89088 Differential Revision: https://reviews.llvm.org/D61176 llvm-svn: 359343
* [MinGW] Don't let template instantiation declarations cover nested classesMartin Storsjo2019-04-261-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An explicit template instantiation declaration used to let callers assume both outer and nested classes instantiations were defined in a different translation unit. If the instantiation is marked dllexport, only the outer class is exported, but the caller will try to reference the instantiation of both outer and inner classes. This makes MinGW mode match both MSVC and Windows Itanium, by having instantations only cover the outer class, and locally emitting definitions of the nested classes. Windows Itanium was changed to use this behavious in SVN r300804. This deviates from what GCC does, but should be safe (and only inflate the object file size a bit, but MSVC and Windows Itanium modes do the same), and fixes cases where inner classes aren't dllexported. This fixes missing references in combination with dllexported/imported template intantiations. GCC suffers from the same issue, reported at [1], but the issue is still unresolved there. The issue can probably be solved either by making dllexport cover all nested classes as well, or this way (matching MSVC). [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89087 Differential Revision: https://reviews.llvm.org/D61175 llvm-svn: 359342
* [OPENMP]Added check for non-random access types for the dependent loopAlexey Bataev2019-04-261-51/+78
| | | | | | | | | | | counters. According to the OpenMP 5.0, For any associated loop where the b or lb expression is not loop invariant with respect to the outermost loop, the var-outer that appears in the expression may not have a random access iterator type. llvm-svn: 359340
* [MinGW] Fix dllexport of explicit template instantiationMartin Storsjo2019-04-262-4/+29
| | | | | | | | | | | | | | | | | Contrary to MSVC, GCC/MinGW needs to have the dllexport attribute on the template instantiation declaration, not on the definition. Previously clang never marked explicit template instantiations as dllexport in MinGW mode, if the instantiation had a previous declaration, regardless of where the attribute was placed. This makes Clang behave like GCC in this regard, and allows using the same attribute form for both MinGW compilers. This fixes PR40256. Differential Revision: https://reviews.llvm.org/D61118 llvm-svn: 359285
* PR41607: Don't forget to substitute outer template arguments into aRichard Smith2019-04-261-5/+9
| | | | | | class-scope explicit specialization of a class template. llvm-svn: 359266
OpenPOWER on IntegriCloud