This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us to store debug information in the module file that can be shared by all
object files that were built importing the module.
rdar://problem/19104245
This reapplies r230044 with a fixed configure+make build and updated
dependencies. Take 3.
llvm-svn: 230305
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us to store debug information in the module file that can be shared by all
object files that were built importing the module.
rdar://problem/19104245
This reapplies r230044 with a fixed configure+make build and updated
dependencies. Take 2.
llvm-svn: 230089
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us to store debug information in the module file that can be shared by all
object files that were built importing the module.
rdar://problem/19104245
This reapplies r230044 with a fixed configure+make build and updated
dependencies.
llvm-svn: 230067
This patch introduces the -fsanitize=cfi-vptr flag, which enables a control
flow integrity scheme that checks that virtual calls take place using a vptr of
the correct dynamic type. More details in the new docs/ControlFlowIntegrity.rst
file.
It also introduces the -fsanitize=cfi flag, which is currently a synonym for
-fsanitize=cfi-vptr, but will eventually cover all CFI checks implemented
in Clang.
Differential Revision: http://reviews.llvm.org/D7424
llvm-svn: 230055
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us to store debug information in the module file that can be shared by all
object files that were built importing the module.
rdar://problem/19104245
llvm-svn: 230044
If this flag is set, we error out when a module build is required. This is
useful in environments where all required modules are passed via -fmodule-file.
llvm-svn: 230006
They autotools build has a number of missing features, supports less
OS, architectures, build configurations, doesn't have any tests and
is hard to support in sync with CMake build.
llvm-svn: 229554
We appear to use 3.5.0 in the directory structure now. That's probably
unnecessary. We should probably let the micro releases update the docs
for the same minor version.
llvm-svn: 227127
Introduce the following -fsanitize-recover flags:
- -fsanitize-recover=<list>: Enable recovery for selected checks or
group of checks. It is forbidden to explicitly list unrecoverable
sanitizers here (that is, "address", "unreachable", "return").
- -fno-sanitize-recover=<list>: Disable recovery for selected checks or
group of checks.
- -f(no-)?sanitize-recover is now a synonym for
-f(no-)?sanitize-recover=undefined,integer and will soon be deprecated.
These flags are parsed left to right, and mask of "recoverable"
sanitizer is updated accordingly, much like what we do for -fsanitize= flags.
-fsanitize= and -fsanitize-recover= flag families are independent.
CodeGen change: If there is a single UBSan handler function, responsible
for implementing multiple checks, which have different recoverable setting,
then we emit two handler calls instead of one:
the first one for the set of "unrecoverable" checks, another one - for
set of "recoverable" checks. If all checks implemented by a handler have the
same recoverability setting, then the generated code will be the same.
llvm-svn: 225719
I'd be interested if the paragraph on Parse not knowing much about AST is
something folks agree with. I think this used to be true after rjmccall removed
the Action interface in r112244 and I believe it's still true, but I'm not sure.
(For example, ParseOpenMP.cpp does include AST/StmtOpenMP.h. Other than that,
Parse not using AST nodes much seems to be still true, though.)
llvm-svn: 224894
With alignment:
int aaaaaa = aa
+ bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
* cccccccccccccccccccccccccccccccc;
Without alignment:
int aaaaaa = aa
+ bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
* cccccccccccccccccccccccccccccccc;
This fixes llvm.org/PR21666.
llvm-svn: 223117
Change to original: ifndef out tests in Windows due to /-separated
paths.
Summary:
Often one is only interested in matches within the main-file or matches
that are not within a system-header, for which this patch adds
isInMainFile and isInSystemFile. They take no arguments and narrow down
the matches.
The isInFileMatchingName is mainly thought for interactive
clang-query-sessions, to make a matcher more specific without restarting
the session with the files you are interested in for that moment. It
takes a string that will be used as regular-expression to match the
filename of where the matched node is expanded.
Patch by Hendrik von Prince.
llvm-svn: 222765
Rethrowing exceptions in the MS model is very simple: just call
_CxxThrowException with nullptr for both arguments.
N.B. They chose stdcall as the calling convention for x86 but cdecl for
all other platforms.
llvm-svn: 222733
Summary:
Often one is only interested in matches within the main-file or matches
that are not within a system-header, for which this patch adds
isInMainFile and isInSystemFile. They take no arguments and narrow down
the matches.
The isInFileMatchingName is mainly thought for interactive
clang-query-sessions, to make a matcher more specific without restarting
the session with the files you are interested in for that moment. It
takes a string that will be used as regular-expression to match the
filename of where the matched node is expanded.
Patch by Hendrik von Prince.
llvm-svn: 222646
Improve the documentation for vim integration of clang-format. Prefer the use
of <c-o> to do the normal mode command execution to avoid side-effects of the
escape and re-insertion (cursor movement). Tweak the macros to use a double
return to avoid having to manually return control to the editor from the
subprocess.
llvm-svn: 220685
This allows a module to specify that it logically contains a file, but that
said file is non-modular and intended for textual inclusion. This allows
layering checks to work properly in the presence of such files.
llvm-svn: 220448
This is long-since overdue, and matches GCC 5.0. This should also be
backwards-compatible, because we already supported all of C11 as an extension
in C99 mode.
llvm-svn: 220244
#include_next interacts poorly with modules: it depends on where in the list of
include paths the current file was found. Files covered by module maps are not
found in include search paths when building the module (and are not found in
include search paths when @importing the module either), so this isn't really
meaningful. Instead, we fake up the result that #include_next *should* have
given: find the first path that would have resulted in the given file being
picked, and search from there onwards.
llvm-svn: 220177
This commit changes the way we blacklist global variables in ASan.
Now the global is excluded from instrumentation (either regular
bounds checking, or initialization-order checking) if:
1) Global is explicitly blacklisted by its mangled name.
This part is left unchanged.
2) SourceLocation of a global is in blacklisted source file.
This changes the old behavior, where instead of looking at the
SourceLocation of a variable we simply considered llvm::Module
identifier. This was wrong, as identifier may not correspond to
the file name, and we incorrectly disabled instrumentation
for globals coming from #include'd files.
3) Global is blacklisted by type.
Now we build the type of a global variable using Clang machinery
(QualType::getAsString()), instead of llvm::StructType::getName().
After this commit, the active users of ASan blacklist files
may have to revisit them (this is a backwards-incompatible change).
llvm-svn: 220097
Adds a Clang-specific implementation of C11's stdatomic.h header. On systems,
such as FreeBSD, where a stdatomic.h header is already provided, we defer to
that header instead (using our __has_include_next technology). Otherwise, we
provide an implementation in terms of our __c11_atomic_* intrinsics (that were
created for this purpose).
C11 7.1.4p1 requires function declarations for atomic_thread_fence,
atomic_signal_fence, atomic_flag_test_and_set,
atomic_flag_test_and_set_explicit, and atomic_flag_clear, and requires that
they have external linkage. Accordingly, we provide these declarations, but if
a user elides the shadowing macros and uses them, then they must have a libc
(or similar) that actually provides definitions.
atomic_flag is implemented using _Bool as the underlying type. This is
consistent with the implementation provided by FreeBSD and also GCC 4.9 (at
least when __GCC_ATOMIC_TEST_AND_SET_TRUEVAL == 1).
Patch by Richard Smith (rebased and slightly edited by me -- Richard said I
should drive at this point).
llvm-svn: 218957
being on by default. -fno-cxx-modules can still be used to enable C modules but
not C++ modules, but C++ modules is not significantly less stable than C
modules any more.
Also remove some of the scare words from the modules documentation. We're
certainly not going to remove modules support (though we might change the
interface), and it works well enough to bootstrap and build lots of
non-trivial code.
Note that this does not represent a commitment to the current interface nor
implementation, and we still intend to follow whatever direction the C and C++
committees take regarding modules support.
llvm-svn: 218717
The attribute documentation now conforms to Aaron Ballman's renaming of the
thread safety attributes, as well as the new paper that is due to be published
in the conference on Source Code Analysis and Manipulation (SCAM 2014) later
this week. In addition, recent changes to the analysis, such as checking
of references and negative capabilities, are now documented.
llvm-svn: 218420
The reasoning is that this construct is accepted by all compilers and valid in
C++11, so it doesn't seem like a useful warning to have enabled by default.
Building with -pedantic, -Wbind-to-temporary-copy, or -Wc++98-compat still
shows the warning.
The motivation is that I built re2, and this was the only warning that was
emitted during the build. Both changing re2 to fix the warning and detecting
clang and suppressing the warning in re2's build seem inferior than just giving
the compiler a good default for this warning.
Also move the cxx98compat version of this warning to CXX98CompatPedantic, and
update tests accordingly.
llvm-svn: 218008
On a single line:
switch (a) {
case 1: x = 1; return;
case 2: x = 2; return;
default: break;
}
Not on a single line:
switch (a) {
case 1:
x = 1;
return;
case 2:
x = 2;
return;
default:
break;
}
This partly addresses llvm.org/PR16535. In the long run, we probably want to
lay these out in columns.
llvm-svn: 217501
Summary:
This patch implements a new UBSan check, which verifies
that function arguments declared to be nonnull with __attribute__((nonnull))
are actually nonnull in runtime.
To implement this check, we pass FunctionDecl to CodeGenFunction::EmitCallArgs
(where applicable) and if function declaration has nonnull attribute specified
for a certain formal parameter, we compare the corresponding RValue to null as
soon as it's calculated.
Test Plan: regression test suite
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits, rnk
Differential Revision: http://reviews.llvm.org/D5082
llvm-svn: 217389
This makes use of the recently-added @llvm.assume intrinsic to implement a
__builtin_assume(bool) intrinsic (to provide additional information to the
optimizer). This hooks up __assume in MS-compatibility mode to mirror
__builtin_assume (the semantics have been intentionally kept compatible), and
implements GCC's __builtin_assume_aligned as assume((p - o) & mask == 0). LLVM
now contains special logic to deal with assumptions of this form.
llvm-svn: 217349
Added cast operations to the table of vector operations. Supported status 'no' means that there are no tests in the Clang test suite for the given cast.
llvm-svn: 217055
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
Summary:
This patch adds a runtime check verifying that functions
annotated with "returns_nonnull" attribute do in fact return nonnull pointers.
It is based on suggestion by Jakub Jelinek:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140623/223693.html.
Test Plan: regression test suite
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4849
llvm-svn: 215485
to instruct the code generator to not enforce a higher alignment
than the given number (of bytes) when accessing memory via an opaque
pointer or reference. Patch reviewed by John McCall (with post-commit
review pending). rdar://16254558
llvm-svn: 214911
This is required for GNU coding style, among others.
Also update the configuration documentation.
Modified from an original patch by Jarkko Hietaniemi, thank you!
llvm-svn: 214858
This patch flips the default value for -gcolumn-info to be on by
default. I discussed the rationale and provided compile/size data
in:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/074290.html
This also updates the documentation and some tests that relied on
the lack of column information. Some tests had column information
in the expected output, but it was wrong (the tsan tests). Others
were using the driver to execute.
llvm-svn: 212781
Though not completely identical, make former
IndentFunctionDeclarationAfterType change this flag for backwards
compatibility (it is somewhat close in meaning and better the err'ing on
an unknown config flag).
llvm-svn: 212597
StmtDumper.cpp is called ASTDumper.cpp these days, and usually works well
for new AST nodes without changes. There's now DataRecursiveASTVisitor
in addition to RecursiveASTVisitor, and serialization wasn't mentioned.
llvm-svn: 212426
It hasn't been updated to reflect the progress we've made. We've fuzz
tested VFTables, VBTables, layout, and RTTI data. We support lambdas
that are compatible with their scheme.
llvm-svn: 212193
ARMv8 adds (to both AArch32 and AArch64) acquiring and releasing
variants of the exclusive operations, in line with the C++11 memory
model.
This adds support for two new intrinsics to expose them to C & C++
developers directly: __builtin_arm_ldaex and __builtin_arm_stlex, in
direct analogy with the versions with no implicit barrier.
rdar://problem/15885451
llvm-svn: 212175
Summary:
This new debug emission kind supports emitting line location
information in all instructions, but stops code generation
from emitting debug info to the final output.
This mode is useful when the backend wants to track source
locations during code generation, but it does not want to
produce debug info. This is currently used by optimization
remarks (-Rpass, -Rpass-missed and -Rpass-analysis).
When one of the -Rpass flags is used, the front end will enable
location tracking, only if no other debug option is enabled.
To prevent debug information from being generated, a new debug
info kind LocTrackingOnly causes DIBuilder::createCompileUnit() to
not emit the llvm.dbg.cu annotation. This blocks final code generation
from generating debug info in the back end.
Depends on D4234.
Reviewers: echristo, dblaikie
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4235
llvm-svn: 211610
Extend the documentation for "#pragma clang loop" hints to include the unroll
and unroll_count directives.
Patch by Mark Heffernan [http://reviews.llvm.org/D4198]
llvm-svn: 211286
Init-order and use-after-return modes can currently be enabled
by runtime flags. use-after-scope mode is not really working at the
moment.
The only problem I see is that users won't be able to disable extra
instrumentation for init-order and use-after-scope by a top-level Clang flag.
But this instrumentation was implicitly enabled for quite a while and
we didn't hear from users hurt by it.
llvm-svn: 210924
Summary:
Add hasLocalStorage/hasGlobalStorage matchers for VarDecl nodes.
Update the doc. Also add them to the dynamic registry.
Reviewers: klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D4034
llvm-svn: 210278
to the normal non-placement ::operator new and ::operator delete, but allow
optimizations like new-expressions and delete-expressions do.
llvm-svn: 210137
Summary:
This adds documentation for -Rpass, -Rpass-missed and -Rpass-analysis.
It also adds release notes for 3.5.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3730
llvm-svn: 209841
Summary:
This documents the usage of sample profilers with Clang and the
profile format expected by LLVM's optimizers. It also documents the
profile conversion tool used by Linux Perf.
Reviewers: doug.gregor
CC: cfe-commits
Differential Revision: http://reviews.llvm.org/D3402
llvm-svn: 206994
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
llvm-svn: 205100
Summary:
This allows them to be used without -cc1 the same way as -I and -isystem.
Renamed the options to --system-header-prefix=/--no-system-header-prefix to avoid interference with -isystem and make the intent of the option cleaner.
Reviewers: rsmith
Reviewed By: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3185
llvm-svn: 204775
This change turns -fsanitize-memory-track-origins into
-fsanitize-memory-track-origins=[level] flag (keeping the old one for
compatibility). Possible levels are 0 (off), 1 (default) and 2 (incredibly
detailed). See docs (part of this patch) for more info.
llvm-svn: 204346
This name, while more verbose, plays more nicely with tools that use
file extensions to determine file types. The existing spelling
'module.map' will continue to work, but the new spelling will take
precedence.
In frameworks, this new filename will only go in a new 'Modules'
sub-directory.
Similarly, add a module.private.modulemap corresponding to
module_private.map.
llvm-svn: 204261
r203272 enables generation of a Qt Compressed Help file for the LLVM source
code.
As a consequence, this change brings the same capabilities to Clang while
reusing these two variables:
LLVM_ENABLE_DOXYGEN_QT_HELP
LLVM_DOXYGEN_QHELPGENERATOR_PATH
and adding
CLANG_DOXYGEN_QCH_FILENAME="org.llvm.clang.qch"
CLANG_DOXYGEN_QHP_NAMESPACE="org.llvm.clang"
CLANG_DOXYGEN_QHP_CUST_FILTER_NAME="Clang ${CLANG_VERSION}"
CLANG_DOXYGEN_QHP_CUST_FILTER_ATTRS="Clang,${CLANG_VERSION}"
Patch by Konrad Kleine.
llvm-svn: 203801
Summary:
Add loc() to the dynamic registry.
Other fixes:
- Fix the polymorphic variant value to accept an exact match, even if
there are other possible conversions.
- Fix specifiesTypeLoc() to not crash on an empty
NestedNameSpecifierLoc.
Reviewers: klimek
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2928
llvm-svn: 203467
it, importers of B should not see the macro. This is complicated by the fact
that A's macro could also be visible through a different path. The rules (as
hashed out on cfe-commits) are included as a documentation update in this
change.
With this, the number of regressions in libc++'s testsuite when modules are
enabled drops from 47 to 7. Those remaining 7 are also macro-related, and are
due to remaining bugs in this change (in particular, the handling of submodules
is imperfect).
llvm-svn: 202560
This documents some of the status of supported functionality in MSVC
quirks mode. Some of this should be in
http://clang.llvm.org/compatibility.html instead when things have
stabilized.
llvm-svn: 202559
A 'remark' is information that is not an error or a warning, but rather some
additional information provided to the user. In contrast to a 'note' a 'remark'
is an independent diagnostic, whereas a 'note' always depends on another
diagnostic.
A typical use case for remark nodes is information provided to the user, e.g.
information provided by the vectorizer about loops that have been vectorized.
This patch provides the initial implementation of 'remarks'. It includes the
actual definiton of the remark nodes, their printing as well as basic parameter
handling. We are reusing the existing diagnostic parameters which means a remark
can be enabled with normal '-Wdiagnostic-name' flags and can be upgraded to
an error using '-Werror=diagnostic-name'. '-Werror' alone does not upgrade
remarks.
This patch is by intention minimal in terms of parameter handling. More
experience and more discussions will most likely lead to further enhancements
in the parameter handling.
llvm-svn: 202475
Add documentation for these attributes, it includes:
- Motivation for their existence.
- Examples on how to use them.
- Examples on how to misuse them.
llvm-svn: 202121
Before this patch we would only use the fist occurance of a matcher
function in the documentation, for example leaving out
hasType(Matcher<QualType>).
llvm-svn: 202019
1. Move internal functions into ASTMatchersInternal.
2. Adapt dump_ast_matchers.py to the new VariadicOperatorMatcherFunc
signature.
3. Update the actual docs with the updated tool / code.
llvm-svn: 202017
Now that the integrated assembler is considered a first class feature of the
compiler and has a proper feature flag, document the change in the compiler
flags. Ensure that we indicate that the legacy flags are still available, but,
encourage users to switch to the feature flags.
llvm-svn: 201964
This is a temporary stop-gap solution until server-side generation is implemented, at which point the AttributeReference.rst will go back to holding placeholder text.
llvm-svn: 201733
This patch adds some very, very sparse initial documentation for some attributes. Additional effort from attribute authors is greatly appreciated.
llvm-svn: 201515
Instead point readers to the latest, correct example code in SVN until we find
a way to automatically include example sources into the documentation (or until
someone steps up to maintain these actively).
This ensures that the examples are up-to-date, buildable, and most of all that
readers don't pick up incorrect usage.
llvm-svn: 200125
Implement type trait primitives used in the latest edition of the Microsoft
standard C++ library type_traits header.
With this change we can parse much of the Visual Studio 2013 standard headers,
particularly anything that includes <type_traits>.
Fully implemented, available in all language modes:
* __is_constructible()
* __is_nothrow_constructible()
* __is_nothrow_assignable()
Partially implemented, semantic analysis WIP, available as MS extensions:
* __is_destructible()
* __is_nothrow_destructible()
llvm-svn: 199619
Update the documentation to clarify the intent of clang's built-in type trait
facilities, their relation to user-facing C++ type traits and means to check
for availability.
Also explain that __has_feature() is not currently up to date and should not
generally be used in user code (there's a proposal to provide more consistent
checks via __has_builtin(), see cfe-dev).
llvm-svn: 199562
This C++ feature has been marked complete since r191549, but the documentation
claimed it wasn't supported at all and the extension check misreported it as
being available in C.
No regression test; this was a short-lived typo.
llvm-svn: 199292
Someone recently wasted some time not realising that "-###" didn't
actually execute the commands it printed, and suggested a
documentation tweak.
Having made the same mistake myself on at least one occasion, I
sympathise. So here it is. Any kibitzing on an even better text
welcome.
llvm-svn: 199256
It controls everything that -flimit-debug-info used to, plus the
vtable type optimization. The old -fno-limit-debug-info option is now an
alias to -fstandalone-debug and vice versa.
Standalone is the default on Darwin until dtrace is updated to work with
non-standalone debug info (rdar://problem/15758808).
Note: I kept the LimitedDebugInfo name in CodeGenOptions::DebugInfoKind
because NoStandaloneDebugInfo sounded even more confusing.
llvm-svn: 198655
This is an experimental feature, where -integrated-as will be
on by default on ARM/Thumb. We aim to detect the missing features
so that the next release is stable.
Updating the ReleaseNotes, too.
Also moving the AArch64 into the same place.
llvm-svn: 197024
Add support for more filename extensions based on the list in the clang
plus JavaScript.
Also adds a -regex option so users can override defaults if they have unusual
file extensions or want to format everything in the diff.
Keeping with tradition the flag is modelled on Unix conventions, this time
matching the semantics of find(1).
llvm-svn: 196917
Summary:
The rule from the GNU style states:
"We find it easier to read a program when it has spaces before the open-parentheses and after the commas."
http://www.gnu.org/prep/standards/standards.html#index-spaces-before-open_002dparen
This patch makes clang-format adds an option to put spaces before almost all open parentheses, except the cases, where different behavior is dictated by the style rules or language syntax:
* preprocessor:
** function-like macro definitions can't have a space between the macro name and the parenthesis;
** `#if defined(...)` can have a space, but it seems, that it's more frequently used without a space in GCC, for example;
* never add spaces after unary operators;
* adding spaces between two opening parentheses is controlled with the `SpacesInParentheses` option;
* never add spaces between `[` and `(` (there's no option yet).
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2326
llvm-svn: 196901
Summary:
Add partial support for the hasDeclaration() matcher in the dynamic layer.
This matcher has some special logic to allow any type that has a getDecl() method. We do not support this right now.
Reviewers: klimek
CC: cfe-commits, revane
Differential Revision: http://llvm-reviews.chandlerc.com/D1889
llvm-svn: 195013
Summary:
Currently with clang:
$ clang -O20 foo.c
error: invalid value '20' in '-O20'
With the patch:
$ clang -O20 foo.c
warning: optimization level '-O20' is unsupported; using '-O3' instead.
1 warning generated.
This matches the gcc behavior (with a warning added)
Pass all tests:
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 94.14s
Expected Passes : 6721
Expected Failures : 20
Unsupported Tests : 17
(which was not the case of http://llvm-reviews.chandlerc.com/D2125)
Differential Revision: http://llvm-reviews.chandlerc.com/D2212
llvm-svn: 195009
Trying to fix test failures since earlier today.
One of the tests added in this commit is outputting test/Driver/clang_f_opts.s
which the builders that build in-tree (eg. clang-native-arm-cortex-a9) are
trying to run as a test case, causing failures.
clang_f_opts.c:
If -### doesn't emit the warning then this test probably shouldn't be in
here in the first place. Frontend maybe?
invalid-o-level.c:
Running %clang_cc1 in the Driver tests doesn't make sense because -cc1
bypasses the driver. (I'm not reverting the commit that introduced this but
please fix instead of keeping it this way.)
Reverting to fix the build failures and also so that the tests can be thought
out more thoroughly.
This reverts commit r194817.
llvm-svn: 194845
limited ways) after the next release. See the lengthy discussions (which
are on-going) and the corresponding commit to LLVM's release notes.
Nothing is actually changing at this point, this is just further
spreading the plan.
llvm-svn: 194184
requires ! feature
The purpose of this is to allow (for instance) the module map for /usr/include
to exclude <tgmath.h> and <complex.h> when building in C++ (these headers are
instead provided by the C++ standard library in this case, and the glibc C
<tgmath.h> header would otherwise try to include <complex.h>, resulting in a
module cycle).
llvm-svn: 193549
it. Also removes all of the microsoft C++ ABI related code from the
itanium layout builder.
Differential Revision: http://llvm-reviews.chandlerc.com/D2003
llvm-svn: 193290
This uses function prefix data to store function type information at the
function pointer.
Differential Revision: http://llvm-reviews.chandlerc.com/D1338
llvm-svn: 193058
This adds support for outputing the assembly to a file during compilation.
It does this by changing the compilation pipeling to not use the integrated
assembler, and keep the intermediate assembler file.
Differential Revision: http://llvm-reviews.chandlerc.com/D1946
llvm-svn: 192902
There doesn't seem to be a need in checking if a directory exists if we
will just rm -rf it once we affirm that it does. Instead, just blindly
try to delete it.
This fixes PR17541.
llvm-svn: 192680
This will emit a warning if a call to clang_analyzer_warnIfReached is
executed, printing REACHABLE. This is a more explicit way to declare
expected reachability than using clang_analyzer_eval or triggering
a bug (divide-by-zero or null dereference), and unlike the former will
work the same in inlined functions and top-level functions. Like the
other debug helpers, it is part of the debug.ExprInspection checker.
Patch by Jared Grubb!
llvm-svn: 191909
This attribute allows users to use a modified C or C++ function as an ARM
exception-handling function and, with care, to successfully return control to
user-space after the issue has been dealt with.
rdar://problem/14207019
llvm-svn: 191769
With this option, arbitrarily named module map files can be specified
to be loaded as required for headers in the respective (sub)directories.
This, together with the extern module declaration allows for specifying
module maps in a modular fashion without the need for files called
"module.map".
Among other things, this allows a directory to contain two modules that
are completely independent of one another.
Review: http://llvm-reviews.chandlerc.com/D1697.
llvm-svn: 191284
Review: http://llvm-reviews.chandlerc.com/D1546.
I have picked up this patch form Lawrence
(http://llvm-reviews.chandlerc.com/D1063) and did a few changes.
From the original change description (updated as appropriate):
This patch adds a check that ensures that modules only use modules they
have so declared. To this end, it adds a statement on intended module
use to the module.map grammar:
use module-id
A module can then only use headers from other modules if it 'uses' them.
This enforcement is off by default, but may be turned on with the new
option -fmodules-decluse.
When enforcing the module semantics, we also need to consider a source
file part of a module. This is achieved with a compiler option
-fmodule-name=<module-id>.
The compiler at present only applies restrictions to the module directly
being built.
llvm-svn: 191283
LLVM supports applying conversion instructions to vectors of the same number of
elements (fptrunc, fptosi, etc.) but there had been no way for a Clang user to
cause such instructions to be generated when using builtin vector types.
C-style casting on vectors is already defined in terms of bitcasts, and so
cannot be used for these conversions as well (without leading to a very
confusing set of semantics). As a result, this adds a __builtin_convertvector
intrinsic (patterned after the OpenCL __builtin_astype intrinsic). This is
intended to aid the creation of vector intrinsic headers that create generic IR
instead of target-dependent intrinsics (in other words, this is a generic
_mm_cvtepi32_ps). As noted in the documentation, the action of
__builtin_convertvector is defined in terms of the action of a C-style cast on
each vector element.
llvm-svn: 190915
Unlike C++11's "thread_local" keyword, C11's "_Thread_local" is in the
reserved namespace, meaning we provide it unconditionally; it is marked
as KEYALL in TokenKinds.def.
This means that like all the other C11 keywords, we can expose its
presence through __has_extension().
llvm-svn: 190755
This patch is the first step to make module-map-files modular (instead
of requiring a single "module.map"-file per include directory). This
step adds a new "extern module" declaration that enables
module-map-files to reference one another along with a very basic
implementation.
The next steps are:
* Combine this with the use-declaration (from
http://llvm-reviews.chandlerc.com/D1546) in order to only load module
map files required for a specific compilation.
* Add an additional flag to start with a specific module-map-file (instead
of requiring there to be at least one "module.map").
Review: http://llvm-reviews.chandlerc.com/D1637
llvm-svn: 190497
Some build systems use pipes for stdin/stderr. On nix-ish platforms colored
output can be forced by -fcolor-diagnostics. On Windows this option has
no effect in these cases because LLVM uses the console API (which only
operates on the console buffer) even if a console wrapper capable of
interpreting ANSI escape codes is used.
The -fansi-escape-codes option allows switching from the console API to
ANSI escape codes. It has no effect on other platforms.
llvm-svn: 190464
Dotfiles are impractical on Windows. This makes clang-format search
for the style configuration file as '_clang-format' in addition to
the usual '.clang-format'. This is similar to how VIM searches for
'_vimrc' on Windows.
Differential Revision: http://llvm-reviews.chandlerc.com/D1629
llvm-svn: 190413
It was really hard to tell that modules are experimental. This makes it
really clear by
* Noting the experimental status in the title.
* Moving the "warning" above the table of contents.
llvm-svn: 190340
Half the internet has wildly incorrect ideas about what LLVM is (in
particular, many get the impression that LLVM is some magical
cross-platform runtime), so saying "LLVM" near "cross-compilation" in a
user-facing doc might provoke confusion.
llvm-svn: 190338
Last I heard LSan is getting close to prime-time, but for now keep
LeakSanitizer.rst hidden (especially since it contains so little
content).
llvm-svn: 190337
Summary:
The main contents is in the ClangFormatStyleOptions.rst, which can be
updated from the Format.h by the dump_format_style.py script.
Reviewers: djasper, klimek
Reviewed By: klimek
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1597
llvm-svn: 189946
Summary:
Rewrite eachOf/allOf/anyOf to use a variadic operator, instead of hand-written calls to Polymorphic matchers.
This simplifies their definition and future changes to add them to the dynamic registry.
Reviewers: klimek
CC: cfe-commits, revane
Differential Revision: http://llvm-reviews.chandlerc.com/D1427
llvm-svn: 189357
Patch by chris.wailes@gmail.com. The following functionality was added:
* The same functionality is now supported for both CXXOperatorCallExprs and CXXMemberCallExprs.
* Factored out some code in StmtVisitor.
* Removed variables from the state map when their destructors are encountered.
* Started adding documentation for the consumed analysis attributes.
llvm-svn: 189059
Summary:
Refactor ArgumentAdaptativeMatcher matchers to remove the template from their declaration.
This facilitates dynamic registration. Change the registry code to use the regular overload resolution mechanism for adaptative matchers.
Reviewers: klimek
CC: cfe-commits, revane
Differential Revision: http://llvm-reviews.chandlerc.com/D1402
llvm-svn: 188560
DataFlowSanitizer is a generalised dynamic data flow analysis.
Unlike other Sanitizer tools, this tool is not designed to detect a
specific class of bugs on its own. Instead, it provides a generic
dynamic data flow analysis framework to be used by clients to help
detect application-specific issues within their own code.
Differential Revision: http://llvm-reviews.chandlerc.com/D966
llvm-svn: 187925
This allows the ObjFW runtime to correctly implement message forwarding
for messages which return a struct.
Patch by Jonathan Schleifer.
llvm-svn: 187174
cxx_init_capture. "generalized" is neither descriptive nor future-proof. No
compatibility problems expected, since we've never advertised having this
feature.
llvm-svn: 187058
A class with a field of non-POD-for-layout type is not POD-for-layout.
This computation should not depend on whether the field is of POD type
in the language sense.
Fixes PR16537.
Patch by Josh Magee.
llvm-svn: 186741
This adds three overloaded intrinsics to Clang:
T __builtin_arm_ldrex(const volatile T *addr)
int __builtin_arm_strex(T val, volatile T *addr)
void __builtin_arm_clrex()
The intent is that these do what users would expect when given most sensible
types. Currently, "sensible" translates to ints, floats and pointers.
llvm-svn: 186394
Summary:
Fixup the type traversal macros/matchers to specify the supported types.
Make the marshallers a little more generic to support any variadic function.
Update the doc script.
Reviewers: klimek
CC: cfe-commits, revane
Differential Revision: http://llvm-reviews.chandlerc.com/D1023
llvm-svn: 186340
& operator (ignoring any overloaded operator& for the type). The purpose of
this builtin is for use in std::addressof, to allow it to be made constexpr;
the existing implementation technique (reinterpret_cast to some reference type,
take address, reinterpert_cast back) does not permit this because
reinterpret_cast between reference types is not permitted in a constant
expression in C++11 onwards.
llvm-svn: 186053
#if defined(__has_foo("X")) && __has_foo("X")
is not a correct way to portably use __has_foo, because it is expanded to
#if 0 && 0("X")
... which is ill-formed.
Also add a missing ')'.
llvm-svn: 186047
Add a debug checker that is useful to understand how the ExplodedGraph is
built; it can be triggered using the following command:
clang -cc1 -analyze -analyzer-checker=debug.ViewExplodedGraph my_program.c
A patch by Béatrice Creusillet!
llvm-svn: 184768
This will enable users in security critical applications to perform
checked-arithmetic in a fast safe manner that is amenable to c.
Tests/an update to Language Extensions is included as well.
rdar://13421498.
llvm-svn: 184497
I have had several people ask me about why this builtin was not available in
clang (since it seems like a logical conclusion). This patch implements said
builtins.
Relevant tests are included as well. I also updated the Clang language extension reference.
rdar://14192664.
llvm-svn: 184227
Add __has_feature and __has_extension checks for C++1y features (based on the provisional names from
the C++ features study group), and update documentation to match.
llvm-svn: 181342
- 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
More generally, this adds a new configuration option 'c++-inlining', which
controls which C++ member functions can be considered for inlining. This
uses the new -analyzer-config table, so the cc1 arguments will look like this:
... -analyzer-config c++-inlining=[none|methods|constructors|destructors]
Note that each mode implies that all the previous member function kinds
will be inlined as well; it doesn't make sense to inline destructors
without inlining constructors, for example.
The default mode is 'methods'.
llvm-svn: 163004
parse doxygen comments for macros with libclang.
I'm not entirely happy about this script, but as it saves
a lot of work in keeping the docs up to date with the
actual code I think checking it in makes sense.
llvm-svn: 162690
Because the CXXNewExpr appears after the CXXConstructExpr in the CFG, we don't
actually have the correct region to construct into at the time we decide
whether or not to inline. The long-term fix (discussed in PR12014) might be to
introduce a new CFG node (CFGAllocator) that appears before the constructor.
Tracking the short-term fix in <rdar://problem/12180598>.
llvm-svn: 162689
Since DynamicTypeInfo is not inherently related to inlining or to dynamic
calls, it makes more sense (to me) to discuss it first.
Also fix some typos, massage some grammar, and (hopefully) improve precision
and clarity.
llvm-svn: 162365
Also, remove the FIXME about merging -analyzer-stats and the debug.Stats
checker. This would be a bad idea because simply running debug.Stats can
affect the output of -analyzer-stats.
llvm-svn: 162364
Formatting includes:
- removing line wraps (Emacs Cmd-Q), to make text easier to read
- provide useful indentation
- call out caveats and notes more explictly
Stylistically, I prefer the document talk in 3rd person instead of "we". The
term "we" is unambiguous, and sometimes refers to different things. I've passed
over the existing paragraphs and made them speak more about specific entities
that compose the analyzer and what they do (e.g., ExprEngine) instead of "we"
referring to the analyzer.
Further, I have substituted some vague concepts such as "state" or "program
state" and replaced them with their precise implementation counterparts (e.g.,
ProgramState). This makes the document more technically precise throughout the
entire narrative, which would sometimes use vague terms and other times precise
terms.
I've placed several comments within the document, which can be seen with
***TMK/COMMENT***, which indicate places that need to be enhanced or clarified,
or called out as questions about intended bheavior.
llvm-svn: 162338
Under -analyzer-ipa=basic-inlining, only C functions, blocks, and C++ static
member functions are inlined -- essentially, the calls that behave like simple
C function calls. This is essentially the behavior in Xcode 4.4.
C++ support still has some rough edges, and we don't want users to be worried
about them if they download and run their own checker. (In particular, the
massive number of false positives for analyzing LLVM comes from inlining
defensively-written code in contexts where more aggressive assumptions are
implicitly made. This problem is not unique to C++, but it is exacerbated by
the higher proportion of code that lives in header files in C++.)
The eventual goal is to be comfortable enough with C++ support (and simple
Objective-C support) to advance to -analyzer-ipa=inlining as the default
behavior. See the IPA design notes for more details.
llvm-svn: 162318
First, when synthesizing an explicitly strong/retain/copy property
of Class type, don't pretend during compatibility checking that the
property is actually assign. Instead, resolve incompatibilities
by secretly changing the type of *implicitly* __unsafe_unretained
Class ivars to be strong. This is moderately evil but better than
what we were doing.
Second, when synthesizing the setter for a strong property of
non-retainable type, be sure to use objc_setProperty. This is
possible when the property is decorated with the NSObject
attribute. This is an ugly, ugly corner of the language, and
we probably ought to deprecate it.
The first is rdar://problem/12039404; the second was noticed by
inspection while fixing the first.
llvm-svn: 162244
of matchers, categorized by type and fully expanded for the
context in which they can be used.
I used a script to generate this documentation which I'll want
to be scrunitized by a code review before checking it in.
llvm-svn: 162225
This attempts to be a higher-level description of our inlining heuristics
and decision trees than the source, where the work is spread out between
ExprEngine (mostly in ExprEngineCallAndReturn.cpp) and CallEvent, with a
few other classes participating as well.
llvm-svn: 162073
function arguments and arguments for variadic functions are of a particular
type which is determined by some other argument to the same function call.
Usecases include:
* MPI library implementations, where these attributes enable checking that
buffer type matches the passed MPI_Datatype;
* for HDF5 library there is a similar usecase as MPI;
* checking types of variadic functions' arguments for functions like
fcntl() and ioctl().
llvm-svn: 162067
structure of how we're building concrete tools as well as tooling
infrastructure as part of the Clang project.
This documentation is definitely still rough. If anyone can improve it,
flesh it out, or help structure it in a more natural way, please, help!
=] This is not my forte, and patches here are more than welcome!
llvm-svn: 161855
This time, make sure we don't try to print fixits with newline characters,
since they don't have a valid column width, and they don't look good anyway.
PR13417 (and originally <rdar://problem/11877454>)
llvm-svn: 160561
This code is very sensitive to the difference between "columns" as printed
and "bytes" (SourceManager columns). All variables are now named explicitly
and our assumptions are (hopefully) documented as both comment and assertion.
Whether parseable fixits should use byte offsets or Unicode character counts
is pending discussion on the mailing list; currently the implementation uses
bytes (and has no problems on lines containing multibyte characters).
This has been added to the user manual.
<rdar://problem/11877454>
llvm-svn: 160319
Summary: How to guide for setting up clang tooling for llvm repo.
Test Plan: this is untested
Reviewers: klimek, djasper
Reviewed By: klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D3
llvm-svn: 160047
*errors* with fixits on them by following the recovery advised by the
fixit, but if it is a fixit on a warning, then obviously the AST
should be for the code as-written.
llvm-svn: 159980
Chris pointed out that while the comparison is certainly problematic
and does not have well-defined behavior, it isn't any worse than some
of the other abuses that we merely warn about and doesn't need to make
the compilation fail.
Revert the release notes change (r159766) now that this is just a new warning.
llvm-svn: 159939
This may turn out to be a controversial change, due to string literals being
uniqued at link time, but Apple's docs only say "The compiler makes such
object constants unique on a per-module basis..."[1] without actually saying
what a "module" is. (It's not a clang module.) Furthermore, this uniqueness
guarantee often can't be guaranteed once the string has been passed through
framework code.
If this does turn out very controversial, we could downgrade this to a
DefaultError warning for strings, and leave it as a true Error for other
kinds of literals.
(<rdar://problem/11300873>)
[1]: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Strings/Articles/CreatingStrings.html
llvm-svn: 159766
is selected. This will allow more flexibility when converting diagnostics to
use template type diffing.
Also updated the internal manual and test cases for correctly keeping the bold
attribute and for tree printing.
llvm-svn: 159463
This adds support for the tls_model attribute. This allows the user to
choose a TLS model that is better than what LLVM would select by
default. For example, a variable might be declared as:
__thread int x __attribute__((tls_model("initial-exec")));
if it will not be used in a shared library that is dlopen'ed.
This depends on LLVM r159077.
llvm-svn: 159078
override whether headers are system headers by checking for prefixes of the
header name specified in the #include directive.
This allows warnings to be disabled for third-party code which is found in
specific subdirectories of include paths.
llvm-svn: 158418
Remove the instructions on manually adding boilerplate code of AttributeList::Kind and AttributeList::getKind().
Both are now generated by tblgen.
llvm-svn: 158386
-Wsometimes-uninitialized diagnostics to make it clearer that the cause
of the issue may be a condition which must always evaluate to true or
false, rather than an uninitialized variable.
To emphasize this, add a new note with a fixit which removes the
impossible condition or replaces it with a constant.
Also, downgrade the diagnostic from -Wsometimes-uninitialized to
-Wconditional-uninitialized when it applies to a range-based for loop,
since the condition is not written explicitly in the code in that case.
llvm-svn: 157511
cases in switch statements. Also add a [[clang::fallthrough]] attribute, which
can be used to suppress the warning in the case of intentional fallthrough.
Patch by Alexander Kornienko!
The handling of C++11 attribute namespaces in this patch is temporary, and will
be replaced with a cleaner mechanism in a subsequent patch.
llvm-svn: 156086
<stdatomic.h> header.
In passing, fix LanguageExtensions to note that C11 and C++11 are no longer
"upcoming standards" but are now actually standardized.
llvm-svn: 154513
- Developers of system frameworks need a way for their framework to be treated as a "system framework" during development. Otherwise, they are unable to properly test how their framework behaves when installed because of the semantic changes (in warning behavior) applied to system frameworks.
llvm-svn: 154105
last N months. This required a brief soliloquy about change in
an uncertainly-versioned world.
I believe I've gotten the right target versions on all these changes.
llvm-svn: 153501
between unscoped enumerations and class template member specializations,
whose behavior is currently under discussion in CWG (and for which there
is a preference to not implement the currently-standardized wording).
llvm-svn: 153464
that provides the behavior of the C++11 library trait
std::is_trivially_constructible<T, Args...>, which can't be
implemented purely as a library.
Since __is_trivially_constructible can have zero or more arguments, I
needed to add Yet Another Type Trait Expression Class, this one
handling arbitrary arguments. The next step will be to migrate
UnaryTypeTrait and BinaryTypeTrait over to this new, more general
TypeTrait class.
Fixes the Clang side of <rdar://problem/10895483> / PR12038.
llvm-svn: 151352
This option was added in r129614 and doesn't have any use case that I'm aware
of. It's possible that external tools are using these names - and if that's
the case we can certainly reassess the functionality, but for now it lets us
shave out a few unneeded bits from clang.
Move the "StaticDiagNameIndex" table into the only remaining consumer, diagtool.
This removes the actual diagnostic name strings from clang entirely.
Reviewed by Chris Lattner & Ted Kremenek.
llvm-svn: 150612
address safety analysis (such as e.g. AddressSanitizer or SAFECode) for a specific function.
When building with AddressSanitizer, add AddressSafety function attribute to every generated function
except for those that have __attribute__((no_address_safety_analysis)).
With this patch we will be able to
1. disable AddressSanitizer for a particular function
2. disable AddressSanitizer-hostile optimizations (such as some cases of load widening) when AddressSanitizer is on.
llvm-svn: 148842
the release notes despite their awesomeness. If we had a thorough
discussion of the performance of Clang in 2.9 vs. 3.0, the first would
be more relevant, but we don't. The serialization stuff hopefully isn't
terribly visible to end users.
Objections to these omissions are of course welcome. =]
llvm-svn: 145336
accurate than my original notes were based on IRC conversations. Windows
folks, please edit as needed to make this closer to the truth if I've
still got it wrong.
llvm-svn: 145309
add a bit to that section about the many bug-finding warnings that Clang
has grown since 2.9 as this is one of the more visible new additions.
llvm-svn: 145307
stub for OpenCL work. I can't really dig enough out of the commit log
messages other than to tell that a lot of work went into this in the 2.9
-> 3.0 timeframe. I'll let the folks touching it decide if it merits
a spot in the release notes and provide the appropriate details if so.
llvm-svn: 145291
easier. Move the CUDA bits and the C1X/C++11 atomics stuff there. We
haven't exposed a __has_feature for the atomic builtins, so none of this
is available yet...
llvm-svn: 145288
The performance improvement was committed after the 3.0 branch.
Constructors/destructors are handled by the CFG, but we do not do anything
special for them in the analyzer yet.
Since we do not have an open source release qualification for the analyzer,
we are not investing into creating the proper release notes for it.
llvm-svn: 145281
worth noting in the release notes. These remain raw notes. I'll be
re-writing them into nice prose first thing tomorrow, with help from
others. A couple of notes for any reading the commits:
If you don't see something that should be mentioned, feel free to add
a note (or even a nicely written section) about it! I haven't really
done the static analyzer justice here as I don't really know what the
significant changes are other than mile-high stuff like watching it grow
C++ support and a more robust CFG. I also worry I've missed important
stuff in the Objective-C world.
If you see something that isn't worth mentioning, just delete it. I know
there are several things like this. I plan to prune the list down as
I flesh things out.
If you're name or email is on a bullet, I'll likely be sending you an
email asking for any input on that subject. For many of these I can fill
in something generic, and I'll just want you to give it a once-over.
However, if you have time, feel free to just write the blurb yourself
and drop it in, or drop it in an email to me.
Finally, *WOW* has a lot happened in Clang... I shouldn't have dreaded
(and put off) this so much, it was kind of awesome to go back and watch
the evolution. Anyways, these should be in a reasonable draft state
early tomorrow.
llvm-svn: 145247
these more detailed notes from the primary LLVM release notes for Clang.
This gives us a nice place to flesh out in plenty of detail the major
changes that have happened in Clang land since 2.9.
I've outlined a very rough structure based on the LLVM release notes
structure and what seems like useful divisions in the Clang landscape
(e.g., language-specific stuff is relevant to a narrower audience).
I'll be first converting my brain-dump-ish notes from the commit logs,
and then cleaning here. Suggestions on structure welcome. Typo
corrections, spelling fixes (oh how I'll need them), all welcome; just
commit away.
llvm-svn: 145233
- This disables the system include directories, but not the compiler builtin
directories. Useful for projects that want to use things like the intrinsic
headers, but are otherwise freestanding.
- I'm willing to reconsider the option naming, I also considered providing an
explicit -builtinc (which would match -nobuiltininc), but this is more
consistent with existing options.
llvm-svn: 141692
to operate "as if" in a certain working directory.
- For now, we just implement this by changing the actual working directory, but
eventually we would want to handle this transparently. This is useful to
avoid an extra exec() pair in some situations, and will be something we would
want to support for more flexibility in using the Clang libraries.
llvm-svn: 140409
'id' that can be used (only!) via a contextual keyword as the result
type of an Objective-C message send. 'instancetype' then gives the
method a related result type, which we have already been inferring for
a variety of methods (new, alloc, init, self, retain). Addresses
<rdar://problem/9267640>.
llvm-svn: 139275
This patch special cases the parser for thread safety attributes so that all
attribute arguments are put in the argument list (instead of a special
parameter) since arguments may not otherwise resolve correctly without two-token
lookahead.
This patch also adds checks to make sure that attribute arguments are
lockable objects.
llvm-svn: 137130
Introduce and document a new objc_returns_inner_pointer
attribute, and consume it by performing a retain+autorelease
on message receivers when they're not immediately loaded from
an object with precise lifetime.
llvm-svn: 135764
One weird thing is the addition of several <a name=""> tags where
previously there were id attributes on the <h3> tags. This is because
the id attribute must begin with a letter, not an underscore. The name
attribute is not so constrained, so links will continue to work.
llvm-svn: 133677
Adrian Prantl