has inconsistent ownership with the backing ivar, point the error location to the
ivar.
Pointing to the ivar (instead of the @synthesize) is better since this is where a fix is needed.
Also provide the location of @synthesize via a note.
This also fixes the problem where an auto-synthesized property would emit an error without
any location.
llvm-svn: 170039
Add -fslp-vectorize (with -ftree-slp-vectorize as an alias for gcc compatibility)
to provide a way to enable the basic-block vectorization pass. This uses the same
acronym as gcc, superword-level parallelism (SLP), also common in the literature,
to refer to basic-block vectorization.
Nadav suggested this as a follow-up to the adding of -fvectorize.
llvm-svn: 169909
a file or directory, allowing just a stat call if a file descriptor
is not needed.
Doing just 'stat' is faster than 'open/fstat/close'.
This has the effect of cutting down system time for validating the input files of a PCH.
llvm-svn: 169831
definition, rather than at the end of the definition of the set of nested
classes. We still defer checking of the user-specified exception specification
to the end of the nesting -- we can't check that until we've parsed the
in-class initializers for non-static data members.
llvm-svn: 169805
the cases where we can't determine whether special members would be trivial
while building the class, we eagerly declare those special members. The impact
of this is bounded, since it does not trigger implicit declarations of special
members in classes which merely *use* those classes.
In order to determine whether we need to apply this rule, we also need to
eagerly declare move operations and destructors in cases where they might be
deleted. If a move operation were supposed to be deleted, it would instead
be suppressed, and we could need overload resolution to determine if we fall
back to a trivial copy operation. If a destructor were implicitly deleted,
it would cause the move constructor of any derived classes to be suppressed.
As discussed on cxx-abi-dev, C++11's selected constructor rules are also
retroactively applied as a defect resolution in C++03 mode, in order to
identify that class B has a non-trivial copy constructor (since it calls
A's constructor template, not A's copy constructor):
struct A { template<typename T> A(T &); };
struct B { mutable A a; };
llvm-svn: 169673
Remove pre-standard restriction on explicitly-defaulted copy constructors with
'incorrect' parameter types, and instead just make those special members
non-trivial as the standard requires.
This required making CXXRecordDecl correctly handle classes which have both a
trivial and a non-trivial special member of the same kind.
This also fixes PR13217 by reimplementing DiagnoseNontrivial in terms of the
new triviality computation technology.
llvm-svn: 169667
directive as a macro expansion.
This is more of a "macro reference" than a macro expansion but it's close enough
for libclang's purposes. If it causes issues we can revisit and introduce a new
kind of cursor.
llvm-svn: 169666
properly, rather than faking it up by pretending that a reference member makes
the default constructor non-trivial. That leads to rejects-valids when putting
such types inside unions.
llvm-svn: 169662
with -Werror. Previously, compiling with -Werror would emit only the first
warning in a compilation unit, because clang assumes that once an error occurs,
further analysis is unlikely to return valid results. However, warnings that
have been upgraded to errors should not be treated as "errors" in this sense.
llvm-svn: 169649
top level.
This heuristic is already turned on for non-ObjC methods
(inlining-mode=noredundancy). If a method has been previously analyzed,
while being inlined inside of another method, do not reanalyze it as top
level.
This commit applies it to ObjCMethods as well. The main caveat here is
that to catch the retain release errors, we are still going to reanalyze
all the ObjC methods but without inlining turned on.
Gives 21% performance increase on one heavy ObjC benchmark, which
suffered large performance regressions due to ObjC inlining.
llvm-svn: 169639
This is the case where the analyzer tries to print out source locations
for code within a synthesized function body, which of course does not have
a valid source location. The previous fix attempted to do this during
diagnostic path pruning, but some diagnostics have pruning disabled, and
so any diagnostic with a path that goes through a synthesized body will
either hit an assertion or emit invalid output.
<rdar://problem/12657843> (again)
llvm-svn: 169631
Thanks for reminding me about copy-elision, David. Passing references here
doesn't help when we could get move construction in C++11. If we really
cared, we'd use std::swap to steal the reference from the temporary arg,
but it's probably not /that/ critical outside of Profile anyway.
llvm-svn: 169570
Suggested by David Blaikie. ExplodedNode, CallEvent, and CheckerContext all
hang onto their ProgramState, so the accessors can return a reference to the
internal state rather than preemptively copying it. This helps avoid
temporary ProgramStateRefs, though local variables will still (correctly)
do an extra retain and release.
llvm-svn: 169563
that were already parsed in the same "indexing session".
An indexing session is defined as using the same CXIndexAction object
for multiple clang_indexSourceFile calls.
Passing CXIndexOpt_SkipParsedBodiesInSession as an indexing option will
enable the mode where we try to skip bodies that were already parsed in
another translation unit.
If a function's body was skipped, the "flags" field in the CXIdxDeclInfo
structure will have "CXIdxDeclFlag_Skipped" bit was set.
llvm-svn: 169539
This feature was probably intended to improve diagnostics, but was currently
only used when dumping the Environment. It shows what location a given value
was loaded from, e.g. when evaluating an LValueToRValue cast.
llvm-svn: 169522
diagnostic from the emission of macro backtraces. Incidentally, we now get the
displayed source location for a diagnostic and the location for the caret from
the same place, rather than computing them separately. No functionality change.
llvm-svn: 169357
As the analysis improves, it will continue to add new warnings that are
potentially disruptive to existing users. From now on, such warnings will
first be introduced under the "beta" flag. Such warnings are not turned on by
default; their purpose is to allow users to test their code against future
planned changes, before those changes are actually made. After a suitable
migration period, beta warnings will be folded into the standard
-Wthread-safety.
llvm-svn: 169338
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
PreprocessingRecord and into its own class, PPConditionalDirectiveRecord.
Decoupling allows a client to use the functionality of PPConditionalDirectiveRecord
without needing a PreprocessingRecord.
llvm-svn: 169229
the output size is greater than the register size. No truncation occurs with
those. Reword warning to make it clearer what's the problem is.
llvm-svn: 169054
module, provide a module import stack similar to what we would get for
an include stack, e.g.,
In module 'DependsOnModule' imported from build-fail-notes.m:4:
In module 'Module' imported from DependsOnModule.framework/Headers/DependsOnModule.h:1:
Inputs/Module.framework/Headers/Module.h:15:12: note: previous definition is here
@interface Module
<rdar://problem/12696425>
llvm-svn: 169042
building module 'Foo' imported from..." notes (the same we we provide
"In file included from..." notes) in the diagnostic, so that we know
how this module got included in the first place. This is part of
<rdar://problem/12696425>.
llvm-svn: 169021
If 'x' is a temporary, x.getAs<Foo>() may not be safe if the result is
supposed to persist (if its address is stored somewhere). Since getAs()
can return a null value, the result is almost always stored into a
variable, which of course is not safe when the original value dies.
This has caused several bugs with GCC's "Temporaries May Vanish Sooner Than
You Expect" optimization; in C++11 builds, at least, we'll be able to catch
these problems now.
I would suggest applying these to other getAs() and get*As() methods
(castAs is "better" because sometimes the result is used directly, which
means the temporary will still be live), but these two have both caused
trouble in the analyzer in the past.
llvm-svn: 168967
import of that module elsewhere, don't try to build the module again:
it won't work, and the experience is quite dreadful. We track this
information somewhat globally, shared among all of the related
CompilerInvocations used to build modules on-the-fly, so that a
particular Clang instance will only try to build a given module once.
Fixes <rdar://problem/12552849>.
llvm-svn: 168961
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
Among other differences, GCC accepts
typedef int IA[];
typedef int A10[10];
static A10 *f(void);
static IA *f(void);
void g(void) {
(void)sizeof(*f());
}
but clang used to reject it with:
invalid application of 'sizeof' to an incomplete type 'IA' (aka 'int []')
The intention of c99's 6.2.7 seems to be that we should use the composite type
and accept as gcc does.
Doing the type merging required some extra fixes:
* Use the type from the function type in initializations, even if an parameter
is available.
* Fix the merging of the noreturn attribute in function types.
* Make CodeGen handle the fact that an parameter type can be different from
the corresponding type in the function type.
llvm-svn: 168895
performed, to determine whether that special member is deleted or constexpr.
That overload resolution process can in turn trigger the instantiation of a
template, which can do anything, including triggering the declaration of that
very same special member function. When this happens, do not try to recursively
declare the special member -- that's impossible. Instead, only try to realise
the truth. There is no special member.
llvm-svn: 168847
in deciding a copy/dispose field is needed in a byref structure
and when generating the copy/dispose helpers. In certain
cases, these fields were being added but no copy/dispose was
being generated. This was uncovered in ARC, but not in MRR.
// rdar://12759433
llvm-svn: 168825
constructor/assignment operator with a const-qualified parameter type. The
prior method for determining this incorrectly used overload resolution.
llvm-svn: 168775
allocated using the allocator associated with an ASTContext.
Use this inside CXXRecordDecl::DefinitionData instead of an UnresolvedSet to
avoid a potential memory leak.
rdar://12761275
llvm-svn: 168771
a special member" diagnostic from warning to error, and fix the cases where it
produced diagnostics with incorrect wording.
We don't support this as an extension, and we ban it even in C++98 mode. This
breaks too much (for instance, the ABI-specified calling convention for a type
can change if it acquires a copy constructor through the addition of a default
argument).
llvm-svn: 168769
r128056 moved PrettyStackTraceParserEntry construction from Parser.h
to ParseAST.cpp, so there's no need to keep this class in a header.
llvm-svn: 168731
This change list implemented logic that explicitly detects several combinations of locations where C++11 attribute
specifiers might be incorrectly placed within a class specifier. Previously we emit generic diagnostics like
"expected identifier" for such cases; now we emit specific diagnostic against the misplaced attributes, this also
fixed a bug in old code where attributes appear at legitimate locations were incorrectly rejected.
Thanks to Richard Smith for reviewing!
llvm-svn: 168626
and defined within the current instantiation, but which are not part of the
current instantiation. Previously, it would look at bases which could be
specialized separately from the current template.
llvm-svn: 168477
Previously, this flag to CC1 was never exposed at the clang driver
layer, and if you happened to enable it (by being on Android or GCC 4.7
platform), you couldn't *disable* it, because there was no 'no' variant.
The whole thing was confusingly implemented.
Now, the target-specific flag processing gets the driver arg list, and
we use standard hasFlag with a default based on the GCC version and/or
Android platform. The user can still pass the 'no-' variant to forcibly
disable the flag, or pass the positive variant to clang itself to enable
the flag.
The test has also been substantially cleaned up and extended to cover
these use cases.
llvm-svn: 168473
There were numerous issues here that were all entangled, and so I've
tried to do a general simplification of the logic.
1) The logic was mimicing actual GCC bugs, rather than "features". These
have been fixed in trunk GCC, and this fixes Clang as well. Notably,
the logic was always intended to be last-match-wins like any other
flag.
2) The logic for handling '-mdynamic-no-pic' was preposterously unclear.
It also allowed the use of this flag on non-Darwin platforms where it
has no actual meaning. Now this option is handled directly based on
tests of how llvm-gcc behaves, and it is only supported on Darwin.
3) The APIs for the Driver's ToolChains had the implementation ugliness
of dynamic-no-pic leaking through them. They also had the
implementation details of the LLVM relocation model flag names
leaking through.
4) The actual results of passing these flags was incorrect on Darwin in
many cases. For example, Darwin *always* uses PIC level 2 if it uses
in PIC level, and Darwin *always* uses PIC on 64-bit regardless of
the flags specified, including -fPIE. Darwin never compiles in PIE
mode, but it can *link* in PIE mode.
5) Also, PIC was not always being enabled even when PIE was. This isn't
a supported mode at all and may have caused some fallout in builds
with complex PIC and PIE interactions.
The result is (I hope) cleaner and clearer for readers. I've also left
comments and tests about some of the truly strage behavior that is
observed on Darwin platforms. We have no real testing of Windows
platforms and PIC, but I don't have the tools handy to figure that out.
Hopefully others can beef up our testing here.
Unfortunately, I can't test this for every platform. =/ If folks have
dependencies on these flags that aren't covered by tests, they may
break. I've audited and ensured that all the changes in behavior of the
existing tests are intentional and good. In particular I've tried to
make sure the Darwin behavior (which is more suprising than the Linux
behavior) also matches that of 'gcc' on my mac.
llvm-svn: 168297
With this, ARCMT tests would not crash on certain hosts with g++ -O2, eg. cygwin g++-4.5.3.
r160404 crashed mingw32-g++-4.4.0. I guess method's pointer in conditional expression could not be handled.
llvm-svn: 168295
common LexStringLiteral function. In doing so, some consistency problems have
been ironed out (e.g. where the first token in the string literal was lexed
with macro expansion, but subsequent ones were not) and also an erroneous
diagnostic has been corrected.
LexStringLiteral is complemented by a FinishLexStringLiteral function which
can be used in the situation where the first token of the string literal has
already been lexed.
llvm-svn: 168266
Separate out the notions of 'has a trivial special member' and 'has a
non-trivial special member', and use them appropriately. These are not
opposites of one another (there might be no special member, or in C++11 there
might be a trivial one and a non-trivial one). The CXXRecordDecl predicates
continue to produce incorrect results, but do so in fewer cases now, and
they document the cases where they might be wrong.
No functionality changes are intended here (they will come when the predicates
start producing the right answers...).
llvm-svn: 168119
This allows us to properly remove dead bindings at the end of the top-level
stack frame, using the ReturnStmt, if there is one, to keep the return value
live. This in turn removes the need for a check::EndPath callback in leak
checkers.
This does cause some changes in the path notes for leak checkers. Previously,
a leak would be reported at the location of the closing brace in a function.
Now, it gets reported at the last statement. This matches the way leaks are
currently reported for inlined functions, but is less than ideal for both.
llvm-svn: 168066
to a cc1 -fencode-extended-block-signature and pass it
to cc1 and recognize this option to produce extended block
type signature. // rdar://12109031
llvm-svn: 168063
more sense anyway - it determines how expressions are codegen'd. It also ensures
that -ffp-contract=fast has the intended effect when compiling LLVM IR.
llvm-svn: 168027
We do this by using the "most recent" good location: if a synthesized
function 'A' calls another function 'B', the path notes for the call to 'B'
will be placed at the same location as the path note for calling 'A'.
Similarly, the call to 'A' will have a note saying "Entered call from...",
and now we just don't emit that (since the user doesn't have a body to look
at anyway).
Previously, we were doing this for the "Calling..." notes, but not for the
"Entered call from..." or "Returning to caller". This caused a crash when
the path entered and then exiting a call within a synthesized body.
<rdar://problem/12657843>
llvm-svn: 168019
working with preprocessed testcases. This causes source locations in
diagnostics to point at the spelling location instead of the presumed location,
while still keeping the semantic effects of the line directives (entering and
leaving system-header mode, primarily).
llvm-svn: 168004
pointer, otherwise we will double free it when ExpressionEvaluationContextRecord
gets copied.
Fixes crash in rdar://12645424 & http://llvm.org/PR14252
llvm-svn: 167946
the related comma pasting extension.
In certain cases, we used to get two diagnostics for what is essentially one
extension. This change suppresses the first diagnostic in certain cases
where we know we're going to print the second diagnostic. The
diagnostic is redundant, and it can't be suppressed in the definition
of the macro because it points at the use of the macro, so we want to
avoid printing it if possible.
The implementation works by detecting constructs which look like comma
pasting at the time of the definition of the macro; this information
is then used when the macro is used. (We can't actually detect
whether we're using the comma pasting extension until the macro is
actually used, but we can detecting constructs which will be comma
pasting if the varargs argument is elided.)
<rdar://problem/12292192>
llvm-svn: 167907
This corrects the mangling and linkage of classes (& their member functions) in
cases like this:
struct foo {
struct {
void func() { ... }
} x;
};
we were accidentally giving this nested unnamed struct 'no' linkage where it
should've had the linkage of the outer class. The mangling was incorrecty too,
mangling as TU-wide unnamed type mangling of $_X rather than class-scoped
mangling of UtX_.
This also fixes -Wunused-member-function which would incorrectly diagnose
'func' as unused due to it having no linkage & thus appearing to be TU-local
when in fact it might be correctly used in another TU.
Similar mangling should be applied to function local classes in similar cases
but I've deferred that for a subsequent patch.
Review/discussion by Richard Smith, John McCall, & especially Eli Friedman.
llvm-svn: 167906
positions of Objective-C methods.
It is possible to recover a lot of type information about
Objective-C methods from the reflective metadata for their
implementations. This information is not rich when it
comes to struct types, however, and it is not possible to
produce a type in the debugger's round-tripped AST which
will really do anything useful during type-checking.
Therefore we allow __unknown_anytype in these positions,
which essentially disables type-checking for that argument.
We infer the parameter type to be the unqualified type of
the argument expression unless that expression is an
explicit cast, in which case it becomes the type-as-written
of that cast.
rdar://problem/12565338
llvm-svn: 167896
applied to CXXRecordDecls, where functions with that return type will
inherit the warn_unused_result attribute.
Also includes a tiny fix (with no discernable behavior change for
existing code) to re-sync AttributeDeclKind enum and
err_attribute_wrong_decl_type with warn_attribute_wrong_decl_type since
the enum is used with both diagnostic messages to chose the correct
description.
llvm-svn: 167783
The 'a', 'c', and 'd' constraints on i386 mean a 32-bit register. We cannot
place a 64-bit value into the 32-bit register. Error out instead of causing the
compiler to spew general badness.
<rdar://problem/12415959>
llvm-svn: 167717
When recursively visiting the generated matches, the aggregated bindings need
to be copied during the recursion. Otherwise, we they might not be properly
overwritten (which is shown by the test), or there might be bound nodes present
that were bound on a different matching branch.
Review: http://llvm-reviews.chandlerc.com/D112
llvm-svn: 167695
Richard Smith