| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
unexpanded parameter pack" bit and that the recursive AST visitor can
then find those unexpanded parameter packs.
llvm-svn: 121899
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameter packs within a statement, type, etc. Use this visitor to
provide improved diagnostics for the presence of unexpanded parameter
packs in a full expression, base type, declaration type, etc., by
highlighting the unexpanded parameter packs and providing their names,
e.g.,
test/CXX/temp/temp.decls/temp.variadic/p5.cpp:28:85: error: declaration type
contains unexpanded parameter packs 'VeryInnerTypes',
'OuterTypes', ...
...VeryInnerTypes, OuterTypes>, pair<InnerTypes, OuterTypes> > types;
~~~~~~~~~~~~~~ ~~~~~~~~~~ ~~~~~~~~~~ ~~~~~~~~~~ ^
llvm-svn: 121883
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
whether the expression contains an unexpanded parameter pack, in the
same vein as the changes to the Type hierarchy. Compute this bit
within all of the Expr subclasses.
This change required a bunch of reshuffling of dependency
calculations, mainly to consolidate them inside the constructors and
to fuse multiple loops that iterate over arguments to determine type
dependence, value dependence, and (now) containment of unexpanded
parameter packs.
Again, testing is painfully sparse, because all of the diagnostics
will change and it is more important to test the to-be-written visitor
that collects unexpanded parameter packs.
llvm-svn: 121831
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and TemplateArgument with an operation that determines whether there
are any unexpanded parameter packs within that construct. Use this
information to diagnose the appearance of the names of parameter packs
that have not been expanded (C++ [temp.variadic]p5). Since this
property is checked often (every declaration, ever expression
statement, etc.), we extend Type and Expr with a bit storing the
result of this computation, rather than walking the AST each time to
determine whether any unexpanded parameter packs occur.
This commit is deficient in several ways, which will be remedied with
future commits:
- Expr has a bit to store the presence of an unexpanded parameter
pack, but it is never set.
- The error messages don't point out where the unexpanded parameter
packs were named in the type/expression, but they should.
- We don't check for unexpanded parameter packs in all of the places
where we should.
- Testing is sparse, pending the resolution of the above three
issues.
llvm-svn: 121724
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
particular, we only add the implement object parameter type if only
one of the function templates is a non-static member function
template.
Moreover, since this DR differs from existing practice in C++98/03,
this commit implements the existing practice (which ignores the
first parameter of the function template that is not the non-static
member function template) in C++98/03 mode.
llvm-svn: 119145
|
|
|
|
|
|
|
|
|
| |
in the order they occur within the class template, delaying
out-of-line member template partial specializations until after the
class has been fully instantiated. This fixes a regression introduced
by r118454 (itself a fix for PR8001).
llvm-svn: 118704
|
|
|
|
|
|
|
| |
on a friend declaration, skip template-ids which do not depend on the
current parameter list.
llvm-svn: 116911
|
|
|
|
|
|
| |
we may need to complete the type before looking into it.
llvm-svn: 116795
|
|
|
|
| |
llvm-svn: 116789
|
|
|
|
| |
llvm-svn: 116787
|
|
|
|
|
|
|
| |
construct an unsupported friend when there's a friend with a templated
scope specifier. Fixes a consistency crash, rdar://problem/8540527
llvm-svn: 116786
|
|
|
|
|
|
|
|
| |
of templated-scope friends by marking them invalid and white-listing all
accesses until such time as we implement them. Fixes a crash, this time
without a broken test case.
llvm-svn: 116364
|
|
|
|
|
|
|
| |
which is should have done from the beginning. As usual, the most
fun with this sort of change is updating all the testcases.
llvm-svn: 113090
|
|
|
|
| |
llvm-svn: 112477
|
|
|
|
| |
llvm-svn: 111611
|
|
|
|
|
|
| |
Avoids a crash.
llvm-svn: 111609
|
|
|
|
|
|
| |
type parameter pack is distinct from a template type parameter.
llvm-svn: 105464
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Revert much of the implementation of C++98/03 [temp.friend]p5 in
r103943 and its follow-ons r103948 and r103952. While our
implementation was technically correct, other compilers don't seem to
implement this paragraph (which forces the instantiation of friend
functions defined in a class template when a class template
specialization is instantiated), and doing so broke a bunch of Boost
libraries.
Since this behavior has changed in C++0x (which instantiates the
friend function definitions when they are used), we're going to skip
the nowhere-implemented C++98/03 semantics and go straight to the
C++0x semantics.
This commit is a band-aid to get Boost up and running again. It
doesn't really fix PR6952 (which this commit un-fixes), but it does
deal with the way Boost.Units abuses this particular paragraph.
llvm-svn: 104014
|
|
|
|
|
|
|
| |
functions defined inside a class template. Fixes PR6952, the last
Boost.Units failure.
llvm-svn: 103952
|
|
|
|
|
|
|
| |
class template conflicts with an existing (non-template)
definition. This is another part of PR6952.
llvm-svn: 103948
|
|
|
|
|
|
|
|
| |
within class templates be instantiated along with each class template
specialization, even if the functions are not used. Do so, as a baby
step toward PR6952.
llvm-svn: 103943
|
|
|
|
|
|
|
|
|
| |
specializations, substitute the deduced template arguments and check
the resulting substitution before concluding that template argument
deduction succeeds. This marvelous little fix makes a bunch of
Boost.Spirit tests start working.
llvm-svn: 102601
|
|
|
|
|
|
| |
two bugfixes which fix selfhost and (hopefully) the nightly tests.
llvm-svn: 102198
|
|
|
|
|
|
| |
same", which seems to break most C++ nightly test apps.
llvm-svn: 102174
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
way that C does. Among other differences, elaborated type specifiers
are defined to skip "non-types", which, as you might imagine, does not
include typedefs. Rework our use of IDNS masks to capture the semantics
of different kinds of declarations better, and remove most current lookup
filters. Removing the last remaining filter is more complicated and will
happen in a separate patch.
Fixes PR 6885 as well some spectrum of unfiled bugs.
llvm-svn: 102164
|
|
|
|
|
|
|
| |
ActOnClassTemplateSpecialization and being very confused.
Fixes PR6514 (for non-templated-scope friends).
llvm-svn: 101198
|
|
|
|
|
|
|
|
| |
code the first time.
Fixes PR6827.
llvm-svn: 101184
|
|
|
|
|
|
|
| |
ended up finding a function template that we didn't expect. Recover
more gracefully, and fix a similar issue for class templates.
llvm-svn: 101040
|
|
|
|
|
|
|
|
| |
Remove -faccess-control from -cc1; add -fno-access-control.
Make the driver pass -fno-access-control by default.
Update a bunch of tests to be correct under access control.
llvm-svn: 100880
|
|
|
|
|
|
| |
Fixes PR6752.
llvm-svn: 100806
|
|
|
|
| |
llvm-svn: 100753
|
|
|
|
|
|
|
|
|
|
|
| |
- When instantiating a friend type template, perform semantic
analysis on the resulting type.
- Downgrade the errors concerning friend type declarations that do
not refer to classes to ExtWarns in C++98/03. C++0x allows
practically any type to be befriended, and ignores the friend
declaration if the type is not a class.
llvm-svn: 100635
|
|
|
|
| |
llvm-svn: 99708
|
|
|
|
|
|
| |
pattern if it has a body.
llvm-svn: 99610
|
|
|
|
| |
llvm-svn: 99601
|
|
|
|
| |
llvm-svn: 99596
|
|
|
|
|
|
|
| |
we look for shadow friend decls in the appropriate scope before injecting
a new declaration.
llvm-svn: 99552
|
|
|
|
|
|
|
| |
the redeclaration chain. Recommitted from r99477 with a fix: we need to
merge in default template arguments from previous declarations.
llvm-svn: 99496
|
|
|
|
|
|
|
|
|
|
|
| |
buildbot. The tramp3d test fails.
--- Reverse-merging r99477 into '.':
U test/SemaTemplate/friend-template.cpp
U test/CXX/temp/temp.decls/temp.friend/p1.cpp
U lib/Sema/SemaTemplateInstantiateDecl.cpp
U lib/Sema/SemaAccess.cpp
llvm-svn: 99481
|
|
|
|
| |
llvm-svn: 99477
|
|
|
|
|
|
|
|
| |
since we have absolutely no way to match them when they are declared
nor do we have a way to represent these parsed-but-not-checked friend
declarations.
llvm-svn: 99407
|
|
|
|
| |
llvm-svn: 99389
|
|
|
|
|
|
|
|
|
| |
templates. So delay access-control diagnostics when (for example) the target
of a friend declaration is a specific specialization of a template.
I was surprised to find that this was required for an access-controlled selfhost.
llvm-svn: 99383
|
|
|
|
| |
llvm-svn: 98764
|
|
|
|
|
|
|
|
| |
*not* entering the context of the nested-name-specifier. This was
causing us to look into an uninstantiated template that we shouldn't
look into. Fixes PR6376.
llvm-svn: 97524
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sema::ActOnUninitializedDecl over to InitializationSequence (with
default initialization), eliminating redundancy. More importantly, we
now check that a const definition in C++ has an initilizer, which was
an #if 0'd code for many, many months. A few other tweaks were needed
to get everything working again:
- Fix all of the places in the testsuite where we defined const
objects without initializers (now that we diagnose this issue)
- Teach instantiation of static data members to find the previous
declaration, so that we build proper redeclaration
chains. Previously, we had the redeclaration chain but built it
too late to be useful, because...
- Teach instantiation of static data member definitions not to try
to check an initializer if a previous declaration already had an
initializer. This makes sure that we don't complain about static
const data members with in-class initializers and out-of-line
definitions.
- Move all of the incomplete-type checking logic out of
Sema::FinalizeDeclaratorGroup; it makes more sense in
ActOnUnitializedDecl.
There may still be a few places where we can improve these
diagnostics. I'll address that as a separate commit.
llvm-svn: 95657
|
|
|
|
|
|
|
|
| |
why the candidate is non-viable. There's a lot we can do to improve this, but
it's a good start. Further improvements should probably be integrated with the
bad-initialization reporting routines.
llvm-svn: 93277
|
|
|
|
| |
llvm-svn: 93177
|
|
|
|
|
|
|
|
|
| |
as parts of overload sets. Also, refer to constructors as 'constructors'
rather than functions.
Adjust a lot of tests.
llvm-svn: 92832
|
|
|
|
|
|
|
|
|
|
| |
InitializationSequence. Specially, switch initialization of a C++
class type (either copy- or direct-initialization).
Also, make sure that we create an elidable copy-construction when
performing copy initialization of a C++ class variable. Fixes PR5826.
llvm-svn: 91750
|