| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
already knows how it was spelled.
llvm-svn: 198375
|
|
|
|
|
|
| |
engine knows how to handle NamedDecl objects.
llvm-svn: 198365
|
|
|
|
|
|
| |
semantic attributes easier (and not require hard-coded strings). This requires a getSpelling() function on the Attr class, which is table-driven. Updates a handful of cases where a hard-coded string was being used to test the functionality out. Updating associated test cases for the improved quoting.
llvm-svn: 198055
|
|
|
|
|
|
| |
name will be quoted in the diagnostic. Manually added some quotes to a diagnostic for consistency. Updated the test cases as appropriate.
llvm-svn: 198054
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this patch, record decls with invalid out-of-line method delcs would
sometimes be marked invalid, but not always. With this patch, they are
consistently never marked invalid.
(The code to do this was added in
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100809/033154.html
, but the test from that revision is still passing.)
As far as I can tell, this was the only place where a class was marked invalid
after its definition was complete.
llvm-svn: 197848
|
|
|
|
|
|
|
|
| |
directly and check the resulting value.
No functional changes intended.
llvm-svn: 197678
|
|
|
|
|
|
| |
change intended -- this only replaces Boolean uses of getAttr.
llvm-svn: 197648
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We would previously emit redundant diagnostics for the following code:
struct S {
virtual ~S() = delete;
void operator delete(void*, int);
void operator delete(void*, double);
} s;
First we would check on ~S() and error about the ambigous delete functions,
and then we would error about using the deleted destructor.
If the destructor is deleted, there's no need to check it.
Also, move the check from Sema::ActOnFields to CheckCompleteCXXClass. These
are run at almost the same time, called from ActOnFinishCXXMemberSpecification.
However, CHeckCompleteCXXClass may mark a defaulted destructor as deleted, and
if that's the case we don't want to check it.
Differential Revision: http://llvm-reviews.chandlerc.com/D2421
llvm-svn: 197509
|
|
|
|
|
|
|
|
|
| |
This reverts commit 2b43f500cfea10a8c59c986dcfc24fd08eecc77d.
This was accidentally committed because I failed to notice my client
wasn't clean prior to submitting a fix for a crasher.
llvm-svn: 197410
|
|
|
|
| |
llvm-svn: 197408
|
|
|
|
|
|
|
|
| |
The check for bitfields that are longer than their base type needed to
be checked in microsoft mode (cl.exe does not support the C++ extnetion
for bitfields longer than their type).
llvm-svn: 197186
|
|
|
|
|
|
|
|
| |
Thanks to Jonathan Sauer for providing initial test cases.
Fixes PR16093 and PR18147.
llvm-svn: 197150
|
|
|
|
|
|
|
|
|
| |
more than one such initializer in a union, make mem-initializers override
default initializers for other union members, handle anonymous unions with
anonymous struct members better. Fix a couple of semi-related bugs exposed by
the tests for same.
llvm-svn: 196892
|
|
|
|
| |
llvm-svn: 196510
|
|
|
|
|
|
|
|
|
|
| |
within their namespace, and such a redeclaration isn't required to be a
definition any more.
Update DR status page to say Clang 3.4 instead of SVN and add new Clang 3.5
category (but keep Clang 3.4 yellow for now).
llvm-svn: 196481
|
|
|
|
|
|
|
| |
This patch tries to avoid unrelated changes other than fixing a few
hyphen-related ambiguities in nearby lines.
llvm-svn: 196466
|
|
|
|
|
|
|
| |
name from the enclosing namespace set if the name is specified as a
qualified-id.
llvm-svn: 196464
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
classes.
Clang currently croaks on the following:
struct X1 {
struct X2 {
int L = ([] (int i) { return i; })(2);
};
};
asserting that the containing lexical context of the lambda is not Sema's cur context, when pushing the lambda's decl context on.
This occurs because (prior to this patch) getContainingDC always returns the non-nested class for functions at class scope (even for inline member functions of nested classes (to account for delayed parsing of their bodies)). The patch addresses this by having getContainingDC always return the lexical DC for a lambda's call operator.
Link to the bug: http://llvm.org/bugs/show_bug.cgi?id=18052
Link to Richard Smith's feedback on phabricator: http://llvm-reviews.chandlerc.com/D2331
Thanks!
llvm-svn: 196423
|
|
|
|
|
|
|
|
|
|
|
| |
super another initializer and when the implementation does not delegate to
another initializer via a call on 'self'.
A secondary initializer is an initializer method not marked as a designated
initializer within a class that has at least one initializer marked as a
designated initializer.
llvm-svn: 196318
|
|
|
|
|
|
|
|
| |
calls on
super an initializer that is not a designated one or any initializer on self.
llvm-svn: 196317
|
|
|
|
|
|
|
|
| |
does not chain to
an init method that is a designated initializer for the superclass.
llvm-svn: 196316
|
|
|
|
|
|
| |
downstream code.
llvm-svn: 195687
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
data member definitions when the variable has an initializer
in its declaration.
For the following code:
struct S {
static const int x = 42;
};
const int S::x = 42;
This patch changes the diagnostic from:
a.cc:4:14: error: redefinition of 'x'
const int S::x = 42;
^
a.cc:2:20: note: previous definition is here
static const int x = 42;
^
to:
a.cc:4:18: error: static data member 'x' already has an initializer
const int S::x = 42;
^
a.cc:2:24: note: previous initialization is here
static const int x = 42;
^
Differential Revision: http://llvm-reviews.chandlerc.com/D2235
llvm-svn: 195306
|
|
|
|
|
|
|
|
|
| |
- If a deprecated class refers to another deprecated class, do not warn.
- @implementations of a deprecated class can refer to other deprecated things.
Fixes <rdar://problem/15407366> and <rdar://problem/15466783>.
llvm-svn: 195259
|
|
|
|
|
|
| |
flag the LinkageSpecDecl as being implicitly generated too.
llvm-svn: 195255
|
|
|
|
|
|
| |
per Doug/Jordan comments. // rdar://15454846.
llvm-svn: 195066
|
|
|
|
|
|
|
| |
on struct/union/class instead of typedef of
such types. // rdar://15454846
llvm-svn: 195061
|
|
|
|
|
|
|
| |
it's also __attribute__((used)), since that undoes the problematic part of
'inline'.
llvm-svn: 194916
|
|
|
|
|
|
|
| |
projects are relying on such (questionable) practices, so we should give them
a way to opt out of this diagnostic.
llvm-svn: 194905
|
|
|
|
|
|
|
|
|
|
|
|
| |
representing the module import rather than making the module immediately
visible. This serves two goals:
* It avoids making declarations in the module visible prematurely, if we
walk past the #include during a tentative parse, for instance, and
* It gives a diagnostic (although, admittedly, not a very nice one) if
a header with a corresponding module is included anywhere other than
at the top level.
llvm-svn: 194782
|
|
|
|
|
|
|
| |
until after we've referenced the operator; otherwise, we might pick up a
not-yet-deduced type.
llvm-svn: 194775
|
|
|
|
|
|
| |
Per feedback from Jordan Rose I realized this wasn't the right way to go.
llvm-svn: 194664
|
|
|
|
|
|
|
|
|
| |
all bridge casts.
Also refine test case to capture the intention of this suppression. Essentially
some developers use __bridge_transfer as if it were a safe CFRelease.
llvm-svn: 194663
|
|
|
|
|
|
|
|
|
|
| |
bit fields of zero size. Warnings are generated in C++ mode and if
only such type is defined inside extern "C" block.
The patch fixed PR5065.
Differential Revision: http://llvm-reviews.chandlerc.com/D2151
llvm-svn: 194653
|
|
|
|
|
|
|
|
| |
management.
Fixes <rdar://problem/15432770>.
llvm-svn: 194647
|
|
|
|
|
|
|
|
| |
No Functionality change.
This refactoring avoids having to call getCurLambda right after PushLambdaScope, to obtain the LambdaScopeInfo that was created during the call to PushLambdaScope.
llvm-svn: 194438
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both Richard and I felt that the current wording in the working paper needed some tweaking - Please see http://llvm-reviews.chandlerc.com/D2035 for additional context and references to core-reflector messages that discuss wording tweaks.
What is implemented is what we had intended to specify in Bristol; but, recently felt that the specification might benefit from some tweaking and fleshing.
As a rough attempt to explain the semantics: If a nested lambda with a default-capture names a variable within its body, and if the enclosing full expression that contains the name of that variable is instantiation-dependent - then an enclosing lambda that is capture-ready (i.e. within a non-dependent context) must capture that variable, if all intervening nested lambdas can potentially capture that variable if they need to, and all intervening parent lambdas of the capture-ready lambda can and do capture the variable.
Of note, 'this' capturing is also currently underspecified in the working paper for generic lambdas. What is implemented here is if the set of candidate functions in a nested generic lambda includes both static and non-static member functions (regardless of viability checking - i.e. num and type of parameters/arguments) - and if all intervening nested-inner lambdas between the capture-ready lambda and the function-call containing nested lambda can capture 'this' and if all enclosing lambdas of the capture-ready lambda can capture 'this', then 'this' is speculatively captured by that capture-ready lambda.
Hopefully a paper for the C++ committee (that Richard and I had started some preliminary work on) is forthcoming.
This essentially makes generic lambdas feature complete, except for known bugs. The more prominent ones (and the ones I am currently aware of) being:
- generic lambdas and init-captures are broken - but a patch that fixes this is already in the works ...
- nested variadic expansions such as:
auto K = [](auto ... OuterArgs) {
vp([=](auto ... Is) {
decltype(OuterArgs) OA = OuterArgs;
return 0;
}(5)...);
return 0;
};
auto M = K('a', ' ', 1, " -- ", 3.14);
currently cause crashes. I think I know how to fix this (since I had done so in my initial implementation) - but it will probably take some work and back & forth with Doug and Richard.
A warm thanks to all who provided feedback - and especially to Doug Gregor and Richard Smith for their pivotal guidance: their insight and prestidigitation in such matters is boundless!
Now let's hope this commit doesn't upset the buildbot gods ;)
Thanks!
llvm-svn: 194188
|
|
|
|
| |
llvm-svn: 194068
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
members
Flexible array members only work out if they are the last field of a
record, however virtual bases would give us many situations where the
flexible array member would overlap with the virtual base fields.
It is unlikely in the extreme that this behavior was intended by the
user so raise a diagnostic instead of accepting. This is will not
reject conforming code because flexible array members are an extension
in C++ mode.
llvm-svn: 193920
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The determination of which diagnostics would be issued for certain
anonymous unions started to get a little ridiculous. Clean this up by
inverting the condition-tree's logic from dialect -> issue to
issue -> diagnostic.
As part of this cleanup, move ext_c99_flexible_array_member from
DiagnosticParseKinds.td to DiagnosticSemaKinds.td because it's driven by
Sema, not Parse.
Also, the liberty was taken to edit ext_c99_flexible_array_member to
match other, similar, diagnostics.
llvm-svn: 193919
|
|
|
|
|
|
|
| |
The declaration of a flexible array member was correctly diagnosed as an
extension in C89 mode but not in C++.
llvm-svn: 193918
|
|
|
|
| |
llvm-svn: 193917
|
|
|
|
| |
llvm-svn: 193916
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D2082
Adds a lang_c LinkageSpecDecl to lazily generated builtins. This enforces correct
behavior for builtins in a variety of cases without special treatment elsewhere within
the compiler (special treatment is removed by the patch). It also allows for C++
overloads of builtin functions, which Microsoft uses in their headers e.g.
_InterlockedExchangeAdd is an extern C builtin for the long type but an inline wrapper
for int type.
llvm-svn: 193896
|
|
|
|
|
|
| |
QualType with a SourceLocation stashed alongside.
llvm-svn: 193803
|
|
|
|
|
|
|
| |
backing warning is not used in one of its accessor methods.
// rdar://14989999
llvm-svn: 193439
|
|
|
|
|
|
| |
Without this patch we would warn and fail to output the function in the test.
llvm-svn: 193388
|
|
|
|
| |
llvm-svn: 193248
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A prior commit of this patch was reverted because it was within the blamelist's purview of a failing test. The failure of that test has been addressed here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131021/091546.html. Therefore I am recommitting this patch (all tests pass on windows, except for the usual modules & index suspects that never pass on my box).
Some background: Both Doug and Richard had asked me in Chicago to remove the circular reference in CXXRecordDecl to LambdaExpr by factoring out and storing the needed information from LambdaExpr directly into CXXRecordDecl.
In addition, I have added an IsGenericLambda flag - this makes life a little easier when we implement capturing, and are Sema-analyzing the body of a lambda (and the calloperator hasn't been wired to the closure class yet). Any inner lambdas can have potential captures that could require walking up the scope chain and checking if any generic lambdas are capture-ready. This 'bit' makes some of that checking easier.
No change in functionality.
This patch was approved by Doug with minor modifications (comments were cleaned up, and all data members were converted from bool/enum to unsigned, as requested):
http://llvm-reviews.chandlerc.com/D1856
Thanks!
llvm-svn: 193246
|
|
|
|
|
|
|
|
|
|
| |
They were causing CodeGenCXX/mangle-exprs.cpp to fail.
Revert "Remove the circular reference to LambdaExpr in CXXRecordDecl."
Revert "Again: Teach TreeTransform and family how to transform generic lambdas nested within templates and themselves."
llvm-svn: 193226
|