deprecation attribute ('deprecated', 'availability' or 'unavailable').
This warning is under a separate flag, -Wdocumentation-deprecated-sync, so it
can be turned off easily while leaving other -Wdocumentation warnings on.
llvm-svn: 164467
The issue is that we were calling clang_getCompletionBriefComment
unconditionally. New we check if this function is available before calling it.
llvm-svn: 164464
FunctionDecl that we are importing the FunctionProtoType for, in which case we'll have
infinite recursion when importing.
Initially create a FunctionProtoType with null ExceptionSpecDecl/ExceptionSpecTemplate and
update the type in ASTNodeImporter::VisitFunctionDecl after the FunctionDecl has been created.
llvm-svn: 164450
This is a heuristic intended to greatly reduce the number of false
positives resulting from inlining, particularly inlining of generic,
defensive C++ methods that live in header files. The suppression is
triggered in the cases where we ask to track where a null pointer came
from, and it turns out that the source of the null pointer was an inlined
function call.
This change brings the number of bug reports in LLVM from ~1500 down to
around ~300, a much more manageable number. Yes, some true positives may
be hidden as well, but from what I looked at the vast majority of silenced
reports are false positives, and many of the true issues found by the
analyzer are still reported.
I'm hoping to improve this heuristic further by adding some exceptions
next week (cases in which a bug should still be reported).
llvm-svn: 164449
Before, PathDiagnosticConsumers that did not support actual path output
would (sensibly) cause the generation of the full path to be skipped.
However, BugReporterVisitors may want to see the path in order to mark a
BugReport as invalid.
Now, even for a path generation scheme of 'None' we will still create a
trimmed graph and walk backwards through the bug path, doing no work other
than passing the nodes to the BugReporterVisitors. This isn't cheap, but
it's necessary to properly do suppression when the first path consumer does
not support path notes.
In the future, we should try only generating the path and visitor-provided
path notes once, or at least only creating the trimmed graph once.
llvm-svn: 164447
This is intended to allow visitors to make decisions about whether a
BugReport is likely a false positive. Currently there are no visitors
making use of this feature, so there are no tests.
When a BugReport is marked invalid, the invalidator must provide a key
that identifies the invaliation (intended to be the visitor type and a
context pointer of some kind). This allows us to reverse the decision
later on. Being able to reverse a decision about invalidation gives us more
flexibility, and allows us to formulate conditions like "this report is
invalid UNLESS the original argument is 'foo'". We can use this to
fine-tune our false-positive suppression (coming soon).
llvm-svn: 164446
Rather than saying "Null pointer value stored to 'foo'", we now say
"Passing null pointer value via Nth parameter 'foo'", which is much better.
The note is also now on the argument expression as well, rather than the
entire call.
This paves the way for continuing to track arguments back to their sources.
<rdar://problem/12211490>
llvm-svn: 164444
Like with struct fields, we want to catch cases like this early,
so that we can produce better diagnostics and path notes:
PointObj *p = nil;
int *px = &p->_x; // should warn here
*px = 1;
llvm-svn: 164442
We want to catch cases like this early, so that we can produce better
diagnostics and path notes:
Point *p = 0;
int *px = &p->x; // should warn here
*px = 1;
llvm-svn: 164441
fatal error. Previously, if a fatal error was followed by a diagnostic which
was suppressed due to a SFINAETrap, we'd forget that we'd seen a fatal error.
llvm-svn: 164437
This makes the wording more informative, and consistent with the other
warnings about uninitialized variables.
Also, me and David who reviewed this couldn't figure out why we would
need to do a lookup to get the name of the variable; so just print the
name directly.
llvm-svn: 164366
external visible decls, call DeclContext::setMustBuildLookupTable so that the
"lazy decls" bit of the LookupPtr is set.
Previously, in non-C++, if there were no new declarations causing the "lazy decls" bit
to be set, then DeclContext::lookups_begin() would fail to return the decls from the PCH.
Fixes rdar://12316296.
llvm-svn: 164351
The expression based expansion too often results in IR level optimizations
splitting the intermediate values into separate basic blocks, preventing
the formation of the VBSL instruction as the code author intended. In
particular, LICM would often hoist part of the computation out of a loop.
rdar://11011471
llvm-svn: 164342
their implementations are unavailable. Start by simulating dispatch_sync().
This change is largely a bunch of plumbing around something very simple. We
use AnalysisDeclContext to conjure up a fake function body (using the
current ASTContext) when one does not exist. This is controlled
under the analyzer-config option "faux-bodies", which is off by default.
The plumbing in this patch is largely to pass the necessary machinery
around. CallEvent needs the AnalysisDeclContextManager to get
the function definition, as one may get conjured up lazily.
BugReporter and PathDiagnosticLocation needed to be relaxed to handle
invalid locations, as the conjured body has no real source locations.
We do some primitive recovery in diagnostic generation to generate
some reasonable locations (for arrows and events), but it can be
improved.
llvm-svn: 164339
but can be dereferenced to form an expression which does have viable begin/end
functions, then typo-correct the range, even if something else goes wrong with
the statement (such as inaccessible begin/end or the wrong type of loop
variable).
In order to ensure we recover correctly and produce any followup diagnostics in
this case, redo semantic analysis on the for-range statement outside of the
diagnostic trap, after issuing the typo-correction.
llvm-svn: 164323
This test behavior differs depending (at least) on whether
sizeof(wchar_t) == sizeof(int) or not.
When they are equal, the first redeclaration will fail because decltype(+L'x')
is unsigned int instead of the expected int. This occurs on ARM.
llvm-svn: 164315
While it might be nice to have a quick end-to-end sanity test, it's just not
really the right place for it & would require more work to enable lit to
provide a detection flag ("XFAIL: cross" or similar) than the value we get from
having this test. Early on it might've made more sense, but these days we've
got some pretty good coverage across the stack with more targeted tests.
llvm-svn: 164314
This is some really old code (took me a while to find the test cases) & the
diagnostic text is slightly incorrect (it should really only apply to
re/declarations/, redefinitions are an error regardless of whether the types
match). Not sure if anyone cares about it, though.
For now this just makes the diagnostic more clear in less obvious cases where
the type of a declaration might not be explicitly written (eg: because it
uses decltype)
llvm-svn: 164313
- Inputs/system-header-simulator.h: Declare strlen() with size_t.
- malloc-interprocedural.c: Move the definition of size_t into the header above.
Then XFAIL can be pruned.
llvm-svn: 164300
By changing the conversion operator into a conversion constructor, we
can enabled based on the template parameters leading to better error
messages. E.g.: stmt(decl()) will now create an error message including:
note: candidate function not viable: no known conversion from
'clang::ast_matchers::internal::BindableMatcher<clang::Decl>' to 'const
clang::ast_matchers::internal::Matcher<clang::Stmt>' for 1st argument
llvm-svn: 164298
If someone provides their own function called 'strdup', or 'reallocf', or
even 'malloc', and we inlined it, the inlining should have given us all the
malloc-related information we need. If we then try to attach new information
to the return value, we could end up with spurious warnings.
<rdar://problem/12317671>
llvm-svn: 164276
While we definitely want this optimization in the future, we're not
currently handling constraints on symbolic /expressions/ correctly.
These should stay live even if the SymExpr itself is no longer referenced
because could recreate an identical SymExpr later. Only once the SymExpr
can no longer be recreated -- i.e. a component symbol is dead -- can we
safely remove the constraints on it.
This liveness issue is tracked by <rdar://problem/12333297>.
This reverts r163444 / 24c7f98828e039005cff3bd847e7ab404a6a09f8.
llvm-svn: 164275
clang has recently started to warn about the enum compares:
lib/Serialization/ASTWriter.cpp:2760:31: warning: comparison of literal 256 with expression of type
'clang::DeclarationName::NameKind' is always true [-Wtautological-constant-out-of-range-compare]
llvm-svn: 164220
definition info; it needs to be there because the mangler needs to
access it before we're finished defining the lambda class.
PR12808.
llvm-svn: 164186
The Freescale SDK is based on OpenEmbedded, and this might be useful
for other OpenEmbedded-based configurations as well.
With minor modifications, patch by Tobias von Koch!
llvm-svn: 164177
This makes Clang warn about self references in in-class initializers,
for example:
struct S {
int a = a + 42;
};
This basically just moves UninitializedFieldVisitor up a bit in
SemaDeclCXX.cpp, and adds a call to it from ActOnCXXInClassMemberInitializer.
llvm-svn: 164131
Without this patch, the isDerivedFrom matcher asserts in the
"assert(ClassDecl != NULL);" in the new test, as a
DependentTemplateSpecilizationType is not a sub-type of
TemplateSpecializationType and also does not offer getAsCXXRecordDecl().
I am not sure why this did not cause problems before. It is now (after
the changed implementation of isDerivedFrom) easier to write a matcher
that actually gets into this branch of the code.
llvm-svn: 164127
Having Expr-subclass-matchers being VariadicDynCast-Expr-matchers does
not provide additional type safety and just makes using them harder. In
the clang AST, expressions are always statements and an expression
matcher can be used anywhere, a statement matcher is expected. Any given
matcher definition still has at least one noun.
llvm-svn: 164121
start of a statement or the end of a compound-statement, diagnose the comma as
a typo for a semicolon. Patch by Ahmed Bougacha! Additional test cases and
minor refactoring by me.
llvm-svn: 164085
is no compelling argument that this is a generally useful warning,
and imposes a strong stylistic argument on code beyond what it was
intended to find warnings in.
llvm-svn: 164083
in ObjCMethods.
Extend FunctionTextRegion to represent ObjC methods as well as
functions. Note, it is not clear what type ObjCMethod region should
return. Since the type of the FunctionText region is not currently used,
defer solving this issue.
llvm-svn: 164046
Retain cycles happen in the case where a block is persisted past its
life on the stack, and the way that occurs is by copying the block.
We should thus look through any explicit copies we see.
Note that Block_copy is actually a type-safe wrapper for _Block_copy,
which does all the real work.
<rdar://problem/12219663>
llvm-svn: 164039
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
Specifically, this should warn:
__block block_t a = ^{ a(); };
Furthermore, this case which previously warned now does not, since the value
of 'b' is captured before the assignment occurs:
block_t b; // not __block
b = ^{ b(); };
(This will of course warn under -Wuninitialized, as before.)
<rdar://problem/11015883>
llvm-svn: 163962
bytes of the buffer and not the size of the string, otherwise we
may overwrite the buffer if there is a mismatch between the size
of the string and the CharByteWidth, and assertions are disabled.
The bug where this could occur was fixed in r163931.
Related to rdar://12069503
llvm-svn: 163939
type checking for non-static data member initializers in a dependent
class, because our ASTs lose too much information to when
type-checking an initializer. Fixes <rdar://problem/11974632>,
although the result is still rather unsatisfactory.
llvm-svn: 163871
TypeSourceInfo, we may have lost some adjustments made to the type of
that function due to declaration merging. Adjust the resulting type
correspondingly. Fixes PR12948 / <rdar://problem/11552434>.
llvm-svn: 163845
it is not possible to guarantee that without duplicating logic or buffering
<Discussion> element contents. So, allow empty <Discussion> elements in schema.
llvm-svn: 163842
integral promotions to both its underlying type and to its underlying type's
promoted type. This matters now that boolean conversions aren't permitted in
converted constant expressions (a la DR1407): an enumerator with a fixed
underlying type of bool still can be.
llvm-svn: 163841
should be fine to use it without further explanations in the attached
paragraph, so the warning about empty paragraph was turned off for it.
llvm-svn: 163836
warning to an error. C++ bans it, and both GCC and EDG diagnose it as
an error. Microsoft allows it, so we still warn in Microsoft
mode. Fixes <rdar://problem/11135644>.
llvm-svn: 163831
middle of UTF-8 characters, and avoid walking to such positions when adjusting
column ranges for display. Fixes a couple of hangs when rendering diagnostics.
llvm-svn: 163820
crazy case where dispatch_once gets redefined as a macro that calls
_dispatch_once (which calls the real dispatch_once). Users want to
see the warning in their own code.
Fixes <rdar://problem/11617767>
llvm-svn: 163816
passing -fretain-comments-from-system-headers. By default, the
compiler no longer parses such documentation comments, as they
can result in a noticeable compile time/PCH slowdown.
Fixes <rdar://problem/11860820>.
llvm-svn: 163778
Objective-C related to NSException.
Fixes <rdar://problem/12287498>
I debated whether or not this logic should be sunk into the CFG
itself. It's not clear if we should, as different analyses may
wish to have different policies. We can re-evaluate this in the
future.
llvm-svn: 163760
in NSException to a helper object in libAnalysis that can also
be used by Sema. Not sure if the predicate name 'isImplicitNoReturn'
is the best one, but we can massage that later.
No functionality change.
llvm-svn: 163759
more robust way to address a few FIXMEs.
The initial implementation, r163342, built the IR asm string and then tried to
patch things on the fly without enough context. Specifically, it didn't skip
mnemonics nor did it track with assembly instruction an expression was related
to. The new implementation patches the operands and then builds the final
IR string.
llvm-svn: 163756
Make clang emit a flag for DW_AT_object_pointer for the artificial
args where it should (implicit first arguments). FileCheck-ize a
test as well and update tests to take into account the object
pointer flag.
rdar://9797999
llvm-svn: 163755
static Qualifiers removeCommonQualifiers(Qualifiers &L, Qualifiers &R)
Removes the common qualifiers from L and R and returns them in a new Qualifier.
This will be used in template diffing.
void removeQualifiers(Qualifiers Q)
Removes the qualifiers in Q from the current qualifier.
This replaces the current underlying implementation of operator- and
operator -= which only performed bit masking.
llvm-svn: 163752
Rafael Espindola