summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaExpr.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [OPENMP] Do not emit references to original variables in 'private' clause.Alexey Bataev2015-06-231-0/+15
| | | | | | | Currently if the variable is captured in captured region, capture record for this region stores reference to this variable for future use. But we don't need to provide the reference to the original variable if it was explicitly marked as private in the 'private' clause of the OpenMP construct, this variable is replaced by private copy. Differential Revision: http://reviews.llvm.org/D9550 llvm-svn: 240377
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-221-7/+7
| | | | llvm-svn: 240353
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-221-7/+7
| | | | | | | | | | | | The patch is generated using this command: $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ work/llvm/tools/clang To reduce churn, not touching namespaces spanning less than 10 lines. llvm-svn: 240270
* Remove incomplete comment.Davide Italiano2015-06-221-1/+0
| | | | llvm-svn: 240252
* Consider unsigned long for non-u/U decimal literals (C90/C++03)Hubert Tong2015-06-081-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This modifies Clang to reflect that under pre-C99 ISO C, decimal constants may have type `unsigned long` even if they do not contain `u` or `U` in their suffix (C90 subclause 6.1.3.2 paragraph 5). The same is done for C++ without C++11 which--because of undefined behaviour--allows for behaviour compatible with ISO C90 in the case of an unsuffixed decimal literal and is otherwise identical to C90 in its treatment of integer literals (C++03 subclause 2.13.1 [lex.icon] paragraph 2). Messages are added to the `c99-compat` and `c++11-compat` groups to warn on such literals, since they behave differently under the newer standards. Fixes PR 16678. Test Plan: A new test file is added to exercise both pre-C99/C++11 and C99/C++11-up on decimal literals with no suffix or suffixes `l`/`L` for both 32-bit and 64-bit `long`. In the file, 2^31 (being `INT_MAX+1`) is tested for the expected type using `__typeof__` and multiple declarations of the same entity. 2^63 is similarly tested when it is within the range of `unsigned long`. Preprocessor arithmetic tests are added to ensure consistency given that Clang (like GCC) uses greater than 32 bits for preprocessor arithmetic even when `long` and `unsigned long` is 32 bits and a pre-C99/C++11 mode is in effect. Tests added: test/Sema/PR16678.c Reviewers: fraggamuffin, rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D9794 llvm-svn: 239356
* [Sema] Promote compound assignment exprs. with fp16 LHS and int. RHS.Ahmed Bougacha2015-05-291-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | We catch most of the various other __fp16 implicit conversions to float, but not this one: __fp16 a; int i; ... a += i; For which we used to generate something 'fun' like: %conv = sitofp i32 %i to float %1 = tail call i16 @llvm.convert.to.fp16.f32(float %conv) %add = add i16 %0, %1 Instead, when we have an __fp16 LHS and an integer RHS, we should use float as the result type. While there, add a bunch of missing tests for mixed __fp16/integer expressions. llvm-svn: 238625
* Fix assertion when assigning to object in OpenCL constant address space.Richard Smith2015-05-221-0/+3
| | | | | | Patch by John Garvin! llvm-svn: 237983
* Check for bool-like conversion in conditional expressions.Richard Trieu2015-05-201-0/+2
| | | | | | | | | | Add a check for bool-like conversions for the condition expression of conditional operators. This is similiar to the checking of condition expressions of if statements, for-loops, while-loops, and do-while loops. Specificially, this is to fix the problem of assert("message") not triggering -Wstring-conversion when the assert macro uses a conditional operator. llvm-svn: 237856
* Fix Clang -Wsequence-pointDavid Blaikie2015-05-141-1/+1
| | | | llvm-svn: 237401
* Tweak availability checking to look through typedef declarations.Ted Kremenek2015-05-141-2/+18
| | | | llvm-svn: 237396
* Make GNUInline consistent with whether we use traditional GNU inline semantics.Peter Collingbourne2015-05-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we were setting LangOptions::GNUInline (which controls whether we use traditional GNU inline semantics) if the language did not have the C99 feature flag set. The trouble with this is that C++ family languages also do not have that flag set, so we ended up setting this flag in C++ modes (and working around it in a few places downstream by also checking CPlusPlus). The fix is to check whether the C89 flag is set for the target language, rather than whether the C99 flag is cleared. This also lets us remove most CPlusPlus checks. We continue to test CPlusPlus when deciding whether to pre-define the __GNUC_GNU_INLINE__ macro for consistency with GCC. There is a change in semantics in two other places where we weren't checking both CPlusPlus and GNUInline (FunctionDecl::doesDeclarationForceExternallyVisibleDefinition and FunctionDecl::isInlineDefinitionExternallyVisible), but this change seems to put us back into line with GCC's semantics (test case: test/CodeGen/inline.c). While at it, forbid -fgnu89-inline in C++ modes, as GCC doesn't support it, it didn't have any effect before, and supporting it just makes things more complicated. Differential Revision: http://reviews.llvm.org/D9333 llvm-svn: 237299
* [modules] Stop trying to fake up a linear MacroDirective history.Richard Smith2015-04-291-3/+2
| | | | | | | | | | | | | | Modules builds fundamentally have a non-linear macro history. In the interest of better source fidelity, represent the macro definition information faithfully: we have a linear macro directive history within each module, and at any point we have a unique "latest" local macro directive and a collection of visible imported directives. This also removes the attendent complexity of attempting to create a correct MacroDirective history (which we got wrong in the general case). No functionality change intended. llvm-svn: 236176
* PR23334: Perform semantic checking of lambda capture initialization in the ↵Richard Smith2015-04-271-130/+23
| | | | | | | | | | | | | | | | | | right context. Previously we'd try to perform checks on the captures from the middle of parsing the lambda's body, at the point where we detected that a variable needed to be captured. This was wrong in a number of subtle ways. In PR23334, we couldn't correctly handle the list of potential odr-uses resulting from the capture, and our attempt to recover from that resulted in a use-after-free. We now defer building the initialization expression until we leave the lambda body and return to the enclosing context, where the initialization does the right thing. This patch only covers lambda-expressions, but we should apply the same change to blocks and captured statements too. llvm-svn: 235921
* [Objective-C Sema]This patch fixes the warning when clang issuesFariborz Jahanian2015-04-151-2/+1
| | | | | | | | | | "multiple methods named '<selector>' found" warning by noting the method that is actualy used. It also cleans up and refactors code in this area and selects a method that matches actual arguments in case of receiver being a forward class object. rdar://19265430 llvm-svn: 235023
* Improve the error message for assigning to read-only variables.Richard Trieu2015-04-111-3/+141
| | | | | | | | | | Previously, many error messages would simply be "read-only variable is not assignable" This change provides more information about why the variable is not assignable, as well as note to where the const is located. Differential Revision: http://reviews.llvm.org/D4479 llvm-svn: 234677
* Sema: Accept pointers to any address space for builtin functionsTom Stellard2015-03-311-3/+94
| | | | | | | | As long as they don't have an address space explicitly defined. This allows builtins with pointer arguments to be used with OpenCL. llvm-svn: 233706
* Fix -Wshift-count-negative. It didn't work if the right hand sideDavide Italiano2015-03-261-1/+1
| | | | | | | | of the shift wasn't a constant integer expression, now it (hopefully) does. PR: 22059 llvm-svn: 233320
* Add -Wpartial-availability.Nico Weber2015-03-191-7/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | This warns when using decls that are not available on all deployment targets. For example, a call to - (void)ppartialMethod __attribute__((availability(macosx,introduced=10.8))); will warn if -mmacosx-version-min is set to less than 10.8. To silence the warning, one has to explicitly redeclare the method like so: @interface Whatever(MountainLionAPI) - (void)ppartialMethod; @end This way, one cannot accidentally call a function that isn't available everywhere. Having to add the redeclaration will hopefully remind the user to add an explicit respondsToSelector: call as well. Some projects build against old SDKs to get this effect, but building against old SDKs suppresses some bug fixes -- see http://crbug.com/463171 for examples. The hope is that SDK headers are annotated well enough with availability attributes that new SDK + this warning offers the same amount of protection as using an old SDK. llvm-svn: 232750
* Remove many superfluous SmallString::str() calls.Yaron Keren2015-03-181-1/+1
| | | | | | | | | | | | | | | Now that SmallString is a first-class citizen, most SmallString::str() calls are not required. This patch removes a whole bunch of them, yet there are lots more. There are two use cases where str() is really needed: 1) To use one of StringRef member functions which is not available in SmallString. 2) To convert to std::string, as StringRef implicitly converts while SmallString do not. We may wish to change this, but it may introduce ambiguity. llvm-svn: 232622
* Reverted OpenCL2.0 atomic type commits r231932, r231935Anastasia Stulova2015-03-111-22/+0
| | | | | | (caused undesirable update of -std flag to use _Atomic) llvm-svn: 231942
* OpenCL: CL2.0 atomic type diagnosticsAnastasia Stulova2015-03-111-0/+22
| | | | | | Added restictions for atomic type usage from OpenCL C Spec Section 6.13.11.8 llvm-svn: 231935
* Sema: The i8 suffix should yield a literal of type charDavid Majnemer2015-03-061-0/+3
| | | | | | | | | We would make i8 literals turn into signed char instead of char. This is incompatible with MSVC. This fixes PR22824. llvm-svn: 231494
* Don't crash on non-public referenced dtors in toplevel classes.Nico Weber2015-03-061-2/+5
| | | | | | | Fixes PR22793, a bug that caused self-hosting to fail after the innocuous r231254. See the bug for details. llvm-svn: 231451
* Sema: Parenthesized bound destructor member expressions can be calledDavid Majnemer2015-02-251-1/+11
| | | | | | | | | We would wrongfully reject (a.~A)() in both the destructor and pseudo-destructor cases. This fixes PR22668. llvm-svn: 230512
* Restores r228382, which was reverted in r228406.Sameer Sahasrabuddhe2015-02-251-1/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The original commit failed to handle "shift assign" (<<=), which broke the test mentioned in r228406. This is now fixed and the test added to the lit tests under SemaOpenCL. *** Original commit message from r228382 *** OpenCL: handle shift operator with vector operands Introduce a number of checks: 1. If LHS is a scalar, then RHS cannot be a vector. 2. Operands must be of integer type. 3. If both are vectors, then the number of elements must match. Relax the requirement for "usual arithmetic conversions": When LHS is a vector, a scalar RHS can simply be expanded into a vector; OpenCL does not require that its rank be lower than the LHS. For example, the following code is not an error even if the implicit type of the constant literal is "int". char2 foo(char2 v) { return v << 1; } Consolidate existing tests under CodeGenOpenCL, and add more tests under SemaOpenCL. llvm-svn: 230464
* MS extensions: Properly diagnose address of MS property declReid Kleckner2015-02-241-0/+2
| | | | | | | | | | | | Summary: Fixes PR22671. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D7863 llvm-svn: 230362
* Sema: Replace some push_backs of expensive to move objects with emplace_back.Benjamin Kramer2015-02-171-6/+3
| | | | | | NFC. llvm-svn: 229557
* Sema: Semantically check _Atomic-qualified pointersDavid Majnemer2015-02-121-5/+12
| | | | | | This fixes PR22568. llvm-svn: 228959
* Revert "OpenCL: handle shift operator with vector operands"Tom Stellard2015-02-061-65/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit r228382. This breaks the following case: Reported by Jeroen Ketema: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150202/122961.html typedef __attribute__((ext_vector_type(3))) char char3; void foo() { char3 v = {1,1,1}; char3 w = {1,2,3}; w <<= v; } If I compile with: clang -x cl file.c Then an error is produced: file.c:10:5: error: expression is not assignable w <<= v; ~ ^ 1 error generated. llvm-svn: 228406
* OpenCL: handle shift operator with vector operandsSameer Sahasrabuddhe2015-02-061-1/+65
| | | | | | | | | | | | | | | | | | | | Introduce a number of checks: 1. If LHS is a scalar, then RHS cannot be a vector. 2. Operands must be of integer type. 3. If both are vectors, then the number of elements must match. Relax the requirement for "usual arithmetic conversions": When LHS is a vector, a scalar RHS can simply be expanded into a vector; OpenCL does not require that its rank be lower than the LHS. For example, the following code is not an error even if the implicit type of the constant literal is "int". char2 foo(char2 v) { return v << 1; } Consolidate existing tests under CodeGenOpenCL, and add more tests under SemaOpenCL. llvm-svn: 228382
* OpenCL: handle ternary operator when the condition is a vectorSameer Sahasrabuddhe2015-02-041-42/+194
| | | | | | | | | | When the condition is a vector, OpenCL specifies additional requirements on the operand types, and also the operations required to determine the result type of the operator. This is a combination of OpenCL v1.1 s6.3.i and s6.11.6, and the semantics remain unchanged in later versions of OpenCL. llvm-svn: 228118
* Fix OpenCL 1.2 double as an optional core feature behaviourFraser Cormack2015-01-301-1/+3
| | | | | | | | | | | | | | | | | | | | In OpenCL 1.2, using double no longer requires using the pragma cl_khr_fp64, instead a kernel is allowed to use double, but must first have queried clGetDeviceInfo's CL_DEVICE_DOUBLE_FP_CONFIG. Page 197, section 6.1.1 of the OpenCL 1.2 specification has a footnote 23 describing this behaviour. I've also added test cases such that the pragma must be used if targeting OpenCL 1.0 or 1.1, but is ignored in 1.2 and 2.0. Patch by Neil Henning! Reviewers: Pekka Jääskeläinen Differential Revision: http://reviews.llvm.org/D7245 llvm-svn: 227565
* Revert a change from r222797 that is no longer needed and can causeKaelyn Takata2015-01-281-6/+2
| | | | | | | | | | | | | infinite recursion. Also guard against said infinite recursion by adding an assert that will trigger if CorrectDelayedTyposInExpr is called before a previous call to CorrectDelayedTyposInExpr returns (i.e. if the TreeTransform run by CorrectDelayedTyposInExpr calls a sequence of methods that end up calling CorrectDelayedTyposInExpr, as the new test case had done prior to this commit). Fixes PR22292. llvm-svn: 227368
* Fix a think-o in handling ambiguous corrections for a TypoExpr.Kaelyn Takata2015-01-271-1/+19
| | | | | | | | | | | | | | | | | | | | Under certain circumstances, the identifier mentioned in the diagnostic won't match the intended correction even though the replacement expression and the note pointing to the decl are both correct. Basically, the TreeTransform assumes the TypoExpr's Consumer points to the correct TypoCorrection, but the handling of typos that appear to be ambiguous from the point of view of TransformTypoExpr would cause that assumption to be violated by altering the Consumer's correction stream. This fix allows the Consumer's correction stream to be reset to the right TypoCorrection after successfully resolving the percieved ambiguity. Included is a fix to suppress correcting the RHS of an assignment to the LHS of that assignment for non-C++ code, to prevent a regression in test/SemaObjC/provisional-ivar-lookup.m. This fixes PR22297. llvm-svn: 227251
* Properly handle typos in the conditional of ?: expressions in C.Kaelyn Takata2015-01-271-9/+9
| | | | | | | | | | In particular, remove the OpaqueExpr transformation from r225389 and move the correction of the conditional from CheckConditionalOperands to ActOnConditionalOp before the OpaqueExpr is created. This fixes the typo correction behavior in C code that uses the GNU extension for a binary ?: (without an expression between the "?" and the ":"). llvm-svn: 227220
* Don't let virtual calls and dynamic casts call Sema::MarkVTableUsed().Nico Weber2015-01-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | clang currently calls MarkVTableUsed() for classes that get their virtual methods called or that participate in a dynamic_cast. This is unnecessary, since CodeGen only emits vtables when it generates constructor, destructor, and vtt code. (*) Note that Sema::MarkVTableUsed() doesn't cause the emission of a vtable. Its main user-visible effect is that it instantiates virtual member functions of template classes, to make sure that if codegen decides to write a vtable all the entries in the vtable are defined. While this shouldn't change the behavior of codegen (other than being faster), it does make clang more permissive: virtual methods of templates (in particular destructors) end up being instantiated less often. In particular, classes that have members that are smart pointers to incomplete types will now get their implicit virtual destructor instantiated less frequently. For example, this used to not compile but does now compile: template <typename T> struct OwnPtr { ~OwnPtr() { static_assert((sizeof(T) > 0), "TypeMustBeComplete"); } }; class ScriptLoader; struct Base { virtual ~Base(); }; struct Sub : public Base { virtual void someFun() const {} OwnPtr<ScriptLoader> m_loader; }; void f(Sub *s) { s->someFun(); } The more permissive behavior matches both gcc (where this is not often observable, since in practice most things with virtual methods have a key function, and Sema::DefineUsedVTables() skips vtables for classes with key functions) and cl (which is my motivation for this change) – this fixes PR20337. See this issue and the review thread for some discussions about optimizations. This is similar to r213109 in spirit. r225761 was a prerequisite for this change. Various tests relied on "a->f()" marking a's vtable as used (in the sema sense), switch these to just construct a on the stack. This forces instantiation of the implicit constructor, which will mark the vtable as used. (*) The exception is -fapple-kext mode: In this mode, qualified calls to virtual functions (`a->Base::f()`) still go through the vtable, and since the vtable pointer off this doesn't point to Base's vtable, this needs to reference Base's vtable directly. To keep this working, keep referencing the vtable for virtual calls in apple kext mode. llvm-svn: 227073
* Name a bool parameter. No behavior change.Nico Weber2015-01-251-1/+2
| | | | llvm-svn: 227026
* Make the ?: precedence warning handle pointers to the left of ?Hans Wennborg2015-01-221-0/+2
| | | | | | | | | | Previously, Clang would fail to warn on: int n = x + foo ? 1 : 2; when foo is a pointer. llvm-svn: 226870
* Fix crashes on missing @interface for categoryBen Langmuir2015-01-201-2/+2
| | | | | | | In a few places we didn't check that Category->getClassInterface() was not null before using it. llvm-svn: 226605
* Look through sugar when determining whether a type is a scoped enumerationRichard Smith2015-01-141-1/+1
| | | | | | type. Patch by Stephan Bergmann! llvm-svn: 225889
* Extend the self move warning to record types.Richard Trieu2015-01-131-85/+1
| | | | | | | Move the logic for checking self moves into SemaChecking and add that function to Sema since it is now used in multiple places. llvm-svn: 225756
* Rename RefersToCapturedVariable to RefersToEnclosingVariableOrCapture, NFCAlexey Bataev2015-01-121-6/+6
| | | | llvm-svn: 225624
* Add a new warning, -Wself-move, to Clang.Richard Trieu2015-01-101-1/+87
| | | | | | | | -Wself-move is similiar to -Wself-assign. This warning is triggered when a value is attempted to be moved to itself. See r221008 for a bug that would have been caught with this warning. llvm-svn: 225581
* Parse: Don't crash when namespace is in GNU statement exprDavid Majnemer2015-01-091-5/+0
| | | | | | | | | | | Parser::ParseNamespace can get a little confused when it found itself inside a compound statement inside of a non-static data member initializer. Try to determine that the statement expression's scope makes sense before trying to parse it's contents. llvm-svn: 225514
* WIPDavid Majnemer2014-12-261-16/+16
| | | | llvm-svn: 224843
* Adding a -Wunused-value warning for expressions with side effects used in an ↵Aaron Ballman2014-12-171-0/+13
| | | | | | unevaluated expression context, such as sizeof(), or decltype(). Also adds a similar warning when the expression passed to typeid() *is* evaluated, since it is equally likely that the user would expect the expression operand to be unevaluated in that case. llvm-svn: 224465
* Consider calls from implict host device functions as valid in SemaCUDA.Jacques Pienaar2014-12-161-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | In SemaCUDA all implicit functions were considered host device, this led to errors such as the following code snippet failing to compile: struct Copyable { const Copyable& operator=(const Copyable& x) { return *this; } }; struct Simple { Copyable b; }; void foo() { Simple a, b; a = b; } Above the implicit copy assignment operator was inferred as host device but there was only a host assignment copy defined which is an error in device compilation mode. Differential Revision: http://reviews.llvm.org/D6565 llvm-svn: 224358
* Renamed RefersToEnclosingLocal bitfield to RefersToCapturedVariable.Alexey Bataev2014-12-161-15/+15
| | | | | | | Bitfield RefersToEnclosingLocal of Stmt::DeclRefExprBitfields renamed to RefersToCapturedVariable to reflect latest changes introduced in commit 224323. Also renamed method Expr::refersToEnclosingLocal() to Expr::refersToCapturedVariable() and comments for constant arguments. No functional changes. llvm-svn: 224329
* [OPENMP] Bugfix for processing of global variables in OpenMP regions.Alexey Bataev2014-12-161-10/+30
| | | | | | | | Currently, if global variable is marked as a private OpenMP variable, the compiler crashes in debug version or generates incorrect code in release version. It happens because in the OpenMP region the original global variable is used instead of the generated private copy. It happens because currently globals variables are not captured in the OpenMP region. This patch adds capturing of global variables iff private copy of the global variable must be used in the OpenMP region. Differential Revision: http://reviews.llvm.org/D6259 llvm-svn: 224323
* Sema: Cleanup and improve string-plus-char checking.Daniel Marjamaki2014-12-151-4/+4
| | | | | | Patch by Anders Rönnholm llvm-svn: 224268
OpenPOWER on IntegriCloud