This permits to add a space after closing parenthesis of a C-style cast.
Defaults to false to preserve old behavior.
Fixes llvm.org/PR19982.
Before:
(int)i;
After:
(int) i;
Patch by Marek Kurdej.
llvm-svn: 217022
Scoped lockable objects (mutex guards) are implemented as if it is a
lock itself that is acquired upon construction and unlocked upon
destruction. As it if course needs to be used to actually lock down
something else (a mutex), it keeps track of this knowledge through its
underlying mutex field in its FactEntry.
The problem with this approach is that this only allows us to lock down
a single mutex, so extend the code to use a vector of underlying
mutexes. This, however, makes the code a bit more complex than
necessary, so subclass FactEntry into LockableFactEntry and
ScopedLockableFactEntry and move all the logic that differs between
regular locks and scoped lockables into member functions.
llvm-svn: 217016
determining whether a declaration is out of line, instead of assuming
that the semantic and lexical DeclContext will be the same declaration
whenever they're the same entity.
This fixes behavior of declarations within merged classes and enums.
llvm-svn: 217008
On operating systems like the BSDs, it is typically the case that
/usr/bin/python does not exist. We should therefore use /usr/bin/env
instead. This is also done in various other scripts in tools/.
llvm-svn: 216945
With targeting i686-win32,
error: 'error' diagnostics seen but not expected:
File clang/test/CXX/drs/dr5xx.cpp Line 521: implicit instantiation of undefined template 'dr547::X<void () __attribute__((thiscall)) const>'
File clang/test/CXX/drs/dr5xx.cpp Line 518: implicit instantiation of undefined template 'dr547::X<void () __attribute__((thiscall)) const>'
File clang/test/CXX/drs/dr5xx.cpp Line 518: implicit instantiation of undefined template 'dr547::X<void () __attribute__((thiscall)) const>'
error: 'note' diagnostics seen but not expected:
File clang/test/CXX/drs/dr5xx.cpp Line 516: template is declared here
File clang/test/CXX/drs/dr5xx.cpp Line 521: in instantiation of function template specialization 'dr547::f<void () __attribute__((thiscall)) const, dr547::S>' requested here
File clang/test/CXX/drs/dr5xx.cpp Line 516: template is declared here
File clang/test/CXX/drs/dr5xx.cpp Line 516: template is declared here
7 errors generated.
llvm-svn: 216841
A couple of these arguments were passed by void* as a rather extreme
example of pimpling. Adjusting this to a more classic form of the idiom
(involving forward declarations) makes this more legible and allows
explicit passing of ownership via std::unique_ptr.
llvm-svn: 216785
This avoids encoding information about the function prototype into the
thunk at the cost of some function prototype bitcast gymnastics.
Fixes PR20653.
llvm-svn: 216782
in the super class, do not issue the warning about property
in current class's protocol will not be auto synthesized.
// rdar://18179833
llvm-svn: 216769
People have been incorrectly using "-analyzer-disable-checker" to
silence analyzer warnings on a file, when analyzing a project. Add
the "-analyzer-disable-all-checks" option, which would allow the
suppression and suggest it as part of the error message for
"-analyzer-disable-checker". The idea here is to compose this with
"--analyze" so that users can selectively opt out specific files from
static analysis.
llvm-svn: 216763
I suspect llvm::ilist should take elements by unique_ptr, since it does
take ownership of the element (by stitching it into the linked list) -
one day.
llvm-svn: 216761
Do not warn when property declared in class's protocol will be auto-synthesized
by its uper class implementation because super class has also declared this
property while this class has not. Continue to warn if current class
has declared the property also (because this declaration will not result
in a 2nd synthesis).
rdar://18152478
llvm-svn: 216753
Again, if shared ownership is the right model here (I assume it is,
given graph algorithms & such) this could be tidied up (the 'release'
call removed in favor of something safer) by having
IntrunsiveRefCntPointer constructible from a unique_ptr.
(& honestly I'd probably favor taking a page out of shared_ptr's book,
allowing implicit construction from a unique_ptr rvalue, and only allow
explicit from a raw pointer - currently IntrusiveRefCntPointer can
implicitly own from a raw pointer, which seems unsafe)
llvm-svn: 216752
Benjamin Kramer