Commit Graph

6 Commits

Author SHA1 Message Date
Erich Keane dd0adae65a Fix test failure from r362435
Apparently I forgot to do an open brace in a namespace, so we get an
error about an extra closing brace.

llvm-svn: 362443
2019-06-03 19:57:52 +00:00
Erich Keane bf37536a35 Make NoThrow FunctionLike, make FunctionLike include references, fix
prettyprint

__declspec(nothrow) should work on function pointers as well as function
references, so this changes it to FunctionLike.  Additionally,
FunctionLike needed to be modified to permit function references.

Finally, the TypePrinter didn't properly print the NoThrow exception
specifier, so make sure we get that right as well.

llvm-svn: 362435
2019-06-03 18:36:33 +00:00
Erich Keane 81ef625080 Permit Exception Spec mismatch with NoThrow on inherited Virtual
As reported here: https://bugs.llvm.org/show_bug.cgi?id=42100

This fairly common pattern ends up being an error in MinGW, so relax it
in all cases to a warning.

llvm-svn: 362434
2019-06-03 18:36:26 +00:00
Erich Keane c61762797e Suppress nothrow/Exception spec conflict warning when we dont know the ES.
In any situation where the Exception Spec isn't clear, suppress the
warning to avoid false positives.

llvm-svn: 362243
2019-05-31 16:46:38 +00:00
Erich Keane 24016eb374 Suppress nothrow/exception spec conflict warning when ES is parsed.
The previously added warning ended up causing false positives when
nothrow was used on member functions, where the exception specification
wasn't yet parsed.  So, throw() and noexcept(true) both were incorrectly
warning.  There doesn't seem to be a good way to force these to be parsed
to identify which they are (and likely should not be), so suppress the warning.

For now, unevaluated/uninstantiated are left as warnings as I am not
creative enough to find a reproducer that causes a false positive for
either.

llvm-svn: 362236
2019-05-31 15:56:27 +00:00
Erich Keane d02f4a1043 Add Attribute NoThrow as an Exception Specifier Type
In response to https://bugs.llvm.org/show_bug.cgi?id=33235, it became
clear that the current mechanism of hacking through checks for the
exception specification of a function gets confused really quickly when
there are alternate exception specifiers.

This patch introcues EST_NoThrow, which is the equivilent of
EST_noexcept when caused by EST_noThrow. The existing implementation is
left in place to cover functions with no FunctionProtoType.

Differential Revision: https://reviews.llvm.org/D62435

llvm-svn: 362119
2019-05-30 17:31:54 +00:00