Commit Graph

21 Commits

Author SHA1 Message Date
Rafael Espindola 3497069784 Switch to the new MingW ABI.
GCC 4.7 changed the MingW ABI. On the clang side this means that methods now
have the thiscall calling convention by default.

llvm-svn: 197164
2013-12-12 16:07:11 +00:00
Richard Smith 8809a0c95e Variable templates: handle instantiation of static data member templates
appropriately, especially when they appear within class templates.

llvm-svn: 191548
2013-09-27 20:14:12 +00:00
Serge Pavlov 60ac1269c6 Added regression tests.
llvm-svn: 190531
2013-09-11 17:04:24 +00:00
Larisse Voufo 98b20f1278 FIXME fix: improving diagnostics for template arguments deduction of class templates and explicit specializations
This patch essentially removes all the FIXMEs following calls to DeduceTemplateArguments() that want to keep track of deduction failure info.

llvm-svn: 186730
2013-07-19 23:00:19 +00:00
Larisse Voufo 47c0845e0b Revert "Use function overloading instead of template specialization for diagnosis of bad template argument deductions."
This reverts commit a730f548325756d050d4caaa28fcbffdae8dfe95.

llvm-svn: 186729
2013-07-19 22:53:23 +00:00
Larisse Voufo 8d33da6d58 Use function overloading instead of template specialization for diagnosis of bad template argument deductions.
llvm-svn: 186727
2013-07-19 22:34:32 +00:00
David Blaikie 1c7c8f7637 Implement warning for integral null pointer constants other than the literal 0.
This is effectively a warning for code that violates core issue 903 & thus will
become standard error in the future, hopefully. It catches strange null
pointers such as: '\0', 1 - 1, const int null = 0; etc...

There's currently a flaw in this warning (& the warning for 'false' as a null
pointer literal as well) where it doesn't trigger on comparisons (ptr == '\0'
for example). Fix to come in a future patch.

Also, due to this only being a warning, not an error, it triggers quite
frequently on gtest code which tests expressions for null-pointer-ness in a
SFINAE context (so it wouldn't be a problem if this was an error as in an
actual implementation of core issue 903). To workaround this for now, the
diagnostic does not fire in unevaluated contexts.

Review by Sean Silva and Richard Smith.

llvm-svn: 161501
2012-08-08 17:33:31 +00:00
Argyrios Kyrtzidis 2644063ec9 Pass context and access to Parser::ParseExplicitInstantiation() for
good parser error recovery and for not crashing.

We still have a accepts-invalid-code bug.

llvm-svn: 147216
2011-12-23 02:16:45 +00:00
Richard Trieu 553b2b2e5d Modify how the -verify flag works. Currently, the verification string and
diagnostic message are compared.  If either is a substring of the other, then
no error is given.  This gives rise to an unexpected case:

  // expect-error{{candidate function has different number of parameters}}

will match the following error messages from Clang:

  candidate function has different number of parameters (expected 1 but has 2)
  candidate function has different number of parameters

It will also match these other error messages:

  candidate function
  function has different number of parameters
  number of parameters

This patch will change so that the verification string must be a substring of
the diagnostic message before accepting.  Also, all the failing tests from this
change have been corrected.  Some stats from this cleanup:

87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)

llvm-svn: 146619
2011-12-15 00:38:15 +00:00
Sebastian Redl 83f3b859ab Make the invalid declarator recovery when parsing members work the same as when parsing global decls. It's still rather broken (skipping much too far when the declarator belongs to a function definition), but at least not so broken as to mismatch braces. Tested by the removal of the fixme in the template test case.
llvm-svn: 130101
2011-04-24 16:27:48 +00:00
Douglas Gregor aa49ecc458 Not content to implement just "extern" explicit template
instantiations, GCC also supports "inline" and "static" explicit
template instantiations. Parse and warn about such constructs, but
don't implement the semantics of either "inline" or "static". They
don't seem to be widely used.

llvm-svn: 120599
2010-12-01 20:32:20 +00:00
Douglas Gregor 6cc1df5d3d Provide a special diagnostic for attempts to explicitly specialize
class templates within class scope (which is ill-formed), and recover
by dropping the explicit specialization entirely. Fixes the infinite
loop in PR7622.

llvm-svn: 108217
2010-07-13 00:10:04 +00:00
Chandler Carruth 6b4756a224 Skip implicit instantiation of templated variables where a more recent
redeclaration provides an explicit instantiation or is invalid.

llvm-svn: 96097
2010-02-13 10:17:50 +00:00
John McCall e1ac8d1742 Improve the reporting of non-viable overload candidates by noting the reason
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
2010-01-13 00:25:19 +00:00
John McCall fd0b2f8fe4 Improve the diagnostics used to report implicitly-generated class members
as parts of overload sets.  Also, refer to constructors as 'constructors'
rather than functions.

Adjust a lot of tests.

llvm-svn: 92832
2010-01-06 09:43:14 +00:00
Douglas Gregor 39c778b443 Switch default-initialization of variables of class type (or array thereof) over to InitializationSequence. I could swear that this fixes a PR somewhere, but I couldn't figure out which one
llvm-svn: 91796
2009-12-20 22:01:25 +00:00
Daniel Dunbar 8fbe78f6fc Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- This is designed to make it obvious that %clang_cc1 is a "test variable"
   which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
   can be useful to redefine what gets run as 'clang -cc1' (for example, to set
   a default target).

llvm-svn: 91446
2009-12-15 20:14:24 +00:00
Douglas Gregor e47f5a76cc Additional semantic checking for explicit template instantiations,
focusing on the scope- and qualifier-related semantic requirements in
C++ [temp.explicit]p2.

llvm-svn: 84154
2009-10-14 23:41:34 +00:00
Douglas Gregor f343fd8929 Make sure to free the explicit template arguments provided for an
explicit instantiation. Also, tighten up reference-count checking to
help catch these issues earlier. Fixes PR5069.

llvm-svn: 83225
2009-10-01 23:51:25 +00:00
Douglas Gregor d90fd526d3 Declarators can now properly represent template-ids, e.g., for
template void f<int>(int);
                ~~~~~~
Previously, we silently dropped the template arguments. With this
change, we now use the template arguments (when available) as the
explicitly-specified template arguments used to aid template argument
deduction for explicit template instantiations.

llvm-svn: 82806
2009-09-25 21:45:23 +00:00
Douglas Gregor 450f0084a2 WIP implementation of explicit instantiation of function templates,
member functions of class template specializations, and static data
members. The mechanics are (mostly) present, but the semantic analysis
is very weak.

llvm-svn: 82789
2009-09-25 18:43:00 +00:00