two types in different AST contexts are equivalent. Rather than
transforming the type from one context into the other context, we
perform a deep structural comparison of the types. This change
addresses a serious problem with recursive data types like
struct ListNode {
int value;
struct ListNode *Next;
} xList;
llvm-svn: 96278
those declared in it. This is to allow duplicate
property diagnostics for properties declared in class extensions
multiple times (radar 7629420) and for future use.
llvm-svn: 96276
of operating on each code decl. This exposes two flaws in AnalysisConsumer
that should eventually be fixed:
(1) It is not possible to associate multiple "actions" with a single
command line argument. This will require the notion of an
"analysis" group, and possibly tablegen support. (although eventually
we want to support dynamically loading analyses as well)
(2) AnalysisConsumer may not actually be scanning the declarations in namespaces.
We'll experiment first in LLVMConventionsChecker before changing the
behavior in AnalysisConsumer.
llvm-svn: 96183
Currently these checks are intended to be largely syntactical, but may get more
sophisticated over time.
As an initial foray into this brave new world, emit a static analyzer warning
when binding a temporary 'std::string' to an 'llvm::StringRef' where the
lifetime of the 'std::string' does not outlive the 'llvm::StringRef'.
llvm-svn: 96147
(1) Since CXXMethodDecl subclasses FunctionDecl (and CXXDestructorDecl
and CXXConversion subclass CXXMethodDecl), refactor switch statement
to handle them all in one spot.
(2) Use 'DeclarationName::getAsString()' to handle all functions that
don't have simple identifiers (fixing a null dereference when scanning
for specific functions).
llvm-svn: 96146
or that's been hidden by a non-type (in C++).
The ideal C++ diagnostic here would note the hiding declaration, but this
is a good start.
llvm-svn: 96141
rebuilding a typename type terminating in a template-id (with
dependent template name, naturally) as a TypenameType when, because
its context could be fully resolved, we should have been building it
as a QualifiedNameType. Fixes PR6268.
llvm-svn: 96084
to the driver, and support it in CodeGenOptsToArgs(). Note that this changes
the default behavior of clang -cc1 to always run the verifier.
llvm-svn: 96077
we'd add an offset from the spelling location space to the
instantiation location, which doesn't make sense and would
lead up to the text diagnostics crashing when presented with
non-sensical locations.
This fixes rdar://7597492, a crash on 255.vortex.
llvm-svn: 96004
worth asserting about in this code: 1) if the source range
is bogus (begin loc after end loc), and 2) if the client
is trying to highlight a range that is purely whitespace.
It is possible to just silently ignore #2, but it seems like
it is always a bug, so lets keep asserting on this condition,
but with a better assert message.
llvm-svn: 95998
guard macro is already defined for the first occurrence of the
header. If it is, the body will be skipped and not be properly
analyzed for the include guard optimization.
llvm-svn: 95972
headers, where malloc (and many other libc functions) are declared
with empty throw specifications, e.g.,
extern void *malloc (__SIZE_TYPE__ __size) throw () __attribute__
((__malloc__)) ;
The C++ standard doesn't seem to allow this, and redeclaring malloc as
the standard permits (as follows) resulted in Clang (rightfully!)
complaining about mis-matched exception specifications.
void *malloc(size_t size);
We work around this by silently propagating an empty throw
specification "throw()" from a function with C linkage declared in a
system header to a redeclaration that has no throw specifier.
Ick.
llvm-svn: 95969
order of constructor arguments (all block API specific). This was exposed only in
a large block literal expression in a large file where PtrSet container size
execceded its limit and required reallocation. Fixes radar 7638294
llvm-svn: 95936
variable type, we can (and should) still check for completeness of the
variable's type. Do so, to work around an assertion that shows up in
Boost's shared_ptr.
llvm-svn: 95934
incompatibility and show where the structural differences are. For
example:
struct1.c:36:8: warning: type 'struct S7' has incompatible definitions
in different translation units
struct S7 { int i : 8; unsigned j : 8; } x7;
^
struct1.c:36:33: note: bit-field 'j' with type 'unsigned int' and length 8 here
struct S7 { int i : 8; unsigned j : 8; } x7;
^
struct2.c:33:33: note: bit-field 'j' with type 'unsigned int' and length 16 here
struct S7 { int i : 8; unsigned j : 16; } x7;
^
There are a few changes to make this work:
- ASTImporter now has only a single Diagnostic object, not multiple
diagnostic objects. Otherwise, having a warning/error printed via
one Diagnostic and its note printed on the other Diagnostic could
cause the note to be suppressed.
- Implemented import functionality for IntegerLiteral (along with
general support for statements and expressions)
llvm-svn: 95900
their spelling location. This prevents warnings from being swallowed just
because the caret is on the first parenthesis in, say, NULL.
This is an experiment; the risk is that there might be a substantial number
of system headers which #define symbols to expressions which inherently cause
warnings. My theory is that that's rare enough that it can be worked
around case-by-case, and that producing useful warnings around NULL is worth
it. But I'm willing to accept that I might be empirically wrong.
llvm-svn: 95870
Enhance the printf format string checking when using the format
specifier flags ' ', '0', '+' with the 'p' or 's' conversions (since
they are nonsensical and undefined). This is similar to GCC's
checking.
Also warning when a precision is used with the 'p' conversin
specifier, since it has no meaning.
llvm-svn: 95869
Right now, it's off by default but can be tested by passing -fdump-vtable-layouts to clang -cc1. This option will cause all vtables that will normally be emitted as part of codegen to also be dumped using the new layout code.
I've also added a very simple new vtable layout test case.
llvm-svn: 95865
array associated with NonNullAttr. This fixes yet another leak when
ASTContext uses a BumpPtrAllocator.
Fixes: <rdar://problem/7637150>
llvm-svn: 95863
storing the set of StoredDeclsMaps in an internal vector of void*.
This isn't an ideal solution, but for the time being this fixes a
major memory leak with these DenseMaps not being freed.
Fixes: <rdar://problem/7634755>
llvm-svn: 95861
array allocated using the allocator in ASTContext. This addresses
these strings getting leaked when using a BumpPtrAllocator (in
ASTContext).
Fixes: <rdar://problem/7636765>
llvm-svn: 95853
we would just leak them all over the place, with no clear ownership of
these objects at all. AttributeList objects would get leaked on both
error and non-error paths.
Note: I introduced the usage of llvm::OwningPtr<AttributeList> to
manage these objects, which is particularly useful for methods with
multiple return sites. In at least one method I used them even when
they weren't strictly necessary because it clarified the ownership
semantics and made the code easier to read. Should the excessive
'take()' and 'reset()' calls become a performance issue we can always
re-evaluate.
Note+1: I believe I have not introduced any double-frees, but it would
be nice for someone to review this.
This fixes <rdar://problem/7635046>.
llvm-svn: 95847
attribute, so it uses Anton's new target-specific attribute support. It's
supposed to ensure that the stack is 16-byte aligned, but since necessary
support is lacking from LLVM, this is a no-op for now.
llvm-svn: 95820
merged with variables of constant array types. Also, make sure that we
call DiagnosticClient's BeginSourceFile/EndSourceFile, so that it has
a LangOptions to work with.
llvm-svn: 95782
conversions. Fix an access-control bug where privileges were not considered
at intermediate points along the inheritance path. Prepare for friends.
llvm-svn: 95775
into another AST, including their include history. Here's an example
error that involves a conflict merging a variable with different types
in two translation units (diagnosed in the third AST context into
which everything is merged).
/Volumes/Data/dgregor/Projects/llvm/tools/clang/test/ASTMerge/Inputs/var2.c:3:5:
error: external variable 'x2' declared with incompatible types in
different translation units ('int' vs. 'double')
int x2;
^
In file included from
/Volumes/Data/dgregor/Projects/llvm/tools/clang/test/ASTMerge/Inputs/var1.c:3:
/Volumes/Data/dgregor/Projects/llvm/tools/clang/test/ASTMerge/Inputs/var1.h:1:8:
note: declared here with type 'double'
double x2;
^
Although we maintain include history, we do not maintain macro
instantiation history across a merge. Instead, we map down to the
spelling location (for now!).
llvm-svn: 95732
that we get readable diagnostics such as:
error: external variable 'x1' declared with incompatible types in
different translation units ('double *' vs. 'float **')
However, there is no translation of source locations, yet.
llvm-svn: 95704
This is a non-fragile-abi feature only. Since it
breaks existing code, it is currently placed under
-fobjc-nonfragile-abi2 option for test purposes only
until further notice. WIP.
llvm-svn: 95685
NULL, not the store, to determine if a lookup succeeded. The store
can be null if it contained no bindings. This fixes a false positive
reported to me by a user of the analyzer.
llvm-svn: 95679
Sema::ActOnUninitializedDecl over to InitializationSequence (with
default initialization), eliminating redundancy. More importantly, we
now check that a const definition in C++ has an initilizer, which was
an #if 0'd code for many, many months. A few other tweaks were needed
to get everything working again:
- Fix all of the places in the testsuite where we defined const
objects without initializers (now that we diagnose this issue)
- Teach instantiation of static data members to find the previous
declaration, so that we build proper redeclaration
chains. Previously, we had the redeclaration chain but built it
too late to be useful, because...
- Teach instantiation of static data member definitions not to try
to check an initializer if a previous declaration already had an
initializer. This makes sure that we don't complain about static
const data members with in-class initializers and out-of-line
definitions.
- Move all of the incomplete-type checking logic out of
Sema::FinalizeDeclaratorGroup; it makes more sense in
ActOnUnitializedDecl.
There may still be a few places where we can improve these
diagnostics. I'll address that as a separate commit.
llvm-svn: 95657
- This fixes many many more places than the test case, but my feeling is we need to audit alignment systematically so I'm not inclined to try hard to test the individual fixes in this patch. If this bothers you, patches welcome!
PR6240.
llvm-svn: 95648
At the moment the inlinehint attribute is ignored by the Inliner unless you
pass a -respect-inlinehint option. This will soon be the default.
The inlinehint attribute is set if the inline keyword is explicitly specified
on any declaration.
llvm-svn: 95623
non-type template parameter that has reference type, augment the
qualifiers of the non-type template argument with those of the
referenced type. Fixes PR6250.
llvm-svn: 95607
The standard actually says that such references should have internal linkage,
but gcc doesn't do that, so we probably can't get away with it.
llvm-svn: 95577
attribute properly and avoid bogus warning. This is
an objective-c fix only. objective-c++ follows different code
pass and requires separate fix (which will come at a later time).
Fixes radar 7214820.
llvm-svn: 95571
deduction. This requires refactoring the deduction to have access to the Sema
object instead of merely the ASTContext. Still leaves something to be desired
due to poor source location.
Fixes PR6257 and half of PR6259.
llvm-svn: 95528
Fariborz Jahanian