we first touch any part of that module. Instead, defer them until the first
time that module is (transitively) imported. The initializer step for a module
then recursively initializes modules that its own headers imported.
For example, this avoids running the <iostream> global initializer in programs
that don't actually use iostreams, but do use other parts of the standard
library.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276159 91177308-0d34-0410-b5e6-96231b3b80d8
VarDecl, TagDecl, EnumDecl, RecordDecl, CXXRecordDecl.
Use getDefinition in two locations to make the code more readable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275303 91177308-0d34-0410-b5e6-96231b3b80d8
- Changes diagnostics for Blocks to be implicitly
const qualified OpenCL v2.0 s6.12.5.
- Added and unified diagnostics of some OpenCL special types:
blocks, images, samplers, pipes. These types are intended for use
with the OpenCL builtin functions only and, therefore, most regular
uses are not allowed including assignments, arithmetic operations,
pointer dereferencing, etc.
Review: http://reviews.llvm.org/D21989
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275061 91177308-0d34-0410-b5e6-96231b3b80d8
ArrayRef is a little better than passing around a pointer/length
pair.
No functional change is intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274732 91177308-0d34-0410-b5e6-96231b3b80d8
We didn't correctly detect situations where a flexible array member was
the only named member in a record.
This fixes PR28407.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274477 91177308-0d34-0410-b5e6-96231b3b80d8
variable weak discardable linkage and partially-ordered initialization, and is
implied for constexpr static data members.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@273754 91177308-0d34-0410-b5e6-96231b3b80d8
- In functions with try { } catch { }, only the try block would be
skipped, not the catch blocks
- The template functions would still be parsed.
- The initializers within a constructor would still be parsed.
- The inline functions within class would still be stored, only to be
discared later.
- Invalid code with try would assert (as in "int foo() try assert_here")
This attempt to do even less while skipping function bodies.
Differential Revision: http://reviews.llvm.org/D20821
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272963 91177308-0d34-0410-b5e6-96231b3b80d8
The bug report by Gonzalo (https://llvm.org/bugs/show_bug.cgi?id=27507 -- which results in clang crashing when generic lambdas that capture 'this' are instantiated in contexts where the Functionscopeinfo stack is not in a reliable state - yet getCurrentThisType expects it to be) - unearthed some additional bugs in regards to maintaining proper cv qualification through 'this' when performing by value captures of '*this'.
This patch attempts to correct those bugs and makes the following changes:
o) when capturing 'this', we do not need to remember the type of 'this' within the LambdaScopeInfo's Capture - it is never really used for a this capture - so remove it.
o) teach getCurrentThisType to walk the stack of lambdas (even in scenarios where we run out of LambdaScopeInfo's such as when instantiating call operators) looking for by copy captures of '*this' and resetting the type of 'this' based on the constness of that capturing lambda's call operator.
This patch has been baking in review-hell for > 6 weeks - all the comments so far have been addressed and the bug (that it addresses in passing, and I regret not submitting as a separate patch initially) has been reported twice independently, so is frequent and important for us not to just sit on. I merged the cv qualification-fix and the PR-fix initially in one patch, since they resulted from my initial implementation of star-this and so were related. If someone really feels strongly, I can put in the time to revert this - separate the two out - and recommit. I won't claim it's immunized against all bugs, but I feel confident enough about the fix to land it for now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272480 91177308-0d34-0410-b5e6-96231b3b80d8
These ExprWithCleanups are added for holding a RunCleanupsScope not
for destructor calls; rather, they are for lifetime marks. This requires
ExprWithCleanups to keep a bit to indicate whether it have cleanups with
side effects (e.g. dtor calls).
Differential Revision: http://reviews.llvm.org/D20498
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272296 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of setting DeclSpec's range end to point to the next token
after the DeclSpec, we use getLocForEndOfToken to insert fix-it after a type
name.
Before this fix, fix-it will change
^(NSView view) to ^(*NSView view)
This commit correctly updates the source to ^(NSView* view).
rdar://21042144
Differential Revision: http://reviews.llvm.org/D20844
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@271448 91177308-0d34-0410-b5e6-96231b3b80d8
Wilson.
An unqualified lookup for in base classes may cause stack overflow if
the base class is a specialization of current class.
Patch by Will Wilson.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@271251 91177308-0d34-0410-b5e6-96231b3b80d8
If we have some function with dllimport attribute and then we have the function
definition in the same module but without dllimport attribute we should add
dllexport attribute to this function definition.
The same should be done for variables.
Example:
struct __declspec(dllimport) C3 {
~C3();
};
C3::~C3() {;} // we should export this definition.
Patch by Andrew V. Tischenko
Differential revision: http://reviews.llvm.org/D18953
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@270686 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In dependent contexts where we know a type name is required, such as a
new expression, we can recover by forming a DependentNameType.
This generalizes our existing compatibility hack for default arguments
for template type parameters.
Works towards parsing atlctrlw.h, which is PR26748.
Reviewers: avt77, rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D20500
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@270615 91177308-0d34-0410-b5e6-96231b3b80d8
map to the redecl context for both decls, not just one of them, and to properly
check that the decl contexts are equivalent.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@270482 91177308-0d34-0410-b5e6-96231b3b80d8
According to Cuda Programming guide (v7.5, E2.3.1):
> __device__, __constant__ and __shared__ variables defined in namespace
> scope, that are of class type, cannot have a non-empty constructor or a
> non-empty destructor.
Clang already deals with device-side constructors (see D15305).
This patch enforces similar rules for destructors.
Differential Revision: http://reviews.llvm.org/D20140
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@270108 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements __unaligned (MS extension) as a proper type qualifier
(before that, it was implemented as an ignored attribute).
It also fixes PR27367 and PR27666.
Differential Revision: http://reviews.llvm.org/D20103
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269220 91177308-0d34-0410-b5e6-96231b3b80d8
According to CUDA programming guide (v7.5):
> E.2.9.4: Within the body of a device or global function, only
> shared variables may be declared with static storage class.
Differential Revision: http://reviews.llvm.org/D20034
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@268962 91177308-0d34-0410-b5e6-96231b3b80d8
This patch corresponds to reviews:
http://reviews.llvm.org/D15120http://reviews.llvm.org/D19125
It adds support for the __float128 keyword, literals and target feature to
enable it. Based on the latter of the two aforementioned reviews, this feature
is enabled on Linux on i386/X86 as well as SystemZ.
This is also the second attempt in commiting this feature. The first attempt
did not enable it on required platforms which caused failures when compiling
type_traits with -std=gnu++11.
If you see failures with compiling this header on your platform after this
commit, it is likely that your platform needs to have this feature enabled.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@268898 91177308-0d34-0410-b5e6-96231b3b80d8
When inferring availability attributes for tvos, watchos from ios, we
use the same source location and set the implicit bit to true.
So when emitting diagnostics on inferred attributes, we have a source
location.
rdar://25893544
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@268793 91177308-0d34-0410-b5e6-96231b3b80d8
Usually these parameters are used solely to initialize the field in the
initializer list, and there is no real shadowing confusion.
There is a new warning under -Wshadow called
-Wshadow-field-in-constructor-modified. It attempts to find
modifications of such constructor parameters that probably intended to
modify the field.
It has some false negatives, though, so there is another warning group,
-Wshadow-field-in-constructor, which always warns on this special case.
For users who just want the old behavior and don't care about these fine
grained groups, we have a new warning group called -Wshadow-all that
activates everything.
Fixes PR16088.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18271
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@267957 91177308-0d34-0410-b5e6-96231b3b80d8
template<class T> void f(T) = delete;
template<> void f(int); // OK.
f(3); // OK
Implementation strategy:
When an explicit specialization of a function template, a member function template or a member function of a class template is declared, clang first implicitly instantiates the declaration of a specialization from the templated-entity being explicitly specialized (since their signatures must be the same) and then links the explicit specialization being declared as a redeclaration of the aforementioned specialization.
The problem was that when clang 'implicitly instantiates' the initial specialization, it marks the corresponding FunctionDecl as deleted if the corresponding templated-entity was deleted, rather than waiting to see whether the explicit specialization being declared provides a non-deleted body. (The eager marking of delete has advantages during overload resolution I suppose, where we don't have to try and instantiate a definition of the function to see if it is deleted).
The present fix entails recognizing that when clang knows that an explicit specialization is being declared (for whichever templated-entity), the prior implicit instantiation should not inherit the 'deleted' status, and so we reset it to false.
I suppose an alternative fix (amongst others) could consider creating a new context (ExplicitSpecializationDeclarationSubstitution or some such) that is checked during template-argument-deduction and final substitution, and avoid inheriting the deleted status during declaration substitution. But while conceptually cleaner, that would be a slightly more involved change (as could be some of the other alternatives: such as avoid tagging implicit specializations as deleted, and check their primary templates for the deleted status where needed), and so I chose a different path. Hopefully it'll prove to not be a bad choice.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266561 91177308-0d34-0410-b5e6-96231b3b80d8
Since this patch provided support for the __float128 type but disabled it
on all platforms by default, some platforms can't compile type_traits with
-std=gnu++11 since there is a specialization with __float128.
This reverts the patch until D19125 is approved (i.e. we know which platforms
need this support enabled).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266460 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements __unaligned as a type qualifier; before that, it was
modeled as an attribute. Proper mangling of __unaligned is implemented as well.
Some OpenCL code/tests are tangenially affected, as they relied on existing
number and sizes of type qualifiers.
Differential Revision: http://reviews.llvm.org/D18596
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266415 91177308-0d34-0410-b5e6-96231b3b80d8
This patch corresponds to review:
http://reviews.llvm.org/D15120
It adds support for the __float128 keyword, literals and a target feature to
enable it. This support is disabled by default on all targets and any target
that has support for this type is free to add it.
Based on feedback that I've received from target maintainers, this appears to
be the right thing for most targets. I have not heard from the maintainers of
X86 which I believe supports this type. I will subsequently investigate the
impact of enabling this on X86.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266186 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: A program shall not declare an explicit instantiation (14.8.2), an explicit specialization (14.8.3), or a partial specialization of a concept definition.
Reviewers: rsmith, hubert.reinterpretcast, faisalv, aaron.ballman
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18221
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265868 91177308-0d34-0410-b5e6-96231b3b80d8
Add parsing, sema analysis for 'declare target' construct for OpenMP 4.0
(4.5 support will be added in separate patch).
The declare target directive specifies that variables, functions (C, C++
and Fortran), and subroutines (Fortran) are mapped to a device. The declare
target directive is a declarative directive. In Clang declare target is
implemented as implicit attribute for the declaration.
The syntax of the declare target directive is as follows:
#pragma omp declare target
declarations-definition-seq
#pragma omp end declare target
Based on patch from Michael Wong http://reviews.llvm.org/D15321
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265530 91177308-0d34-0410-b5e6-96231b3b80d8
With this patch, by a constexpr function is implicitly host+device
unless:
a) it's a variadic function (variadic functions are not allowed on the
device side), or
b) it's preceeded by a __device__ overload in a system header.
The restriction on overloading __host__ __device__ functions on the
basis of their CUDA attributes remains in place, but we use (b) to allow
us to define __device__ overloads for constexpr functions in cmath,
which would otherwise be __host__ __device__ and thus not overloadable.
You can disable this behavior with -fno-cuda-host-device-constexpr.
Reviewers: tra, rnk, rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18380
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264964 91177308-0d34-0410-b5e6-96231b3b80d8
...as that is apparently what MSVC does. This is an updated version of r263738,
which had to be reverted in r263740 due to test failures. The original version
had erroneously emitted functions that are defined in class templates, too (see
the updated "Handle friend functions" code in EmitDeferredDecls,
lib/CodeGen/ModuleBuilder.cpp). (The updated tests needed to be split out into
their own dllexport-ms-friend.cpp because of the CHECK-NOTs which would have
interfered with subsequent CHECK-DAGs in dllexport.cpp.)
Differential Revision: http://reviews.llvm.org/D18430
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264841 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
* -fcuda-target-overloads
Previously unconditionally set to true by the driver. Necessary for
correct functioning of the compiler -- our CUDA headers wrapper won't
compile without this.
* -fcuda-disable-target-call-checks
Previously unconditionally set to true by the driver. Necessary to
compile almost any external CUDA code -- almost all libraries assume
that host+device code can call host or device functions.
* -fcuda-allow-host-calls-from-host-device
No effect when target overloading is enabled.
Reviewers: tra
Subscribers: rsmith, cfe-commits
Differential Revision: http://reviews.llvm.org/D18416
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264739 91177308-0d34-0410-b5e6-96231b3b80d8
Before this commit, we assert failure in ImplicitCastExpr
"unheralded conversion to bool". This commit fixes the assertion by using
the correct cast type when the fixed type is boolean.
This commit also fixes the behavior for Microsoft mode as well, since
Obj-C and Microsoft mode share the same code path.
rdar://24999533
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264167 91177308-0d34-0410-b5e6-96231b3b80d8
This commit adds a named argument to AvailabilityAttr, while r263652 adds an
optional string argument to __attribute__((deprecated)).
This was commited in r263687 and reverted in 263752 due to misaligned
access.
rdar://20588929
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263958 91177308-0d34-0410-b5e6-96231b3b80d8
Implement lambda capture of *this by copy.
For e.g.:
struct A {
int d = 10;
auto foo() { return [*this] (auto a) mutable { d+=a; return d; }; }
};
auto L = A{}.foo(); // A{}'s lifetime is gone.
// Below is still ok, because *this was captured by value.
assert(L(10) == 20);
assert(L(100) == 120);
If the capture was implicit, or [this] (i.e. *this was captured by reference), this code would be otherwise undefined.
Implementation Strategy:
- amend the parser to accept *this in the lambda introducer
- add a new king of capture LCK_StarThis
- teach Sema::CheckCXXThisCapture to handle by copy captures of the
enclosing object (i.e. *this)
- when CheckCXXThisCapture does capture by copy, the corresponding
initializer expression for the closure's data member
direct-initializes it thus making a copy of '*this'.
- in codegen, when assigning to CXXThisValue, if *this was captured by
copy, make sure it points to the corresponding field member, and
not, unlike when captured by reference, what the field member points
to.
- mark feature as implemented in svn
Much gratitude to Richard Smith for his carefully illuminating reviews!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263921 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith