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 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
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
"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
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
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
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
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
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
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
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
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
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
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
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
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
-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
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
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
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
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
Don't send a value dependent expression into the expression evaluator,
HandleSizeof would crash. Making HandleSizeof handle dependent types
would noisily warn about the operation even if everything turns out OK
after instantiation.
This fixes PR21848.
llvm-svn: 224240
OpenCL v2.0 s6.5.5 restricts conversion of pointers to different address spaces:
- the named address spaces (__global, __local, and __private) => __generic - implicitly converted;
- __generic => named - with an explicit cast;
- named <=> named - disallowed;
- __constant <=> any other - disallowed.
llvm-svn: 222834
Sema::ActOnIdExpression to use the new functionality.
Among other things, this allows recovery in several cases where it
wasn't possible before (e.g. correcting a mistyped static_cast<>).
llvm-svn: 222464
nonnull attribute when comparison is always true/false.
Original patch by Steven Wu. I have added extra code to prevent issuing of
warning when the nonnull parameter is modified prior to the comparison.
This addition prevents false positives in the most obvious cases.
There may still be false positive warnings in some cases (as one of my tests
indicates), but benefit far outweighs such cases. rdar://18712242
llvm-svn: 222264
Summary:
Ok, here is somewhat addition to D6217 aiming to preserve old darwin behavior wrt the typedefed types. The actual change to SemaChecking turned out to be pretty gross, in particular:
1. We need to extract the typedef'ed type for proper diagnostics
2. We need to walk over paren expressions as well
Reviewers: chandlerc, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6256
llvm-svn: 222044
Summary:
Consider the following nifty 1 liner: (0 ? csqrtl(2.0f) : sqrtl(2.0f)). One can easily obtain such code from e.g. tgmath. Right now it produces an assertion because we fail to do the promotion real => _Complex real.
The case was properly handled previously (old handleOtherComplexFloatConversion routine), but was forgotten in the current version. This seems to be about fallout from r219557
Reviewers: chandlerc, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6217
llvm-svn: 221821
code for calling CorrectTypo.
Includes a needed fix for non-C++ code to not choke on TypoExprs (which
also resolves a TODO from r220698).
llvm-svn: 221736
an __unknown_anytype(...). In this case, we rebuild the
vararg function type specially to convert the call expression
to something that IRGen can handle. However, FunctionDecl
as rebuilt in RebuildUnknownAnyExpr::resolveDecl is bogus and
results in crash when accessing its params later on. This
patch fixes the crash by rebuilding the FunctionDecl to match
its new resolved type. rdar://15297105.
(patch reapplied after lldb issue was fixed in r221660).
llvm-svn: 221691
This is a new form of expression of the form:
(expr op ... op expr)
where one of the exprs is a parameter pack. It expands into
(expr1 op (expr2onwards op ... op expr))
(and likewise if the pack is on the right). The non-pack operand can be
omitted; in that case, an empty pack gives a fallback value or an error,
depending on the operator.
llvm-svn: 221573
an __unknown_anytype(...). In this case, we rebuild the
vararg function type specially to convert the call expression
to something that IRGen can handle. However, FunctionDecl
as rebuilt in RebuildUnknownAnyExpr::resolveDecl is bogus and
results in crash when accessing its params later on. This
patch fixes the crash by rebuilding the FunctionDecl to match
its new resolved type. rdar://15297105.
John McCall, please review post-commit.
llvm-svn: 221404
An updated implemnentation of VLA types capturing based on previously committed solution for Lambdas.
This version captures the whole VLA type instead of particular variables which are part of VLA size expression and allows to use previusly calculated size of VLA type in captured regions. Required for OpenMP.
Differential Revision: http://reviews.llvm.org/D5099
llvm-svn: 220850
Part of the infrastructure is a map from a TypoExpr to the Sema-specific
state needed to correct it, along with helpers to ease dealing with the
state.
The the typo count is propagated up the stack of
ExpressionEvaluationContextRecords when one is popped off of to
avoid accidentally dropping TypoExprs on the floor. For example,
the attempted correction of g() in test/CXX/class/class.mem/p5-0x.cpp
happens with an ExpressionEvaluationContextRecord that is popped off
the stack prior to ActOnFinishFullExpr being called and the tree
transform for TypoExprs being run.
llvm-svn: 220695
Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1).
Reviewed by Richard Smith
llvm-svn: 219589
operators where one type is a C complex type, and to emit both the
efficient and correct implementation for complex arithmetic according to
C11 Annex G using this extra information.
For both multiply and divide the old code was writing a long-hand
reduced version of the math without any of the special handling of inf
and NaN recommended by the standard here. Instead of putting more
complexity here, this change does what GCC does which is to emit
a libcall for the fully general case.
However, the old code also failed to do the proper minimization of the
set of operations when there was a mixed complex and real operation. In
those cases, C provides a spec for much more minimal operations that are
valid. Clang now emits the exact suggested operations. This change isn't
*just* about performance though, without minimizing these operations, we
again lose the correct handling of infinities and NaNs. It is critical
that this happen in the frontend based on assymetric type operands to
complex math operations.
The performance implications of this change aren't trivial either. I've
run a set of benchmarks in Eigen, an open source mathematics library
that makes heavy use of complex. While a few have slowed down due to the
libcall being introduce, most sped up and some by a huge amount: up to
100% and 140%.
In order to make all of this work, also match the algorithm in the
constant evaluator to the one in the runtime library. Currently it is
a broken port of the simplifications from C's Annex G to the long-hand
formulation of the algorithm.
Splitting this patch up is very hard because none of this works without
the AST change to preserve non-complex operands. Sorry for the enormous
change.
Follow-up changes will include support for sinking the libcalls onto
cold paths in common cases and fastmath improvements to allow more
aggressive backend folding.
Differential Revision: http://reviews.llvm.org/D5698
llvm-svn: 219557
Assertion failed: "Computed __func__ length differs from type!"
Reworked PredefinedExpr representation with internal StringLiteral field for function declaration.
Differential Revision: http://reviews.llvm.org/D5365
llvm-svn: 219393
Clang warns (treated as error by default, but still ignored in system headers)
when passing non-POD arguments to variadic functions, and generates a trap
instruction to crash the program if that code is ever run.
Unfortunately, MSVC happily generates code for such calls without a warning,
and there is code in system headers that use it.
This makes Clang not insert the trap instruction when in -fms-compatibility
mode, while still generating the warning/error message.
Differential Revision: http://reviews.llvm.org/D5492
llvm-svn: 218640
that function, and apart from being slow, this is unnecessary: ADL can trigger
instantiations that are not permitted here. The standard isn't *completely*
clear here, but this seems like the intent, and in any case this approach is
permitted by [temp.inst]p7.
llvm-svn: 218330
We would end up marking the vtable of the derived class as used for no
reason. Because the call itself is qualified, it is never virtual, and
the vtable of the derived class isn't helpful. We would end up rejecting
code that MSVC accepts for no benefit.
See http://crbug.com/413478
llvm-svn: 217910
In line with SemaOpenMP.cpp, etc. CUDA-specific semantic analysis code goes into
a separate file. This is in anticipation of adding extra functionality here in
the near future.
No change in functionality.
Review: http://reviews.llvm.org/D5160
llvm-svn: 217043
In C++11, instantiation of exception specs is deferred. The instantiation is
done in MarkFunctionReferenced(), which wasn't called for non-OdrUsed functions,
which then caused an assert in codegen. Fixes PR19190, see the bug for details.
llvm-svn: 216562
Changes diagnostic options, language standard options, diagnostic identifiers, diagnostic wording to use c++14 instead of c++1y. It also modifies related test cases to use the updated diagnostic wording.
llvm-svn: 215982
Clang forgot that '++s.m' was a bitfield l-value and permit it's address
to be taken; this would crash at CodeGen-time.
Instead, propagate the object-kind when we see the prefix
increment/decrement.
This fixes PR20496.
Differential Revision: http://reviews.llvm.org/D4733
llvm-svn: 214386
ExtWarn/Warnings. Mostly the name of the warning was changed to match the
semantics, but in the PR20356 cases, the warning was about valid code, so the
diagnostic was changed from ExtWarn to Warning instead.
llvm-svn: 213443
This fixes compilation errors about incomplete types used with WebKit's
RefPtr template. Simply calling an out of line constructor should not
instantiate all inline and defaulted virtual methods.
Tested by building and testing several big piles of code on Linux.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D4429
llvm-svn: 213109
MSVC accepts __noop without any trailing parens and treats it like a
literal zero. We don't treat __noop as an integer literal, but now at
least we can parse a naked __noop expression.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D4476
llvm-svn: 212860
when casting a retainable object to a objc_bridge_related
CF type with the suggestion of applying the method
specified in the bridging attribute to the object.
// rdar://15932435
llvm-svn: 211807
Something went wrong with r211426, it is an older version of this code
and should not have been committed. It was reverted with r211434.
Original commit message:
We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appropriately sized integer type.
This fixes PR20008.
Differential Revision: http://reviews.llvm.org/D4132
llvm-svn: 211441
This reverts commit r211426.
This broke the arm bots. The crash can be reproduced on X86 by running.
./bin/clang -cc1 -fsyntax-only -verify -fms-extensions ~/llvm/clang/test/Lexer/ms-extensions.c -triple arm-linux
llvm-svn: 211434
We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appropriately sized integer type.
This fixes PR20008.
Differential Revision: http://reviews.llvm.org/D4132
llvm-svn: 211426
Peter Collingbourne