This patch uses CodeSegAttr to represent __declspec(code_seg) rather than
building on the existing support for #pragma code_seg.
The code_seg declspec is applied on functions and classes. This attribute
enables the placement of code into separate named segments, including compiler-
generated codes and template instantiations.
For more information, please see the following:
https://msdn.microsoft.com/en-us/library/dn636922.aspx
This patch fixes the regression for the support for attribute ((section).
746b78de78
Patch by Soumi Manna (Manna)
Differential Revision: https://reviews.llvm.org/D48841
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@337420 91177308-0d34-0410-b5e6-96231b3b80d8
Basically, "AttributeList" loses all list-like mechanisms, ParsedAttributes is
switched to use a TinyPtrVector (and a ParsedAttributesView is created to
have a non-allocating attributes list). DeclaratorChunk gets the later kind,
Declarator/DeclSpec keep ParsedAttributes.
Iterators are added to the ParsedAttribute types so that for-loops work.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336945 91177308-0d34-0410-b5e6-96231b3b80d8
deprecated.
Add a -Wdeprecated warning for this in C++2a onwards. (In C++17 and
before, there isn't a reasonable alternative because [=,this] is
ill-formed.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336480 91177308-0d34-0410-b5e6-96231b3b80d8
When the return type of an ObjC-style block literals is deduced, pick
the candidate type with the strictest nullability annotation applicable
to every other candidate.
This suppresses a UBSan false-positive in situations where a too-strict
nullability would be deduced, despite the fact that the returned value
would be implicitly cast to _Nullable.
rdar://41317163
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335572 91177308-0d34-0410-b5e6-96231b3b80d8
This regressed our support for __attribute__((section)). See added test file
for example of code broken by this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332760 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for __declspec(code_seg("segname"))
This patch is built on the existing support for #pragma code_seg. The code_seg
declspec is allowed on functions and classes. The attribute enables the
placement of code into separate named segments, including compiler-generated
members and template instantiations.
For more information, please see the following:
https://msdn.microsoft.com/en-us/library/dn636922.aspx
A new CodeSeg attribute is used instead of adding a new spelling to the existing
Section attribute since they don’t apply to the same Subjects. Section
attributes are also added for the code_seg declspec since they are used for
#pragma code_seg. No CodeSeg attributes are added to the AST.
The patch is written to match with the Microsoft compiler’s behavior even where
that behavior is a little complicated (see https://reviews.llvm.org/D22931, the
Microsoft feedback page is no longer available since MS has removed the page).
That code is in getImplicitSectionAttrFromClass routine.
Diagnostics messages are added to match with the Microsoft compiler for code-seg
attribute mismatches on base and derived classes and virtual overrides.
Differential Revision: https://reviews.llvm.org/D43352
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332470 91177308-0d34-0410-b5e6-96231b3b80d8
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46320
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@331834 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This provides no measurable build speedup, but it reinstates an
optimization from r112038 that was lost in r179618. It requires moving
CapturedScopeInfo::Capture out to clang::sema, which might be too
general since we have plenty of other Capture records in BlockDecl and
other AST nodes.
Reviewers: rjmccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D44221
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@326957 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, we would:
* compute the type of the conversion function and static invoker as a
side-effect of template argument deduction for a conversion
* re-compute the type as part of deduced return type deduction when building
the conversion function itself
Neither of these turns out to be quite correct. There are other ways to reach a
declaration of the conversion function than in a conversion (such as an
explicit call or friend declaration), and performing auto deduction causes the
function type to be rebuilt in the context of the lambda closure type (which is
different from the context in which it originally appeared, resulting in
spurious substitution failures for constructs that are valid in one context but
not the other, such as the use of an enclosing class's "this" pointer).
This patch switches us to use a different strategy: as before, we use the
declared type of the operator() to form the type of the conversion function and
invoker, but we now populate that type as part of return type deduction for the
conversion function. And the invoker is now treated as simply being an
implementation detail of building the conversion function, and isn't given
special treatment by template argument deduction for the conversion function
any more.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321683 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Clang was crashing when diagnosing an unused-lambda-capture for a VLA because
From.getVariable() is null for the capture of a VLA bound.
Warning about the VLA bound capture is not helpful, so only warn for the VLA
itself.
Fixes: PR35555
Reviewers: aaron.ballman, dim, rsmith
Reviewed By: aaron.ballman, dim
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41016
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320396 91177308-0d34-0410-b5e6-96231b3b80d8
To fix: runtime error: load of value 15, which is not a valid value for type 'clang::LVComputationKind'
This reverts commit r313827.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@313856 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
1. Coroutine cannot be constexpr (added a check in SemaLambda.cpp not to mark coroutine as constexpr)
2. TransformCoroutineBodyStmt should transform ResultDecl and ReturnStmt
Reviewers: rsmith, GorNishanov
Reviewed By: GorNishanov
Subscribers: EricWF, cfe-commits
Differential Revision: https://reviews.llvm.org/D33498
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@303764 91177308-0d34-0410-b5e6-96231b3b80d8
lambda capture used by the created block
The commit r288866 introduced guaranteed copy elision to C++ 17. This
unfortunately broke the lambda to block conversion in C++17 (the compiler
crashes when performing IRGen). This commit fixes the conversion by avoiding
copy elision for the capture that captures the lambda that's used in the block
created by the lambda to block conversion process.
rdar://31385153
Differential Revision: https://reviews.llvm.org/D31669
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299646 91177308-0d34-0410-b5e6-96231b3b80d8
- also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17.
- update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299316 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Don't warn about unused lambda captures that involve copying a
value of a type that cannot be trivially copied and destroyed.
Fixes PR31977
Reviewers: rsmith, aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30327
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@296602 91177308-0d34-0410-b5e6-96231b3b80d8
instantiation.
In preparation for converting the template stack to a more general context
stack (so we can include context notes for other kinds of context).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295686 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Warn when a lambda explicitly captures something that is not used in its body.
The warning is part of -Wunused and can be enabled with -Wunused-lambda-capture.
Reviewers: rsmith, arphaman, jbcoe, aaron.ballman
Subscribers: Quuxplusone, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D28467
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291905 91177308-0d34-0410-b5e6-96231b3b80d8
This patch has been sitting in review hell since july 2016 and our lack of constexpr lambda support is getting embarrassing (given that I've had a branch that implements the feature (modulo *this capture) for over a year. While in Issaquah I was enjoying shamelessly trying to convince folks of the lie that this was Richard's fault ;) I won't be able to do so in Kona since I won't be attending - so I'm going to aim to have this feature be implemented by then.
I'm quite confident of the approach in this patch, which simply maps the static-invoker 'thunk' back to the corresponding call-operator (specialization).
Thanks!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291397 91177308-0d34-0410-b5e6-96231b3b80d8
This implements something like the current direction of DR1581: we use a narrow
syntactic check to determine the set of places where a constant expression
could be evaluated, and only instantiate a constexpr function or variable if
it's referenced in one of those contexts, or is odr-used.
It's not yet clear whether this is the right set of syntactic locations; we
currently consider all contexts within templates that would result in odr-uses
after instantiation, and contexts within list-initialization (narrowing
conversions take another victim...), as requiring instantiation. We could in
principle restrict the former cases more (only const integral / reference
variable initializers, and contexts in which a constant expression is required,
perhaps). However, this is sufficient to allow us to accept libstdc++ code,
which relies on GCC's behavior (which appears to be somewhat similar to this
approach).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291318 91177308-0d34-0410-b5e6-96231b3b80d8
copy constructors of classes with array members, instead using
ArrayInitLoopExpr to represent the initialization loop.
This exposed a bug in the static analyzer where it was unable to differentiate
between zero-initialized and unknown array values, which has also been fixed
here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289618 91177308-0d34-0410-b5e6-96231b3b80d8
Reworked fix after comments from Richard Smith. We must skip all
CapturedDecl-based contexts when trying to get correct mangling number
context.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286953 91177308-0d34-0410-b5e6-96231b3b80d8
Clang emits error message for the following code:
```
template <class F> void parallel_loop(F &&f) { f(0); }
int main() {
int x;
parallel_loop([&](auto y) {
{
x = y;
};
});
}
```
$ clang++ --std=gnu++14 clang_test.cc -o clang_test
clang_test.cc:9:7: error: reference to local variable 'x' declared in enclosing function 'main'
x = y;
^
clang_test.cc:2:48: note: in instantiation of function template specialization 'main()::(anonymous class)::operator()<int>' requested here
template <class F> void parallel_loop(F &&f) { f(0); }
^
clang_test.cc:6:3: note: in instantiation of function template specialization 'parallel_loop<(lambda at clang_test.cc:6:17)>' requested here parallel_loop([&](auto y) {
^
clang_test.cc:5:7: note: 'x' declared here
int x;
^
1 error generated.
Patch fixes this issue.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286584 91177308-0d34-0410-b5e6-96231b3b80d8
aren't captured by lambdas with a default capture specifier
This commit is a follow-up to r286354. It avoids the -Wshadow warning for
variables which shadow variables that aren't captured by lambdas with a default
capture specifier. It provides an additional note that points to location of
the capture.
The old behaviour is preserved with -Wshadow-all or -Wshadow-uncaptured-local.
rdar://14984176
Differential Revision: https://reviews.llvm.org/D26448
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286465 91177308-0d34-0410-b5e6-96231b3b80d8
There was a bug in the implementation of captured statements. If it has
a lambda expression in it and the same lambda expression is used outside
the captured region, clang produced an error:
```
error: definition with same mangled name as another definition
```
Here is an example:
```
struct A {
template <typename L>
void g(const L&) { }
};
template<typename T>
void f() {
{
A().g([](){});
}
A().g([](){});
}
int main() {
f<void>();
}
```
Error report:
```
main.cpp:3:10: error: definition with same mangled name as another
definition
void g(const L&) { }
^
main.cpp:3:10: note: previous definition is here
```
Patch fixes this bug.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284229 91177308-0d34-0410-b5e6-96231b3b80d8
I'm told that some optimizers like lambdas a lot more than mem_fn.
Given that the readability difference is basically nil, and we seem to
use lambdas basically everywhere else, it seems sensible to just use
lambdas.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276577 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Space for storing the //constraint-expression// of the
//requires-clause// associated with a `TemplateParameterList` is
arranged by taking a bit out of the `NumParams` field for the purpose
of determining whether there is a //requires-clause// or not, and by
adding to the trailing objects tied to the `TemplateParameterList`. An
accessor is provided.
An appropriate argument is supplied to `TemplateParameterList::Create`
at the various call sites.
Serialization changes will addressed as the Concepts implementation
becomes more solid.
Drive-by fix:
This change also replaces the custom
`FixedSizeTemplateParameterListStorage` implementation with one that
follows the interface provided by `llvm::TrailingObjects`.
Reviewers: aaron.ballman, faisalv, rsmith
Subscribers: cfe-commits, nwilson
Differential Revision: https://reviews.llvm.org/D19322
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276069 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
if we are parsing a template specialization.
This commit makes changes to clear the TemplateParamScope bit and set
the TemplateParamParent field of the current scope to null if a template
specialization is being parsed.
Before this commit, Sema::ActOnStartOfLambdaDefinition would check
whether the parent template scope had any decls to determine whether
or not a template specialization was being parsed. This wasn't correct
since it couldn't distinguish between a real template specialization and
a template defintion with an unnamed template parameter (only template
parameters with names are added to the scope's decl list). To fix the
bug, this commit changes the code to check the pointer to the parent
template scope rather than the decl list.
rdar://problem/23440346
Differential Revision: http://reviews.llvm.org/D19175
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@267975 91177308-0d34-0410-b5e6-96231b3b80d8
Support the constexpr specifier on lambda expressions - and support its inference from the lambda call operator's body.
i.e.
auto L = [] () constexpr { return 5; };
static_assert(L() == 5); // OK
auto Implicit = [] (auto a) { return a; };
static_assert(Implicit(5) == 5);
We do not support evaluation of lambda's within constant expressions just yet.
Implementation Strategy:
- teach ParseLambdaExpressionAfterIntroducer to expect a constexpr specifier and mark the invented function call operator's declarator's decl-specifier with it; Have it emit fixits for multiple decl-specifiers (mutable or constexpr) in this location.
- for cases where constexpr is not explicitly specified, have buildLambdaExpr check whether the invented function call operator satisfies the requirements of a constexpr function, by calling CheckConstexprFunctionDecl/Body.
Much obliged to Richard Smith for his patience and his care, in ensuring the code is clang-worthy.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264513 91177308-0d34-0410-b5e6-96231b3b80d8
Erich Keane