| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This is C++14 with conforming GNU extensions.
llvm-svn: 320250
|
|
|
|
|
|
|
|
|
| |
When an undeclared identifier in a context that requires a type is followed by
'<', only look for type templates when typo-correcting, tweak the diagnostic
text to say that a template name (not a type name) was undeclared, and parse
the template arguments when recovering from the error.
llvm-svn: 302732
|
|
|
|
|
|
| |
Previously Clang would simply ignore the 'template' keyword in this case.
llvm-svn: 294639
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider a template class with attributes on a method, and an explicit
specialization of that method:
template <int>
struct A {
void foo() final;
};
template <>
void A<0>::foo() {}
In this example, the attribute is `final`, but it might also be an
__attribute__((visibility("foo"))), noreturn, inline, etc. clang's current
behavior is to strip all attributes, which for some attributes is wrong
(the snippet above allows a subclass of A<0> to override the final method, for
example) and for others disagrees with gcc.
So stop dropping attributes. r95845 added this code without a test case, and
r176728 added the code for dropping attributes on parameters (with tests, but
they still pass).
As an additional wrinkle, do drop dllimport and dllexport, since that's how
these two attributes work. (This is covered by existing tests.)
Fixes PR21942.
The approach is by Richard Smith, initial analysis and typing was done by me.
With this, clang also matches GCC and EDG on all attributes Richard tested.
llvm-svn: 224651
|
|
|
|
|
|
|
| |
According to C++ standard if an exception-specification is specified in an explicit instantiation directive, it shall be compatible with the exception-specifications of other declarations of that function. This patch adds checks for this.
Differential Revision: http://reviews.llvm.org/D5822
llvm-svn: 221448
|
|
|
|
|
|
|
|
|
|
| |
This patch was submitted to the list for review and didn't receive a LGTM.
(In fact one explicit objection and one query were raised.)
This reverts commit r197295.
llvm-svn: 197299
|
|
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D2392
llvm-svn: 197295
|
|
|
|
|
|
|
|
|
|
|
| |
The tests were perhaps made too relaxed in r197164 when we switched to the new
MinGW ABI. This makes sure we check explicitly for an optional thiscall
attribute and nothing else.
We should still look into whether we should print these attributes at all in
these cases.
llvm-svn: 197252
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
appropriately, especially when they appear within class templates.
llvm-svn: 191548
|
|
|
|
| |
llvm-svn: 190531
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
diagnosis of bad template argument deductions."
This reverts commit a730f548325756d050d4caaa28fcbffdae8dfe95.
llvm-svn: 186729
|
|
|
|
|
|
| |
bad template argument deductions.
llvm-svn: 186727
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
good parser error recovery and for not crashing.
We still have a accepts-invalid-code bug.
llvm-svn: 147216
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
redeclaration provides an explicit instantiation or is invalid.
llvm-svn: 96097
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
as parts of overload sets. Also, refer to constructors as 'constructors'
rather than functions.
Adjust a lot of tests.
llvm-svn: 92832
|
|
|
|
|
|
| |
over to InitializationSequence. I could swear that this fixes a PR somewhere, but I couldn't figure out which one
llvm-svn: 91796
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
| |
focusing on the scope- and qualifier-related semantic requirements in
C++ [temp.explicit]p2.
llvm-svn: 84154
|
|
|
|
|
|
|
| |
explicit instantiation. Also, tighten up reference-count checking to
help catch these issues earlier. Fixes PR5069.
llvm-svn: 83225
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
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
|