| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
24 tests have been updated for C++11 compatibility.
llvm-svn: 266387
|
|
|
|
|
|
|
| |
Added expected diagnostics new to C++11.
Expanded RUN line to: default, C++98/03 and C++11.
llvm-svn: 253371
|
|
|
|
|
|
|
|
|
|
|
| |
So, we now reject that. We also warn for any external-linkage global
variable named main in C, because it results in undefined behavior.
PR: 24309
Differential Revision: http://reviews.llvm.org/D11658
Reviewed by: rsmith
llvm-svn: 245051
|
|
|
|
|
|
|
|
|
| |
We didn't correctly expect a QualifiedTypeLoc when faced with fixing a
variable array type into a constant array type.
Differential Revision: http://reviews.llvm.org/D8958
llvm-svn: 235251
|
|
|
|
|
|
|
|
|
| |
Previously if an enumeration was used in a nested name specifier in pre-C++11
language dialect, error message was 'XXX is not a class, namespace, or scoped
enumeration'. This patch removes the word 'scoped' as in C++11 any enumeration
may be used in this context.
llvm-svn: 226410
|
|
|
|
|
|
| |
type.
llvm-svn: 224388
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-frewrite-includes. [PR20321]"
We've decided to make the core rewriter class and PP rewriters mandatory.
They're only a few hundred lines of code in total and not worth supporting as a
distinct build configuration, especially since doing so disables key compiler
features.
This reverts commit r213150.
Revert "clang/test: Introduce the feature "rewriter" for --enable-clang-rewriter."
This reverts commit r213148.
Revert "Move clang/test/Frontend/rewrite-*.c to clang/test/Frontend/Rewriter/"
This reverts commit r213146.
llvm-svn: 213159
|
|
|
|
| |
llvm-svn: 213148
|
|
|
|
|
|
|
|
|
| |
C++ [basic.start.main]p1: "It shall have a return type of type int"
ISO C is also clear about this, so only accept 'int' with qualifiers in GNUMode
C.
llvm-svn: 212171
|
|
|
|
|
|
|
| |
function parameter. One of our existing test cases was XFAILed because
of this. This fixes the issue and un-XFAILs the test.
llvm-svn: 210026
|
|
|
|
|
|
| |
test contents are acceptable. No diagnostics expected from this test.
llvm-svn: 209891
|
|
|
|
|
|
| |
It's still XFAIL, but slightly closer to passing.
llvm-svn: 209729
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Naming the destructor using a typedef-name for the class-name is
well-formed.
This fixes PR19620.
Reviewers: rsmith, doug.gregor
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3583
llvm-svn: 209319
|
|
|
|
|
|
|
|
| |
This was accidentally committed.
This reverts commit r207892.
llvm-svn: 207893
|
|
|
|
|
|
|
|
|
| |
Naming the destructor using a typedef-name for the class-name is
well-formed.
This fixes PR19620.
llvm-svn: 207892
|
|
|
|
|
|
| |
declared in different namespaces in the same inline namespace set.
llvm-svn: 204082
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
name specifier.
Rather than simply saying "X is not a class or namespace", clarify what
X is by providing the aka type in the case where X is a type, or
pointing to the named declaration if there's an unambiguous one to refer
to. In the ambiguous case, the ambiguities are already enumerated
(though could be clarified by describing what kind of entities they are)
Included a few FIXMEs in tests where some further improvements could be
made.
llvm-svn: 201038
|
|
|
|
|
|
|
|
| |
redeclaration, not just when looking them up for a use -- we need the implicit
declaration to appropriately check various properties of them (notably, whether
they're deleted).
llvm-svn: 200729
|
|
|
|
| |
llvm-svn: 199783
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
scope, be careful about function-scope declarations (which are not declared in
their semantic context).
llvm-svn: 193671
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unlike with namespaces, searching inside of classes requires also
checking the access to correction candidates (i.e. don't suggest a
correction to a private class member for a correction occurring outside
that class and its methods or friends).
Included is a small (one line) fix for a bug, that was uncovered while
cleaning up the unit tests, where the decls from a TypoCorrection candidate
were preserved in new TypoCorrection candidates that are derived (copied)
from the old TypoCorrection--notably when creating a new candidate by
changing the NestedNameSpecifier associated with the base idenitifer.
llvm-svn: 191449
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
variable from being the function to being the enclosing namespace scope (in
C++) or the TU (in C). This allows us to fix a selection of related issues
where we would build incorrect redeclaration chains for such declarations, and
fail to notice type mismatches.
Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern,
which is only found when searching scopes, and not found when searching
DeclContexts. Such a declaration is only made visible in its DeclContext if
there are no non-LocalExtern declarations.
llvm-svn: 191064
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a local extern declaration redeclares some other entity, the type of that
entity is merged with the prior type if the prior declaration is visible (in C)
or is declared in the same scope (in C++).
- Make LookupRedeclarationWithLinkage actually work in C++, use it in the right
set of cases, and make it track whether it found a shadowed declaration.
- Track whether we found a declaration in the same scope (for C++) including
across serialization and template instantiation.
llvm-svn: 188307
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sema::MergeFunctionDecl attempts merging two decls even if the old decl
is invalid. This can lead to interesting circumstances where we
successfully merge the decls but the result makes no sense.
Take the following for example:
template <typename T>
int main(void);
int main(void);
Sema will not consider these to be overloads of the same name because
main can't be overloaded, which means that this must be a redeclaration.
In this case the templated decl is compatible with the non-templated
decl allowing the Sema::CheckFunctionDeclaration machinery to move on
and do bizarre things like setting the previous decl of a non-templated
decl to a templated decl!
The way I see it, we should just bail from MergeFunctionDecl if the old
decl is invalid.
This fixes PR16531.
llvm-svn: 185779
|
|
|
|
|
|
|
|
|
|
| |
This boils down to us sending invalid function decls to
CheckFunctionDeclaration becauswe we did not consider that CheckMain
could cause the decl to be invalid. Instead, interogate the new decl's
main-validity and *then* send it over to get CheckFunctionDeclaration'd
if it was still valid after calling CheckMain.
llvm-svn: 185745
|
|
|
|
|
|
|
|
| |
statement in constexpr functions. Everything which doesn't require variable
mutation is also allowed as an extension in C++11. 'void' becomes a literal
type to support constexpr functions which return 'void'.
llvm-svn: 180022
|
|
|
|
|
|
|
|
|
| |
C++1y, so stop adding the 'const' there. Provide a compatibility warning for
code relying on this in C++11, with a fix-it hint. Update our lazily-written
tests to add the const, except for those ones which were testing our
implementation of this rule.
llvm-svn: 179969
|
|
|
|
|
|
| |
Fixes the bootstrap regression I introduced in r179067.
llvm-svn: 179079
|
|
|
|
|
|
|
|
|
|
|
|
| |
contexts not represented by scopes.
This fixes a regression I introduced in r178136, where we would not
consider the using directives from the semantic declaration contexts
that aren't represented by the lexical scopes (Scope) when performing
unqualified name lookup. This lead to horribly funny diagnostics like
"no identifier named 'foo'; did you mean 'foo'?".
llvm-svn: 179067
|
|
|
|
|
|
|
|
|
| |
visible. There's a lot of potential badness in how we're modelling
these things, but getting this much correct is reasonably easy.
rdar://13535367
llvm-svn: 178488
|
|
|
|
|
|
| |
unqualified name lookup into declarations contexts represented by the qualified-id but not in the actual scope hierarchy.
llvm-svn: 178136
|
|
|
|
|
|
| |
(but we happen to get this part right).
llvm-svn: 177958
|
|
|
|
|
|
|
| |
using-declarations with names which look constructor-like are interpreted as
constructor names.
llvm-svn: 177957
|
|
|
|
| |
llvm-svn: 176474
|
|
|
|
|
|
| |
forms of 'main' which we accept as an extension.
llvm-svn: 173758
|
|
|
|
| |
llvm-svn: 173756
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove pre-standard restriction on explicitly-defaulted copy constructors with
'incorrect' parameter types, and instead just make those special members
non-trivial as the standard requires.
This required making CXXRecordDecl correctly handle classes which have both a
trivial and a non-trivial special member of the same kind.
This also fixes PR13217 by reimplementing DiagnoseNontrivial in terms of the
new triviality computation technology.
llvm-svn: 169667
|
|
|
|
|
|
|
| |
Introduces more clear scoping flags & flag combinations which should hopefully
be more understandable.
llvm-svn: 167766
|
|
|
|
|
|
| |
Fix to regression caused by r167650, caught by Richard Smith in code review.
llvm-svn: 167653
|
|
|
|
|
|
|
|
|
|
|
|
| |
C++11 3.3.3/2 "A parameter name shall not be redeclared in the outermost block
of the function definition nor in the outermost block of any handler associated
with a function-try-block."
It's not totally clear to me whether the "FIXME" case is covered by this, but
Richard Smith thinks it probably should be. It's just a bit more involved to
fix that case.
llvm-svn: 167650
|
|
|
|
|
|
| |
VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive.
llvm-svn: 166280
|
|
|
|
| |
llvm-svn: 162586
|
|
|
|
| |
llvm-svn: 155942
|
|
|
|
| |
llvm-svn: 155940
|
|
|
|
|
|
| |
explaining that.
llvm-svn: 155598
|
|
|
|
|
|
|
|
| |
access expression is the start of a template-id, ignore function
templates found in the context of the entire postfix-expression. Fixes
PR11856.
llvm-svn: 152520
|
|
|
|
| |
llvm-svn: 151005
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1358, 1360, 1452 and 1453.
- Instantiations of constexpr functions are always constexpr. This removes the
need for separate declaration/definition checking, which is now gone.
- This makes it possible for a constexpr function to be virtual, if they are
only dependently virtual. Virtual calls to such functions are not constant
expressions.
- Likewise, it's now possible for a literal type to have virtual base classes.
A constexpr constructor for such a type cannot actually produce a constant
expression, though, so add a special-case diagnostic for a constructor call
to such a type rather than trying to evaluate it.
- Classes with trivial default constructors (for which value initialization can
produce a fully-initialized value) are considered literal types.
- Classes with volatile members are not literal types.
- constexpr constructors can be members of non-literal types. We do not yet use
static initialization for global objects constructed in this way.
llvm-svn: 150359
|
|
|
|
|
|
| |
lvalue-to-rvalue conversions in constant expressions.
llvm-svn: 150145
|