- 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
that protected members be used on objects of types which derive from the
naming class of the lookup. My first N attempts at this were poorly-founded,
largely because the standard is very badly worded here.
llvm-svn: 100562
an object or function. Our previous checking was too lax, and ended up
allowing missing or extraneous address-of operators, among other
evils. The new checking provides better diagnostics and adheres more
closely to the standard.
Fixes PR6563 and PR6749.
llvm-svn: 100125
nested-name-specifier (e.g., "class T::foo") fails to find a tag
member in the scope nominated by the
nested-name-specifier. Previously, we gave a bland
error: 'Nested' does not name a tag member in the specified scope
which didn't actually say where we were looking, which was rather
horrible when the nested-name-specifier was instantiated. Now, we give
something a bit better:
error: no class named 'Nested' in 'NoDepBase<T>'
llvm-svn: 100060
(such as "class T::foo") from an ElaboratedType of a TypenameType to a
DependentNameType, which more accurately models the underlying
concept.
Improve template instantiation for DependentNameType nodes that
represent nested-name-specifiers, by performing tag name lookup and
checking the resulting tag appropriately. Fixes PR5681.
There is still much testing and cleanup to do in this area.
llvm-svn: 100054
name in the outermost block of a if/else that declares the same name
is ill-formed. Turns out that Clang and MSVC were right about PR6739;
GCC is too lax.
llvm-svn: 99937
the underlying/instantiated decl) through a lot of API, including "intermediate"
MemberExprs required for (e.g.) template instantiation. This is necessary
because of the access semantics of member accesses to using declarations:
only the base class *containing the using decl* need be accessible from the
naming class.
This allows us to complete an access-controlled selfhost, if there are no
recent regressions.
llvm-svn: 99936
check deduced non-type template arguments and template template
arguments against the template parameters for which they were deduced,
performing conversions as appropriate so that deduced template
arguments get the same treatment as explicitly-specified template
arguments. This is the bulk of PR6723.
Also keep track of whether deduction of a non-type template argument
came from an array bound (vs. anywhere else). With this information,
we enforce C++ [temp.deduct.type]p17, which requires exact type
matches when deduction deduces a non-type template argument from
something that is not an array bound.
Finally, when in a SFINAE context, translate the "zero sized
arrays are an extension" extension diagnostic into a hard error (for
better standard conformance), which was a minor part of PR6723.
llvm-svn: 99734
nested within, and suddenly local classes start working. Wouldn't be
necessary if I hadn't used local classes in Clang in the first place.
Or, well, wouldn't be necessary yet. :)
llvm-svn: 99709
that we extend/truncate then correct the sign to convert the non-type
template argument to the template parameter's type. Previously, we
reported an error when the non-type template argument was out of
range; now we just warn.
llvm-svn: 99600
the type of its corresponding non-type template parameter changes the
value. Previously, we were diagnosing this as an error, which was
wrong. We give reasonably nice warnings like:
test/SemaTemplate/temp_arg_nontype.cpp💯10: warning: non-type template
argument value '256' truncated to '0' for template parameter of type
'unsigned char'
Overflow<256> *overflow3; // expected-warning{{non-type template ...
^~~
test/SemaTemplate/temp_arg_nontype.cpp:96:24: note: template parameter is
declared here
template<unsigned char C> struct Overflow;
^
llvm-svn: 99561
friendship for a derived class if the base class specifier was non-public,
and thus not considering friendship for non-public members of public bases.
llvm-svn: 99554
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
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
that was present in a prior declaration, emit a warning rather than a
hard error (which we did before, and still do with mismatched
exception specifications). Moreover, provide a fix-it hint with the
throw() clause that should be added, e.g.,
t.C:10:7: warning: 'operator new' is missing exception specification
'throw(std::bad_alloc)'
void *operator new(unsigned long sz)
^
throw(std::bad_alloc)
As part of this, disable the warning when we're missing an exception
specification on operator new, operator new[], operator delete, or
operator delete[] when exceptions are turned off (-fno-exceptions).
Fixes PR5957.
llvm-svn: 99388
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
function within a class hierarchy (C++ [class.virtual]p2).
We use the final-overrider computation to determine when a particular
class is ill-formed because it has multiple final overriders for a
given virtual function (e.g., because two virtual functions override
the same virtual function in the same virtual base class). Fixes
PR5973.
We also use the final-overrider computation to determine which virtual
member functions are pure when determining whether a class is
abstract or diagnosing the improper use of an abstract class. The
prior approach to determining whether there were any pure virtual
functions in a class didn't cope with virtual base class subobjects
properly, and could not easily be fixed to deal with the oddities of
subobject hiding. Fixes PR6631.
llvm-svn: 99351
access to the (elevated) access of the accessed declaration, if applicable,
rather than plunking that access onto the end after we've calculated the
inheritance access.
Also, being a friend of a derived class gives you public access to its
members (subject to later modification by further inheritance); it does
not simply ignore a single location of restricted inheritance.
Also, when computing the best unprivileged path to a subobject, preserve
the information that the worst path might be AS_none (forbidden) rather
than a minimum of AS_private.
llvm-svn: 98899
non-placement news when selecting the corresponding operator delete; this is
fixed.
Access and ambiguity control for calls to operator new and delete. Also AFAICT
llvm-svn: 98818
parameter hides a namespace-scope declararion with the same name in an
out-of-line definition of a template. The lookup requires a strange
interleaving of lexical and semantic scopes (go C++), which I have not
yet handled in the typo correction/code completion path.
Fixes PR6594.
llvm-svn: 98544
iterations of this patch gave explicit template instantiation
link-once ODR linkage, which permitted the back end to eliminate
unused symbols. Weak ODR linkage still requires the symbols to be
generated.
llvm-svn: 98441
Douglas Gregor