Commit Graph

2774 Commits

Author SHA1 Message Date
Anders Carlsson 3d5829cd4f More return type checking.
llvm-svn: 84034
2009-10-13 21:49:31 +00:00
Anders Carlsson f64a3dae04 Diagnose invalid return types for unary operators.
llvm-svn: 84030
2009-10-13 21:19:37 +00:00
Douglas Gregor e40876a50c Unify our diagnostic printing for errors of the form, "we didn't like
what we found when we looked into <blah>", where <blah> is a
DeclContext*. We can now format DeclContext*'s in nice ways, e.g.,
"namespace N", "the global namespace", "'class Foo'".

This is part of PR3990, but we're not quite there yet.

llvm-svn: 84028
2009-10-13 21:16:44 +00:00
Douglas Gregor 62e10f0bdc Diagnose attempts to add default function arguments to a
specialization. This completes C++ [temp.expl.spec]!

llvm-svn: 83980
2009-10-13 17:02:54 +00:00
Douglas Gregor cf91555cb8 When explicitly specializing a member that is a template, mark the
template as a specialization. For example, this occurs with:

  template<typename T>
  struct X {
    template<typename U> struct Inner { /* ... */ };
  };

  template<> template<typename T>
  struct X<int>::Inner {
    T member;
  };

We need to treat templates that are member specializations as special
in two contexts:

  - When looking for a definition of a member template, we look
    through the instantiation chain until we hit the primary template
    *or a member specialization*. This allows us to distinguish
    between the primary "Inner" definition and the X<int>::Inner
    definition, above.
  - When computing all of the levels of template arguments needed to
    instantiate a member template, don't add template arguments
    from contexts outside of the instantiation of a member
    specialization, since the user has already manually substituted
    those arguments.

Fix up the existing test for p18, which was actually wrong (but we
didn't diagnose it because of our poor handling of member
specializations of templates), and add a new test for member
specializations of templates.

llvm-svn: 83974
2009-10-13 16:30:37 +00:00
Douglas Gregor 3a88c1d784 Improve the internal representation and semantic analysis of friend
function templates.

This commit ensures that friend function templates are constructed as
FunctionTemplateDecls rather than partial FunctionDecls (as they
previously were). It then implements template instantiation for friend
function templates, injecting the friend function template only when
no previous declaration exists at the time of instantiation. 

Oh, and make sure that explicit specialization declarations are not
friends.

llvm-svn: 83970
2009-10-13 14:39:41 +00:00
Chris Lattner 1a6babf1f4 make the diagnostic in the 'unused result' warning more precise
about the reason, rdar://7186119.

llvm-svn: 83940
2009-10-13 04:53:48 +00:00
Douglas Gregor ef06ccf8d0 When declaring a class template whose name is qualified, make sure
that the scope in which it is being declared is complete. Also, when
instantiating a member class template's ClassTemplateDecl, be sure to
delay type creation so that the resulting type is dependent. Ick.

llvm-svn: 83923
2009-10-12 23:11:44 +00:00
Douglas Gregor ca027af608 Permit explicit specialization of member functions of class templates
that are declarations (rather than definitions). Also, be sure to set
the access specifiers properly when instantiating the declarations of
member function templates.

llvm-svn: 83911
2009-10-12 22:27:17 +00:00
John McCall e724ae92a8 More appropriate API usage.
llvm-svn: 83910
2009-10-12 22:25:59 +00:00
John McCall d5707abdfd Implement -Wparentheses: warn about using assignments in contexts that require
conditions.  Add a fixit to insert the parentheses.  Also fix a very minor
possible memory leak in 'for' conditions.

Fixes PR 4876 and rdar://problem/7289172

llvm-svn: 83907
2009-10-12 21:59:07 +00:00
Douglas Gregor 06db9f50a2 Diagnose the declaration of explicit specializations after an implicit
instantiation has already been required. To do so, keep track of the
point of instantiation for anything that can be instantiated.

llvm-svn: 83890
2009-10-12 20:18:28 +00:00
Fariborz Jahanian e7196431c1 Handle built-in unary operators when reporting ambiguities.
wip - To prune excessive reporting.

llvm-svn: 83889
2009-10-12 20:11:40 +00:00
Fariborz Jahanian 574de2c5a4 If built-in operators could not be selected because of ambiguity in
user-defined type conversions, issue list of ambiguites in addition 
to the diagnostic. So, clang now issues the following:

b.cpp:19:19: error: left hand operand to ->* must be a pointer to class compatible with the right hand operand, but is 'struct C1'
        int i = c1->*pmf;
                ~~^
b.cpp:19:19: note: because of ambiguity in conversion of 'struct C1' to 'struct E *'
b.cpp:5:5: note: candidate function
    operator E*();
    ^
b.cpp:11:5: note: candidate function
    operator E*();
    ^

llvm-svn: 83862
2009-10-12 17:51:19 +00:00
Sebastian Redl 6e4c871855 Types appearing more than once in a spec shouldn't matter.
llvm-svn: 83766
2009-10-11 09:11:23 +00:00
Sebastian Redl 4915e63d3b Test exception spec compatibility on return type and parameters.
Along the way, use RequireCompleteType when testing exception spec types.
Separate all the ugly spec stuff into its own file.

llvm-svn: 83764
2009-10-11 09:03:14 +00:00
Sebastian Redl 5d43164bc2 Implement the core checking for compatible exception specifications in assignment and initialization.
The exception specification of the assignee must be the same or a subset of the target. In addition, exception specifications on arguments and return types must be equivalent, but this is not implemented yet.
This currently produces two diagnostics for every invalid assignment/initialization, due to the diagnostic produced outside PerformImplicitConversion, e.g. in CheckSingleInitializer. I don't know how to suppress this; in any case I think it is the wrong place for a diagnostic, since there are other diagnostics produced inside the function. So I'm leaving it as it is for the moment.

llvm-svn: 83710
2009-10-10 12:04:10 +00:00
John McCall 6538c93050 Qualified lookup through using declarations. Diagnose a new type of ambiguity.
Split the various ambiguous result enumerators into their own enum.  Tests
for most of C++ [namespace.qual].

llvm-svn: 83700
2009-10-10 05:48:19 +00:00
Anders Carlsson c4859baea4 Check that the return type is complete when calling a member function.
llvm-svn: 83694
2009-10-10 00:06:20 +00:00
Anders Carlsson 7f84ed9287 Add CheckCallReturnType and start using it for regular call expressions. This will improve error messages. For
struct B;

B f();

void g() {
f();
}

We now get

t.cpp:6:3: error: calling 'f' with incomplete return type 'struct B'
  f();
  ^~~
t.cpp:3:3: note: 'f' declared here
B f();
  ^
t.cpp:1:8: note: forward declaration of 'struct B'
struct B;
       ^

llvm-svn: 83692
2009-10-09 23:51:55 +00:00
Douglas Gregor b385b7c62e Dead Code Elimination
llvm-svn: 83686
2009-10-09 22:56:12 +00:00
Douglas Gregor 7d195b93d8 Add some FIXMEs
llvm-svn: 83685
2009-10-09 22:54:25 +00:00
Douglas Gregor 58acf32af2 Minor tweaks for code-completion:
- Filter out unnamed declarations
  - Filter out declarations whose names are reserved for the
  implementation (e.g., __bar, _Foo) 
  - Place OVERLOAD: or COMPLETION: at the beginning of each
  code-completion result, so we can easily separate them from other
  compilation results.

llvm-svn: 83680
2009-10-09 22:16:47 +00:00
John McCall 9f3059a192 Refactor the LookupResult API to simplify most common operations. Require users to
pass a LookupResult reference to lookup routines.  Call out uses which assume a single
result.

llvm-svn: 83674
2009-10-09 21:13:30 +00:00
Douglas Gregor 7f34baeb4b When declaring a friend class template, we may end up finding an
injected-class-name (e.g., when we're referring to other
specializations of the current class template). Make sure that we see
the template rather than the injected-class-name. Fixes PR4768.

llvm-svn: 83672
2009-10-09 21:11:42 +00:00
Fariborz Jahanian 0fe5e0308e Produce good looking diagnostics on ambiguous built-in operators.
Now we produce things like:
bug1.cpp:21:11: error: use of overloaded operator '->*' is ambiguous
        int i = c->*pmf;        // expected-error {{use of overloaded operator '->*' is ambiguous}} \
                ~^  ~~~
bug1.cpp:21:11: note: built-in candidate operator ->* ('struct A volatile *', 'int const struct A::*')
bug1.cpp:21:11: note: built-in candidate operator ->* ('struct A volatile *', 'int restrict struct A::*')
...

Still need to look at an issue (indicated as FIXME in the test case).

llvm-svn: 83650
2009-10-09 17:09:58 +00:00
Fariborz Jahanian 4dc1246d87 Use the new API for applying the qualifiers on built-in '->*'
operator's types.

llvm-svn: 83648
2009-10-09 16:34:40 +00:00
Fariborz Jahanian 29f9d39568 Improve on reporting ambiguity involving built-in candidates.
I still don't like it but it is improvement over what we had.

llvm-svn: 83603
2009-10-09 00:13:15 +00:00
Steve Naroff 3b08630b06 - Fixup SortCodeCompleteResult() to properly sort keywords on Mac OS (compare was system dependent). Worked on Linux, failed on Mac OS (which caused the recently added testcase to fail on Linux).
- Sort results in testcase.

llvm-svn: 83597
2009-10-08 23:45:10 +00:00
Fariborz Jahanian 8ae5b0a18b Fix up error reporting when object cannot be constructed
because of missing default constructor of a member.
Fixes pr5154.

llvm-svn: 83583
2009-10-08 22:15:49 +00:00
Douglas Gregor 01249503fe Installation of Clang libraries and headers, from Axel Naumann!
llvm-svn: 83582
2009-10-08 22:15:31 +00:00
Steve Naroff 936354c62a Add code completion support for ObjC property declarations/attributes.
llvm-svn: 83579
2009-10-08 21:55:05 +00:00
Douglas Gregor 3beaf9bbcd Implement support for -Wunused-variable, from Oscar Bonilla!
llvm-svn: 83577
2009-10-08 21:35:42 +00:00
Douglas Gregor eeffde3a1d Add more testing for the properties of explicit specialization.
Also, eliminate a redundant diagnostic by marking a variable declared
with incomplete type as an invalid declaration.

llvm-svn: 83553
2009-10-08 16:41:22 +00:00
Douglas Gregor 19c52729ed Don't complain about out-of-line explicit specializations of member
function and member function templates that are not definitions. Add
more tests to ensure that explicit specializations of member function
templates prevent instantiation.

llvm-svn: 83550
2009-10-08 15:54:21 +00:00
Douglas Gregor bbe8f46621 Improve checking for specializations of member classes of class
templates, and keep track of how those member classes were
instantiated or specialized. 

Make sure that we don't try to instantiate an explicitly-specialized
member class of a class template, when that explicit specialization
was a declaration rather than a definition.

llvm-svn: 83547
2009-10-08 15:14:33 +00:00
Douglas Gregor 86d142a801 For instantiations of static data members of class templates, keep
track of the kind of specialization or instantiation. Also, check the
scope of the specialization and ensure that a specialization
declaration without an initializer is not a definition.

llvm-svn: 83533
2009-10-08 07:24:58 +00:00
Douglas Gregor c093c1de2b Make sure to set the template specialization kind of an explicit
template instantiation of a member function of a class template.
FIXME -= 2;

llvm-svn: 83520
2009-10-08 01:19:17 +00:00
Douglas Gregor e3dfd4826b Only perform an implicit instantiation of a function if its template
specialization kind is TSK_ImplicitInstantiation. Previously, we would
end up implicitly instantiating functions that had explicit
specialization declarations or explicit instantiation declarations
(with no corresponding definitions).

llvm-svn: 83511
2009-10-08 00:14:38 +00:00
Douglas Gregor d801b06232 Keep track of whether a member function instantiated from a member
function of a class template was implicitly instantiated, explicitly
instantiated (declaration or definition), or explicitly
specialized. The same MemberSpecializationInfo structure will be used
for static data members and member classes as well.

llvm-svn: 83509
2009-10-07 23:56:10 +00:00
John McCall c3987485f2 Refactoring around friend class templates. Better error message for friend enums.
Don't create a new declaration for friend classes if a declaration already exists.

llvm-svn: 83505
2009-10-07 23:34:25 +00:00
Douglas Gregor 5c0405d484 Type checking for specializations of member functions of class
templates. Previously, these weren't handled as specializations at
all. The AST for representing these as specializations is still a work
in progress.

llvm-svn: 83498
2009-10-07 22:35:40 +00:00
Anders Carlsson 6c966c458a Handle MemberExprs in ResolveAddressOfOverloadedFunction.
llvm-svn: 83495
2009-10-07 22:26:29 +00:00
John McCall fe8dc76f80 Dead code elimination.
llvm-svn: 83492
2009-10-07 22:04:40 +00:00
Douglas Gregor 40fb74484e Diagnose explicit instantiations and specializations that occur in class scope
llvm-svn: 83473
2009-10-07 17:30:37 +00:00
Fariborz Jahanian ae01f78a31 When building candidate set for built-ins; when looking for
convesion functions, look in base classes to.
(Removes a FIXME).

llvm-svn: 83472
2009-10-07 17:26:09 +00:00
Douglas Gregor e4b05168f6 Class template partial specializations can be declared anywhere that
its definition may be defined, including in a class.

Also, put in an assertion when trying to instantiate a class template
partial specialization of a member template, which is not yet
implemented.

llvm-svn: 83469
2009-10-07 17:21:34 +00:00
Fariborz Jahanian 12df37c5d7 Removed couple of unnecessary canonicalization
per Doug's obsevation.

llvm-svn: 83464
2009-10-07 16:56:50 +00:00
Douglas Gregor 548886518d Refactor checking of the scope of explicit template specialization
declarations and explicit template instantiations, improving
diagnostics and making the code usable for function template
specializations (as well as class template specializations and partial
specializations). 

llvm-svn: 83436
2009-10-07 00:13:32 +00:00
Fariborz Jahanian 34d93dcddd Patch to implement C++ [over.built]p11 of overload resolution.
Doug, please review. There is a FIXME in the test case with a question
which is unrelated to this patch (that is, error is issued
before set of builtins are added to the candidate list).

llvm-svn: 83429
2009-10-06 23:08:05 +00:00