Douglas Gregor [Fri, 4 Mar 2011 21:37:14 +0000 (21:37 +0000)]
Teach Sema::ActOnCXXNestedNameSpecifier and Sema::CheckTemplateIdType
to cope with non-type templates by providing appropriate
errors. Previously, we would either assert, crash, or silently build a
dependent type when we shouldn't. Fixes PR9226.
Douglas Gregor [Fri, 4 Mar 2011 20:42:52 +0000 (20:42 +0000)]
After an error of any kind has occurred, don't assert when attempting
to find the instantiated declaration within a template instantiation
fails to do so. It's likely that the original instantiation got
dropped due to instantiation failures, which doesn't actually break
the invariants of the AST. This eliminates a number of
crash-on-invalid failures, e.g., PR9300.
Devang Patel [Fri, 4 Mar 2011 18:54:42 +0000 (18:54 +0000)]
Emit a stop point before a call expression so that debugger has some chance of getting some footing when user wants to stop at 2nd bar() in following expression when all function calls are inlined.
= bar() + ... + bar() + ...
clang keeps track of column numbers, so we could put location entries for all subexpressions but that will significantly bloat debug info in general, but a location for call expression is helpful here.
Douglas Gregor [Fri, 4 Mar 2011 18:53:13 +0000 (18:53 +0000)]
When constructing source-location information for a
DependentTemplateSpecializationType during tree transformation, retain
the NestedNameSpecifierLoc as it was used to translate the template
name, rather than reconstructing it from the template name.
Douglas Gregor [Fri, 4 Mar 2011 17:52:15 +0000 (17:52 +0000)]
Make sure to put template parameters into their owning template's
DeclContext once we've created it. This mirrors what we do for
function parameters, where the parameters start out with
translation-unit context and then are adopted by the appropriate
DeclContext when it is created. Also give template parameters public
access and make sure that they don't show up for the purposes of name
lookup.
Fixes PR9400, a regression introduced by r126920, which implemented
substitution of default template arguments provided in template
template parameters (C++ core issue 150).
How on earth could the DeclContext of a template parameter affect the
handling of default template arguments?
I'm so glad you asked! The link is
Sema::getTemplateInstantiationArgs(), which determines the outer
template argument lists that correspond to a given declaration. When
we're instantiating a default template argument for a template
template parameter within the body of a template definition (not it's
instantiation, per core issue 150), we weren't getting any outer
template arguments because the context of the template template
parameter was the translation unit. Now that the context of the
template template parameter is its owning template, we get the
template arguments from the injected-class-name of the owning
template, so substitution works as it should.
If we look at the main location of the first explicit specialization (Spec 1) it can be seen that it points to the name of the *second* explicit specialization (Spec 2), which is a redeclaration of Spec1.
Hence, the source range obtained for Spec1 is not only inaccurate, but also invalid (the end location comes before the start location).
John McCall [Fri, 4 Mar 2011 10:39:25 +0000 (10:39 +0000)]
Don't consider visibility from template parameter lists if we're
computing for a nested decl with explicit visibility. This is all part
of the general philosophy of explicit visibility attributes, where
any information that was obviously available at the attribute site
should probably be ignored. Fixes PR9371.
John McCall [Fri, 4 Mar 2011 08:25:59 +0000 (08:25 +0000)]
Access ivars with inbounds GEPs, even in -fwrapv. It's unlikely that
this can have any optimization effect, given the opacity of objects pointers,
but you never know.
John McCall [Fri, 4 Mar 2011 04:00:19 +0000 (04:00 +0000)]
Make AttributedTypes for GC-qualified types and fix some miscellaneous
bugs with such types. Not sure this is quite how I want the desugaring
and a.k.a. logic to go, but it suffices.
Douglas Gregor [Thu, 3 Mar 2011 02:41:12 +0000 (02:41 +0000)]
When we use the default template arguments of a template template
parameter, save the instantiated default template arguments along with
the explicitly-specified template argument list. That way, we prefer
the default template template arguments corresponding to the template
template parameter rather than those of its template template argument.
This addresses the likely direction of C++ core issue 150, and fixes
PR9353/<rdar://problem/9069136>, bringing us closer to the behavior of
EDG and GCC.
Douglas Gregor [Wed, 2 Mar 2011 21:45:00 +0000 (21:45 +0000)]
Force CaseStmt to store its child statements in source-code order,
which is important for libclang's token-annotation and
where's-my-cursor functionality. Fixes <rdar://problem/9004439>.
Douglas Gregor [Wed, 2 Mar 2011 21:06:53 +0000 (21:06 +0000)]
Fix the source range for a member access expression that includes a
nested-name-specifier and improve the detection of implicit 'this'
bases. Fixes <rdar://problem/8750392>.
Ted Kremenek [Wed, 2 Mar 2011 20:32:29 +0000 (20:32 +0000)]
Introduce CFGImplicitDtor::isNoReturn() to query whether a destructor actually returns. Use this for -Wreturn-type to prune false positives reported in PR 6884.
Douglas Gregor [Wed, 2 Mar 2011 18:57:38 +0000 (18:57 +0000)]
Kill off the
TreeTransform::TransformDependentTemplateSpecializationType() with
poor source-location information handling. All of the
CXXScopeSpec::MakeTrivial() and
NestedNameSpecifierLocBuilder::MakeTrivial() callers actually make
sense now.
Douglas Gregor [Wed, 2 Mar 2011 18:52:42 +0000 (18:52 +0000)]
Eliminate an unnecessary use of CXXScopeSpec::MakeTrivial. We have proper nested-name-specifier source-location information in DependentTemplateSpecializationTypeLocs now
Douglas Gregor [Wed, 2 Mar 2011 18:50:38 +0000 (18:50 +0000)]
Kill off TreeTransform::TransformNestedNameSpecifier() in favor of the
source-location-preserving
TreeTransform::TranformNestedNameSpecifierLoc(). No functionality
change: the victim had no callers (that themselves had callers) anyway.
Douglas Gregor [Wed, 2 Mar 2011 18:07:45 +0000 (18:07 +0000)]
Start migrating TreeTransform's TransformTemplateName over to version
that preserve source-location information. This commit adds more
redundancy than it removes; WIP.
Douglas Gregor [Wed, 2 Mar 2011 17:09:35 +0000 (17:09 +0000)]
Push nested-name-specifier source location information into template
template arguments. I believe that this is the last place in the AST
where we were storing a source range for a nested-name-specifier
rather than a proper nested-name-specifier location structure. (Yay!)
There is still a lot of cleanup to do in the TreeTransform, which
doesn't take advantage of nested-name-specifiers with source-location
information everywhere it could.
John McCall [Wed, 2 Mar 2011 11:33:24 +0000 (11:33 +0000)]
Provide an attribute, objc_method_family, to allow the inferred family
of an Objective-C method to be overridden on a case-by-case basis. This
is a higher-level tool than ns_returns_retained &c.; it lets users specify
that not only does a method have different retain/release semantics, but
that it semantically acts differently than one might assume from its name.
This in turn is quite useful to static analysis.
John McCall [Wed, 2 Mar 2011 07:36:25 +0000 (07:36 +0000)]
Split out a subgroup of -Wconversion called -Wsign-conversion. Note that
unlike GCC, this is simply a subset of -Wconversion in all languages; it
is not disabled by defualt in C++.
John McCall [Wed, 2 Mar 2011 04:00:57 +0000 (04:00 +0000)]
Support a new InheritableAttr subclass, InheritableParamAttr, which is
used for attributes that are okay to inherit when written on a parameter.
Dependent on LLVM r126827.
Douglas Gregor [Wed, 2 Mar 2011 02:04:06 +0000 (02:04 +0000)]
When we're substituting into a parameter-type-list nested inside the pattern
of an expansion, and we have a paramameter that is not a parameter
pack, don't suppress substitution of parameter packs within this
context.
John McCall [Wed, 2 Mar 2011 01:50:55 +0000 (01:50 +0000)]
Move some of the logic about classifying Objective-C methods into
conventional categories into Basic and AST. Update the self-init checker
to use this logic; CFRefCountChecker is complicated enough that I didn't
want to touch it.
Douglas Gregor [Wed, 2 Mar 2011 00:47:37 +0000 (00:47 +0000)]
Push nested-name-specifier source-location information into dependent
template specialization types. This also required some parser tweaks,
since we were losing track of the nested-name-specifier's source
location information in several places in the parser. Other notable
changes this required:
- Sema::ActOnTagTemplateIdType now type-checks and forms the
appropriate type nodes (+ source-location information) for an
elaborated-type-specifier ending in a template-id. Previously, we
used a combination of ActOnTemplateIdType and
ActOnTagTemplateIdType that resulted in an ElaboratedType wrapped
around a DependentTemplateSpecializationType, which duplicated the
keyword ("class", "struct", etc.) and nested-name-specifier
storage.
- Sema::ActOnTemplateIdType now gets a nested-name-specifier, which
it places into the returned type-source location information.
- Sema::ActOnDependentTag now creates types with source-location
information.
Benjamin Kramer [Tue, 1 Mar 2011 22:50:47 +0000 (22:50 +0000)]
Since getDriver().getInstalledDir() returns a const char *, don't try to
compare it with getDriver().Dir.c_str(), since that is a pointer
comparison, not a "are these strings equal" comparison.
Instead, just compare with getDriver().Dir directly, so both sides will
get promoted to std::string, and the regular std::string comparison
operator applies.
Douglas Gregor [Tue, 1 Mar 2011 20:11:18 +0000 (20:11 +0000)]
Push nested-name-specifier source-location information into dependent
template specialization types. There are still a few rough edges to
clean up with some of the parser actions dropping
nested-name-specifiers too early.
Douglas Gregor [Tue, 1 Mar 2011 18:12:44 +0000 (18:12 +0000)]
Reinstate the introduction of source-location information for
nested-name-speciciers within elaborated type names, e.g.,
enum clang::NestedNameSpecifier::SpecifierKind
Fixes in this iteration include:
(1) Compute the type-source range properly for a dependent template
specialization type that starts with "template template-id ::", as
in a member access expression
dep->template f<T>::f()
This is a latent bug I triggered with this change (because now we're
checking the computed source ranges for dependent template
specialization types). But the real problem was...
(2) Make sure to set the qualifier range on a dependent template
specialization type appropriately. This will go away once we push
nested-name-specifier locations into dependent template
specialization types, but it was the source of the
valgrind errors on the buildbots.
Roman Divacky [Tue, 1 Mar 2011 18:03:28 +0000 (18:03 +0000)]
On FreeBSD, we don't want 'getDriver().Dir + "/../lib"' added to the
ToolChain's FilePaths. If clang is installed as a port in /usr/local,
it is *not* supposed to use /usr/local/lib by default, for example.
Additionally, there are no clang-related executables in either
/usr/libexec, or getDriver().Dir + "/../libexec", anymore, so remove
that from the ToolChain's ProgramPaths.
objc IRGen for Next runtime message API.
The prototype for objc_msgSend() is technically variadic -
`id objc_msgSend(id, SEL, ...)`.
But all method calls should use a prototype that matches the method,
not the prototype for objc_msgSend itself().
// rdar://9048030
Douglas Gregor [Tue, 1 Mar 2011 17:04:42 +0000 (17:04 +0000)]
When digging into a cv-qualified return type that is a pointer type to
diagnose ignored qualifiers on return types, only assume that there is
a pointer chunk if the type is *structurally* a pointer type, not if
it's a typedef of a pointer type. Fixes PR9328/<rdar://problem/9055428>.
Douglas Gregor [Tue, 1 Mar 2011 16:44:30 +0000 (16:44 +0000)]
When building a type for a typename specifier, check specifically for
a dependent template name rather than (indirectly and incorrectly)
trying to determine whether we can compute a context for the
nested-name-specifier. Fixes a GCC testsuite regression,
<rdar://problem/9068589>.
projects / clang / log