| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Apparently I forgot to do an open brace in a namespace, so we get an
error about an extra closing brace.
llvm-svn: 362443
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
In any situation where the Exception Spec isn't clear, suppress the
warning to avoid false positives.
llvm-svn: 362243
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
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
|
