So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and
`dyn_cast`s for fun. This is a portion of what it found for clang; I
plan to do similar cleanups in LLVM and other subprojects when I find
time.
Because of the volume of changes, I explicitly avoided making any change
that wasn't highly local and obviously correct to me (e.g. we still have
a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading
is a thing and the cast<Bar> did actually change the type -- just up the
class hierarchy).
I also tried to leave the types we were cast<>ing to somewhere nearby,
in cases where it wasn't locally obvious what we were dealing with
before.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@326416 91177308-0d34-0410-b5e6-96231b3b80d8
It'd be better that they are #cmakedefine01 rather than #cmakedefine.
(#if FOO rather than #if defined(FOO))
Then we can find missing #include "clang/Config/config.h" in the future.
Differential Revision: https://reviews.llvm.org/D35541
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316061 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM_ENABLE_MODULES is sensitive of -D. Move them into config.h.
FIXME: It'd be better that they are #cmakedefine01 rather than #cmakedefine.
(#if FOO rather than #if defined(FOO))
Then we can find missing #include "clang/Config/config.h" in the future.
Differential Revision: https://reviews.llvm.org/D35527
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@308277 91177308-0d34-0410-b5e6-96231b3b80d8
Sema holds the current FPOptions which is adjusted by 'pragma STDC
FP_CONTRACT'. This then gets propagated into expression nodes as they are
built.
This encapsulates FPOptions so that this propagation happens opaquely rather
than directly with the fp_contractable on/off bit. This allows controlled
transitioning of fp_contractable to a ternary value (off, on, fast). It will
also allow adding more fast-math flags later.
This is toward moving fp-contraction=fast from an LLVM TargetOption to a
FastMathFlag in order to fix PR25721.
Differential Revision: https://reviews.llvm.org/D31166
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298877 91177308-0d34-0410-b5e6-96231b3b80d8
This changes the CompilerInstance::createOutputFile function to return
a std::unique_ptr<llvm::raw_ostream>, rather than an llvm::raw_ostream
implicitly owned by the CompilerInstance. This in most cases required that
I move ownership of the output stream to the relevant ASTConsumer.
The motivation for this change is to allow BackendConsumer to be a client
of interfaces such as D20268 which take ownership of the output stream.
Differential Revision: http://reviews.llvm.org/D21537
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275507 91177308-0d34-0410-b5e6-96231b3b80d8
All current properties are instance properties.
This is the second patch in a series of patches to support class properties
in addition to instance properties in objective-c.
rdar://23891898
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258824 91177308-0d34-0410-b5e6-96231b3b80d8
The pointer was being implicitly converted to a StringRef and the size was being passed into the bool. Since the bool has a default value normally, no one noticed that the wrong number of arguments was given.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250977 91177308-0d34-0410-b5e6-96231b3b80d8
The pattern was born out of the lack of range-based for loops in C++98
and is somewhat obscure. No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241300 91177308-0d34-0410-b5e6-96231b3b80d8
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240270 91177308-0d34-0410-b5e6-96231b3b80d8
Bitfield RefersToEnclosingLocal of Stmt::DeclRefExprBitfields renamed to RefersToCapturedVariable to reflect latest changes introduced in commit 224323. Also renamed method Expr::refersToEnclosingLocal() to Expr::refersToCapturedVariable() and comments for constant arguments.
No functional changes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224329 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, if global variable is marked as a private OpenMP variable, the compiler crashes in debug version or generates incorrect code in release version. It happens because in the OpenMP region the original global variable is used instead of the generated private copy. It happens because currently globals variables are not captured in the OpenMP region.
This patch adds capturing of global variables iff private copy of the global variable must be used in the OpenMP region.
Differential Revision: http://reviews.llvm.org/D6259
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224323 91177308-0d34-0410-b5e6-96231b3b80d8
After post-commit review and community discussion, this seems like a
reasonable direction to continue, making ownership semantics explicit in
the source using the type system.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215323 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r213307.
Reverting to have some on-list discussion/confirmation about the ongoing
direction of smart pointer usage in the LLVM project.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213325 91177308-0d34-0410-b5e6-96231b3b80d8
(after fixing a bug in MultiplexConsumer I noticed the ownership of the
nested consumers was implemented with raw pointers - so this fixes
that... and follows the source back to its origin pushing unique_ptr
ownership up through there too)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213307 91177308-0d34-0410-b5e6-96231b3b80d8
The rewrite facility's footprint is small so it's not worth going to these
lengths to support disabling at configure time, particularly since key compiler
features now depend on it.
Meanwhile the Objective-C rewriters have been moved under the
ENABLE_CLANG_ARCMT umbrella for now as they're comparatively heavy and still
potentially worth excluding from lightweight builds.
Tests are now passing with any combination of feature flags. The flags
historically haven't been tested by LLVM's build servers so caveat emptor.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213171 91177308-0d34-0410-b5e6-96231b3b80d8
Stephen Kelly