| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
Denis Zobnin.
This patch adds support of #pragma vtordisp inside functions in attempt to improve compatibility. Microsoft compiler appears to save the stack of vtordisp modes on entry of struct methods' bodies and restore it on exit (method-local vtordisp).
Differential Revision: http://reviews.llvm.org/D14467
llvm-svn: 253650
|
| |
|
|
|
|
|
|
|
|
|
|
| |
ConstantEvaluated while substituting into non-type template argument defaults.
Also address a typo from a prior patch that performed a similar fix during Parsing of default non-type template arguments. I left the RAII ExpressionEvaluationContext variable Name as Unevaluated though we had switched the context to ConstantEvaluated.
There should be no functionality change here - since when expression evaluation context is popped off, for the most part these two contexts currently behave similarly in regards to lambda diagnostics and odr-use tracking.
Like its parsing counterpart, this patch presages the advent of constexpr lambda patches...
llvm-svn: 253590
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
from Unevaluated to ConstantEvaluated.
This patch emits a more appropriate (but still noisy) diagnostic stream when a lambda-expression is encountered within a non-type default argument.
For e.g. template<int N = ([] { return 5; }())> int f();
As opposed to complaining that a lambda expression is not allowed in an unevaluated operand, the patch complains about the lambda being forbidden in a constant expression context (which will be allowed in C++17 now that they have been accepted by EWG, unless of course CWG or national bodies (that have so far shown no signs of concern) rise in protest)
As I start submitting patches for constexpr lambdas (http://wg21.link/P0170R0) under C++1z (OK'd by Richard Smith at Kona), this will be one less change to make.
Thanks!
llvm-svn: 253431
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
other than the top level, we issue an error. This breaks a fair amount of C++
code wrapping C libraries, where the C library is #included within a namespace
/ extern "C" combination, because the C library (probably) includes C++
standard library headers which may be within modules.
Without modules, this setup is harmless if (and *only* if) the corresponding
standard library module was already included outside the namespace, so
downgrade the error to a default-error extension in that case, so that it can
be selectively disabled for such misbehaving libraries.
llvm-svn: 253398
|
| |
|
|
|
|
| |
DiagnosticsEngine and Preprocessor. Everything the preprocessor was being used for can be acquired from Sema.
llvm-svn: 253158
|
| |
|
|
|
|
| |
ParserDiagnostic.h diagnostics.
llvm-svn: 253143
|
| |
|
|
| |
llvm-svn: 253136
|
| |
|
|
| |
llvm-svn: 253135
|
| |
|
|
| |
llvm-svn: 253134
|
| |
|
|
| |
llvm-svn: 253133
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
Differences from the GCC extension:
* __auto_type is also permitted in C++ (but only in places where
it could appear in C), allowing its use in headers that might
be shared across C and C++, or used from C++98
* __auto_type can be combined with a declarator, as with C++ auto
(for instance, "__auto_type *p")
* multiple variables can be declared in a single __auto_type
declaration, with the C++ semantics (the deduced type must be
the same in each case)
This patch also adds a missing restriction on applying typeof to
a bit-field, which GCC has historically rejected in C (due to
lack of clarity as to whether the operand should be promoted).
The same restriction also applies to __auto_type in C (in both
GCC and Clang).
This also fixes PR25449.
Patch by Nicholas Allegra!
llvm-svn: 252690
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
std::initializer_list<T> type. Instead, the list must contain a single element
and the type is deduced from that.
In Clang 3.7, we warned by default on all the cases that would change meaning
due to this change. In Clang 3.8, we will support only the new rules -- per
the request in N3922, this change is applied as a Defect Report against earlier
versions of the C++ standard.
This change is not entirely trivial, because for lambda init-captures we
previously did not track the difference between direct-list-initialization and
copy-list-initialization. The difference was not previously observable, because
the two forms of initialization always did the same thing (the elements of the
initializer list were always copy-initialized regardless of the initialization
style used for the init-capture).
llvm-svn: 252688
|
| |
|
|
|
|
| |
type parameters off the scope, and fix the cases where we failed to do so.
llvm-svn: 251875
|
| |
|
|
|
|
|
| |
Most of the cases belong into an anonymous namespace. No functionality
change intended.
llvm-svn: 251514
|
| |
|
|
|
|
| |
of await_* calls, and AST representation for same.
llvm-svn: 251387
|
| |
|
|
|
|
| |
yield / return.
llvm-svn: 250993
|
| |
|
|
|
|
| |
range-based for loop. NFC
llvm-svn: 250990
|
| |
|
|
|
|
| |
offsetof handling code. Also use a range-based for loop. NFC
llvm-svn: 250989
|
| |
|
|
|
|
| |
loop. NFC
llvm-svn: 250988
|
| |
|
|
|
|
| |
co_await modifier on range-based for loop, co_return statement.
llvm-svn: 250985
|
| |
|
|
|
|
|
|
|
|
| |
Summary: It breaks the build for the ASTMatchers
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D13893
llvm-svn: 250827
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Replace empty bodies of default constructors and destructors with '= default'.
Reviewers: bkramer, klimek
Subscribers: klimek, alexfh, cfe-commits
Differential Revision: http://reviews.llvm.org/D13890
llvm-svn: 250822
|
| |
|
|
|
|
|
|
| |
directive
Clang skipped annot_pragma_openmp token, while it should be considered as a stop token while skipping tokens.
llvm-svn: 250684
|
| |
|
|
|
|
| |
We already silently ignore the /RTC, which controls the same functionality.
llvm-svn: 250099
|
| |
|
|
|
|
|
| |
the "" and the suffix; that breaks names such as 'operator""if'. For symmetry,
also remove the space between the 'operator' and the '""'.
llvm-svn: 249641
|
| |
|
|
|
|
|
|
|
|
| |
minor cleanups
Patch by Eugene Zelenko!
Differential Revision: http://reviews.llvm.org/D13406
llvm-svn: 249484
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In versions of clang prior to r238238, __declspec was recognized as a keyword in
all modes. It was then changed to only be enabled when Microsoft or Borland
extensions were enabled (and for CUDA, as a temporary measure). There is a
desire to support __declspec in Playstation code, and possibly other
environments. This commit adds a command-line switch to allow explicit
enabling/disabling of the recognition of __declspec as a keyword. Recognition
is enabled by default in Microsoft, Borland, CUDA, and PS4 environments, and
disabled in all other environments.
Patch by Warren Ristow!
llvm-svn: 249279
|
| |
|
|
| |
llvm-svn: 249259
|
| |
|
|
|
|
|
|
|
|
|
| |
Parsing and sema analysis for 'simd' clause in 'ordered' directive.
Description
If the simd clause is specified, the ordered regions encountered by any thread will use only a single SIMD lane to execute the ordered
regions in the order of the loop iterations.
Restrictions
An ordered construct with the simd clause is the only OpenMP construct that can appear in the simd region
llvm-svn: 248696
|
| |
|
|
|
|
|
|
| |
OpenMP 4.1 extends format of '#pragma omp ordered'. It adds 3 additional clauses: 'threads', 'simd' and 'depend'.
If no clause is specified, the ordered construct behaves as if the threads clause had been specified. If the threads clause is specified, the threads in the team executing the loop region execute ordered regions sequentially in the order of the loop iterations.
The loop region to which an ordered region without any clause or with a threads clause binds must have an ordered clause without the parameter specified on the corresponding loop directive.
llvm-svn: 248569
|
| |
|
|
|
|
|
|
|
|
| |
If an import directive was put into wrong context, the error message was obscure,
complaining on misbalanced braces. To get more descriptive messages, annotation
tokens related to modules are processed where they must not be seen.
Differential Revision: http://reviews.llvm.org/D11844
llvm-svn: 248085
|
| |
|
|
|
|
|
|
| |
related. NFC.
Eric has replied and has demanded the patch be reverted.
llvm-svn: 247702
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and related. NFC.
Summary:
This is the first patch in the series to migrate Triple's (which are ambiguous)
to TargetTuple's (which aren't).
For the moment, TargetTuple simply passes all requests to the Triple object it
holds. Once it has replaced Triple, it will start to implement the interface in
a more suitable way.
This change makes some changes to the public C++ API. In particular,
InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer()
now take TargetTuples instead of Triples. The other public C++ API's have
been left as-is for the moment to reduce patch size.
This commit also contains a trivial patch to clang to account for the C++ API
change. Thanks go to Pavel Labath for fixing LLDB for me.
Reviewers: rengolin
Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10969
llvm-svn: 247692
|
| |
|
|
|
|
| |
LLDB needs to be updated in the same commit.
llvm-svn: 247686
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is the first patch in the series to migrate Triple's (which are ambiguous)
to TargetTuple's (which aren't).
For the moment, TargetTuple simply passes all requests to the Triple object it
holds. Once it has replaced Triple, it will start to implement the interface in
a more suitable way.
This change makes some changes to the public C++ API. In particular,
InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer()
now take TargetTuples instead of Triples. The other public C++ API's have
been left as-is for the moment to reduce patch size.
This commit also contains a trivial patch to clang to account for the C++ API
change.
Reviewers: rengolin
Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10969
llvm-svn: 247683
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause.
Format of 'if' clause is as follows:
```
if([ directive-name-modifier :] scalar-logical-expression)
```
The restriction rules are also changed.
1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'.
2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive.
3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive.
'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied.
llvm-svn: 246747
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now we can parse code like this:
struct A {
int field;
};
int f(A o) {
__asm mov eax, o.field
}
Fixes PR19117.
llvm-svn: 246088
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SourceRange
Summary:
- Store the exception specification range's begin and end SourceLocation in DeclaratorChuck::FunctionTypeInfo. These SourceLocations can be used in a FixItHint Range.
- Add diagnostic; function concept having an exception specification.
Reviewers: hubert.reinterpretcast, fraggamuffin, faisalv, aaron.ballman, rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11789
llvm-svn: 246005
|
| |
|
|
|
|
|
|
| |
Adds parsing/sema analysis/serialization/deserialization for array sections in OpenMP constructs (introduced in OpenMP 4.0).
Currently it is allowed to use array sections only in OpenMP clauses that accepts list of expressions.
Differential Revision: http://reviews.llvm.org/D10732
llvm-svn: 245937
|
| |
|
|
|
|
| |
Add parsing/sema analysis for 'simdlen' clause in simd directives. Also add check that if both 'safelen' and 'simdlen' clauses are specified, the value of 'simdlen' parameter is less than the value of 'safelen' parameter.
llvm-svn: 245692
|
| |
|
|
|
|
|
| |
non-visible definition, skip the new definition to avoid ending up with a
function with multiple definitions.
llvm-svn: 245664
|
| |
|
|
|
|
| |
Standard allows to use 'uval' and 'ref' modifiers in 'linear' clause for variables with reference types only. Added check for it and modified test.
llvm-svn: 245556
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenMP 4.1 adds 3 optional modifiers to 'linear' clause.
Format of 'linear' clause has changed to:
```
linear(linear-list[ : linear-step])
```
where linear-list is one of the following
```
list
modifier(list)
```
where modifier is one of the following:
```
ref (C++)
val (C/C++)
uval (C++)
```
Patch adds parsing and sema analysis for these modifiers.
llvm-svn: 245550
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR23542)
This enables Clang to correctly handle code such as:
struct __declspec(dllexport) S {
int x = 42;
};
where it would otherwise error due to trying to generate the default
constructor before the in-class initializer for x has been parsed.
Differential Revision: http://reviews.llvm.org/D11850
llvm-svn: 245139
|
| |
|
|
|
|
|
|
| |
openmp directive
Add parsing of openmp directives inside structs/unions in C mode.
llvm-svn: 244719
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds the new unroll metadata "llvm.loop.unroll.enable" which directs
the optimizer to unroll a loop fully if the trip count is known at compile time, and
unroll partially if the trip count is not known at compile time. This differs from
"llvm.loop.unroll.full" which explicitly does not unroll a loop if the trip count is not
known at compile time
With this change "#pragma unroll" generates "llvm.loop.unroll.enable" rather than
"llvm.loop.unroll.full" metadata. This changes the semantics of "#pragma unroll" slightly
to mean "unroll aggressively (fully or partially)" rather than "unroll fully or not at all".
The motivating example for this change was some internal code with a loop marked
with "#pragma unroll" which only sometimes had a compile-time trip count depending
on template magic. When the trip count was a compile-time constant, everything works
as expected and the loop is fully unrolled. However, when the trip count was not a
compile-time constant the "#pragma unroll" explicitly disabled unrolling of the loop(!).
Removing "#pragma unroll" caused the loop to be unrolled partially which was desirable
from a performance perspective.
llvm-svn: 244467
|
| |
|
|
|
|
| |
Last part of PR11974.
llvm-svn: 244339
|
| |
|
|
|
|
|
| |
This is committed on behalf of Kelvin Li
http://reviews.llvm.org/D11469?id=31227
llvm-svn: 244325
|
| |
|
|
| |
llvm-svn: 244024
|
| |
|
|
|
|
| |
Parsing of pragmas followed by a class member declaration is outlined into a separate function Parser::ParseCXXClassMemberDeclarationWithPragmas().
llvm-svn: 243739
|