The exception object should be unqualified. Using a qualified exception
object results in the wrong copy constructor getting called when the
catch handler executes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231054 91177308-0d34-0410-b5e6-96231b3b80d8
We would create the exception object with the wrong qualifiers, ensuring
that the wrong copy constructor would get called.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231049 91177308-0d34-0410-b5e6-96231b3b80d8
"protected scope" is very unhelpful here and actively confuses users. Instead,
simply state the nature of the problem in the diagnostic: we cannot jump from
here to there. The notes explain nicely why not.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217293 91177308-0d34-0410-b5e6-96231b3b80d8
decayed to a pointer type. Patch by WenHan Gu, with a little tweaking and
additional testcases by me.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168822 91177308-0d34-0410-b5e6-96231b3b80d8
pointer to incomplete type from an ExtWarn to an error. We put the
ExtWarn in place as part of a workaround for Boost (PR6527), but it
(1) doesn't actually match a GCC extension and (2) has been fixed for
two years in Boost, and (3) causes us to emit code that fails badly at
run time, so it's a bad idea to keep it. Fixes PR11803.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148838 91177308-0d34-0410-b5e6-96231b3b80d8
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)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146619 91177308-0d34-0410-b5e6-96231b3b80d8
intended for redeclarations, fixing those that need it. Fixes PR6831.
This uncovered an issue where the C++ type-specifier-seq parsing logic
would try to perform name lookup on an identifier after it already had
a type-specifier, which could also lead to spurious ambiguity errors
(as in PR6831, but with a different test case).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101419 91177308-0d34-0410-b5e6-96231b3b80d8
therefore not creating ElaboratedTypes, which are still pretty-printed
with the written tag).
Most of these testcase changes were done by script, so don't feel too
sorry for my fingers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@98149 91177308-0d34-0410-b5e6-96231b3b80d8
incomplete type to warnings; GCC (and EDG in GCC compatibility mode)
permit such handles. Fixes PR6527.
(For real this time)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97927 91177308-0d34-0410-b5e6-96231b3b80d8
incomplete type to warnings; GCC (and EDG in GCC compatibility mode)
permit such handles. Fixes PR6527.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97925 91177308-0d34-0410-b5e6-96231b3b80d8
- 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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91446 91177308-0d34-0410-b5e6-96231b3b80d8