- There is no reason to have a modules specific flag for disabling
autolinking. Instead, convert the existing flag into -fno-autolink (which
should cover other autolinking code generation paths like #pragmas if and
when we support them).
llvm-svn: 179612
isVirtual - matches CXXMethodDecl nodes for virtual methods
isOverride - matches CXXMethodDecl nodes for methods that override virtual methods from a base class.
Author: Philip Dunstan <phil@philipdunstan.com>
llvm-svn: 179126
This turns on not only destructor inlining, but inlining of constructors
for types with non-trivial destructors. Per r178516, we will still not
inline the constructor or destructor of anything that looks like a
container unless the analyzer-config option 'c++-container-inlining' is
set to 'true'.
In addition to the more precise path-sensitive model, this allows us to
catch simple smart pointer issues:
#include <memory>
void test() {
std::auto_ptr<int> releaser(new int[4]);
} // memory allocated with 'new[]' should not be deleted with 'delete'
<rdar://problem/12295363>
llvm-svn: 178805
http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb went back green
before it processed the reverted 178663, so it could not have been the culprit.
Revert "Revert 178663."
This reverts commit 4f8a3eb2ce5d4ba422483439e20c8cbb4d953a41.
llvm-svn: 178682
For variables and functions clang used to store two storage classes. The one
"as written" in the code and a patched one, which, for example, propagates
static to the following decls.
This apparently is from the days clang lacked linkage computation. It is now
redundant and this patch removes it.
llvm-svn: 178663
This option can be useful for end users who want to know why they
ended up with a ton of different variants of the "std" module in their
module cache. This problem should go away over time, as we reduce the
need for module variants, but it will never go away entirely.
llvm-svn: 178148
Added two new narrowing matchers:
* hasMethod: aplies a matcher to a CXXRecordDecl's methods until a match is made
or there are no more methods.
* hasCanonicalType: applies a matcher to a QualType's canonicalType.
Enhanced hasOverloadedOperatorName to work on CXXMethodDecl as well as
CXXOperatorCallExpr.
Updated tests and docs.
Reviewers: klimek, gribozavr
llvm-svn: 176556
Instead of passing NULL on to sub-matcher, just return false. Updated tests and
regenerated docs.
Author: Tareq A Siraj <tareq.a.siraj@intel.com>
llvm-svn: 176441
of block declarators. Document the rule we use.
Also document the rule that Doug implemented a few weeks ago
which drops ownership qualifiers on function result types.
rdar://10127067
llvm-svn: 176336
This enables constructor inlining for types with non-trivial destructors.
The plan is to enable destructor inlining within the next month, but that
needs further verification.
<rdar://problem/12295329>
llvm-svn: 176200
These are two related changes (one in llvm, one in clang).
LLVM:
- rename address_safety => sanitize_address (the enum value is the same, so we preserve binary compatibility with old bitcode)
- rename thread_safety => sanitize_thread
- rename no_uninitialized_checks -> sanitize_memory
CLANG:
- add __attribute__((no_sanitize_address)) as a synonym for __attribute__((no_address_safety_analysis))
- add __attribute__((no_sanitize_thread))
- add __attribute__((no_sanitize_memory))
for S in address thread memory
If -fsanitize=S is present and __attribute__((no_sanitize_S)) is not
set llvm attribute sanitize_S
llvm-svn: 176076
TemplateSpecializationType doesn't quite have getDecl(). Need to go
through TemplateName to get a TemplateDecl.
Added test cases for the hasDeclaration() overload for
TemplateSpecializationType. Also introduced the type matcher
templateSpecializationType() used by the new hasDeclaration() test case.
Updated LibASTMatchersReference.
Reviewers: klimek
llvm-svn: 176025
After changing the way several value inheritance hierarchies (TypeLoc,
CFGelement, ProgramPoint and SVal) handle casting, this documentation describes
how 3rd party code may need to be updated to compile with the new APIs.
As suggested by Sean Silva on cfe-dev.
llvm-svn: 175970
to control the check for the C 5.2.4.1 / C++ [implimits] restriction on nesting
levels for parentheses, brackets and braces.
Some code with heavy macro use exceeds the default limit of 256, but we don't
want to increase it generally to avoid stack overflow on stack-constrained
systems.
llvm-svn: 175855
that a __strong object of block type is a valid argument to objc_storeStrong but
that an objc_retain and not an objc_retainBlock will be emitted.
llvm-svn: 175838
I don't want to rule out the possibility of linking to e.g. interesting
blog posts about uses of Clang, so avoid restricting the content to
"projects".
This breaks URL compatibility, but this document was committed less than
an hour ago so hopefully nobody has linked to it yet.
llvm-svn: 175535
Using a new metafunction for detecting the presence of the member
'getDecl' in a type T, added support to hasDeclaration for any such type
T. This allows hasDecl() to be replaced and enables several other
subclasses of clang::Type to use hasDeclaration.
Updated unittests and LibASTMatchersReference.html.
Reviewers: klimek
llvm-svn: 175532
A couple concrete examples are sure to be a win. If you know of any
other external projects using Clang, please let me know!
Patch by Laszlo Nagy! (with a title tweak by me)
llvm-svn: 175529
I'm using the name "Extended Identifiers" for the feature because that's
what GCC calls them. According to the standard, the new feature is
"universal character names are now allowed in identifiers", but the more
interesting "feature" is that identifiers can now contain Unicode characters,
however they are written.
llvm-svn: 174798
This is a powerful tool when doing iterative refined matches,
where another match is started inside the match callback of the first
one; this allows for example to find out whether the node was in
the condition or body of its parent if-statement.
llvm-svn: 174605
This is in preparation for adding other overloaded matchers. This change
alone is a net win in LOC.
I went through all matchers and looked whether we could now encode them
as macro, or simplify them with the matcher atoms that were not
available before.
llvm-svn: 174540
This is a text file with Markdown-ish formatting because we haven't decided
where analyzer internal documents should go, but it's probably better to
have this in source control than sitting on my local drive forever.
llvm-svn: 174398
We found that findAll has been implemented incorrectly multiple times
by various people using the matchers. To prevent further wasted
development effort, it makes sense to add it as convenience matcher
implemented as eachOf(m, forEachDescendant(m)).
This patch also updates the docs with the new matchers.
llvm-svn: 174320
implementation; this is much more inline with the original implementation
(i.e., pre-ubsan) and does not require run-time library support.
The trapping implementation can be invoked using either '-fcatch-undefined-behavior'
or '-fsanitize=undefined-trap -fsanitize-undefined-trap-on-error', with the latter
being preferred. Eventually, the -fcatch-undefined-behavior' flag will be removed.
llvm-svn: 173848
This adds documentation for both LibFormat as well as the standalone
tools and integrations built on top of it. It slightly restructures
the ClangTools documentation.
llvm-svn: 172004
Clang doesn't understand it.
If someone wants to teach clang about that flag instead, please also add
support for -fno-diagnostics-parseable-fixits for consistency.
Until then, let the documentation match the current behavior.
llvm-svn: 171952
This fixes the URL permanence of that URL. This is a bit of a hack. See
the FIXME in the patch for what the "real" solution should be.
llvm-svn: 171795
This is just the output of sphinx-quickstart. Now all that is needed
to begin converting the analyzer docs to reST is the server-side setup.
The analyzer folks have asked me to keep this segregated from the other
clang docs since the analyzer is a logically separate project (and has
its own separate web page) even though it resides in the clang tree.
llvm-svn: 171425
Even though we do have a `.. warning::` directive on the page, hopefully
having "In-Progress" in the title will help to condition people's
expectations a bit for when they run into the extremely bare-bones
release notes.
Also, when release season comes around again, maybe this will get
people's attention and avoid confusion about what is going into the
upcoming release, and what is for changes to trunk for the next version.
llvm-svn: 171419
The way Sphinx treats the "top-level" adornments is weird. It usually
uses the first top-level adornment as the page title, even if the
top-level adornment is just one "section" out of many (i.e. if the first
section is "Introduction", then it will make the page title be
"Introduction"). This behavior can be overriden by using an explicit
`.. title::` directive to set the title.
Since the Sphinx stylesheet that Clang is currently using ('haiku')
nicely puts the document title at the top of the page in the header,
this weird default behavior was resulting in a redundant "title" in the
body content. Getting rid of this redundant level of headings
effectively "exposes" one more level of heading from the stylesheet to
which now makes the real "sections" more distinct.
llvm-svn: 171417
Language extensions are highly relevant to using clang as a compiler, so
move LanguageExtensions up into `Using Clang as a Compiler` on the
landing page.
The other documents from the now-gone `Language Extensions and Specs`
section on the landing page nicely fit hierarchically under
LanguageExtensions.rst, so put them under LanguageExtensions.rst's
toctree instead of on the landing page.
Impetus from Jordan Rose.
llvm-svn: 171409
I clustered the docs by some intuitive/fuzzy notion of "similarity", and
some reasonable categories seemed to materialize. I tried to give the
clusters useful names, but you may want to take a look at the landing
page (<http://clang.llvm.org/docs/> for the lazy) and share your
thoughts.
I have to say, this small change really gives the docs a whole new life!
It makes our documentation quite a bit easier to navigate and scope out.
llvm-svn: 171379
The core of this page is a set of pros/cons for the different ways to
use clang as a library. The title should reflect that the page helps you
choose between alternatives.
llvm-svn: 171377
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
The notes on the objc_method_family and ns_returns_retained-type attributes
have been moved to the Objective-C section, since both are used by ARC.
The notes on analyzer_noreturn are now only on the analyzer site.
The inadequacy of these docs was noticed months ago by Jonathan Sauer;
I'm only just now getting around to cleaning them up.
llvm-svn: 170261
The file still exists in docs/analyzer/, but it won't be linked to from
clang.llvm.org or processed as part of the default Sphinx doc-build.
RegionStore has changed a lot from what Ted and Zhongxing describe here!
llvm-svn: 170260
- Renaming GetCompilations() and GetSourcePathList() to follow LLVM
style.
- Updating docs to reflect name change.
- Also updating help text to not mention clang-check since this class
can be used by any tool.
Reviewed By: Alexander Kornienko
llvm-svn: 170229
Converts:
LanguageExtensions
LibASTMatchers
LibTooling
PCHInternals
ThreadSanitizer
Tooling
Patch by Mykhailo Pustovit!
(with minor edits by Dmitri Gribenko and Sean Silva)
llvm-svn: 170048
I don't think this will be visible just yet on <clang.llvm.org/docs/>
since I don't think that the necessary server-side setup has taken
place.
Don't shoot me over the theme. I don't want to duplicate LLVM's theme
into the clang repo at the moment, so I just used one of Sphinx's
default themes.
llvm-svn: 170042
1) init-order sanitizer: initialization-order checker.
Status: usable, but may produce false positives w/o proper blacklisting.
2) use-after-return sanitizer
Status: implemented, but heavily understed.
Should be optional, as it significanlty slows program down.
3) use-after-scope sanitizer
Status: in progress.
llvm-svn: 168950
This change was initially proposed as a solution to the problem highlighted by check-in r164677, i.e. that -verify will not cause a test-case failure where the compile command does not actually reference the file.
Patch reviewed by David Blaikie.
llvm-svn: 166281
headers and modules in more detail. I'd still like to expand on some
of the modules-related issues further, but this is a decent start.
llvm-svn: 163989
This allows linking to LibASTMatchersRefernce.html#<matcher><N>Anchor to
link to the N'the declaration of a matcher and automatically expand
its documentation.
llvm-svn: 163386
Summary: New clang-check vim integration with the 're-run the last invocation when executed from .h file' feature.
Reviewers: klimek
Reviewed By: klimek
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D35
llvm-svn: 163211
Ted Kremenek