This matches the behavior for setters.
Also pass the class extension to ProcessPropertyDecl as the lexical DeclContext, even when not redeclaring the @property.
This fixes the remaining issues in <rdar://problem/7410145>.
llvm-svn: 114477
ObjCMethodDecls. Further, use the location of the new property declaration as the location of new ObjCMethodDecls
(if they didn't previously exist).
This fixes more of the issues reported in <rdar://problem/7410145>.
llvm-svn: 114456
- definitions of interfaces for CFGInitializer and CFGAutomaticObjDtor,
- support for above classes to print_elem function (renamed print_stmt),
- support for VarDecls in StmtPrinterHelper.
llvm-svn: 114403
message send, e.g.,
[[NSString alloc] initWithCString:<CC>
look up all of the possible methods and determine the preferred type
for the argument expression based on the type of the corresponding
parameter.
llvm-svn: 114379
Objective-C message sends. There is no functionality change here; this
is prep work for using the parameter types to help guide the
expression results when code-completing the argument.
llvm-svn: 114375
at the statement level or in Objective-C message receivers. Therefore,
just give types and declarations the same basic priority, and adjust
from there.
llvm-svn: 114374
statement context; it really isn't helpful in practice (remember
printf!) and we'll be doing other adjustments for statements very soon.
llvm-svn: 114358
- In Objective-C, we prefer BOOL to bool for historic reasons;
slightly penalize "bool".
- Treat Nil macro as a NULL pointer constant.
- Treat YES, NO, true, and false macros as constants.
- Treat the bool macro as a type.
llvm-svn: 114356
LHS and when conditional expression is an array. Since
it will be decayed, saved expression must be saved with
decayed expression. This is necessary to preserve semantics
of this extension (and prevent an IRGen crash which expects
an array to always be decayed). I am sure there will be other
cases in c++ (aggregate conditionals for example) when saving of the
expression must happen after some transformation on conditional
expression has happened.
Doug, please review. Fixes // rdar://8446940
llvm-svn: 114296
unless we're on a platform without __cxa_atexit (or use thereof has been
disabled). This patch actually just disables the check completely for
static locals, but I've filed http://llvm.org/bugs/show_bug.cgi?id=8176 to
track the platform-specific fix.
llvm-svn: 114269
of a binary expression, continue on and parse the right-hand side of
the binary expression anyway, but don't call the semantic actions to
type-check. Previously, we would see the error and then, effectively,
skip tokens until the end of the statement.
The result should be more useful recovery, both in the normal case
(we'll actually see errors beyond the first one in a statement), but
it also helps code completion do a much better job, because we do
"real" code completion on the right-hand side of an invalid binary
expression rather than completing with the recovery completion. For
example, given
x = p->y
if there is no variable named "x", we can still complete after the p->
as a member expression. Along the recovery path, we would have
completed after the "->" as if we were in an expression context, which
is mostly useless.
llvm-svn: 114225
This mainly prevents failures and/or crashes when multiple processes try to read/write the same PCH file. (rdar://8392711&8294781); suggestion & review by Daniel!
llvm-svn: 114187
the bases are completely initialized. This won't work --- base
initializer expressions can rely on the vtables having been set up.
Check for uses of 'this' in the initializers and force a vtable
initialization if found.
This might not be good enough; we might need to extend this to handle
the possibility of arbitrary code finding an external reference to this
(not yet completely-constructed!) object and accessing through it,
in which case we'll probably find ourselves doing a lot more unnecessary
stores.
llvm-svn: 114153
the GCC dir. Unfortunately, this breaks -lstdc++ on SnowLeopard, etc. because
the libstdc++ dylib was hiding there. Workaround this by providing the path to
the right -lstdc++.6 (the only version used in recent memory) if we can't see an
obvious -lstdc++, but can find = -lstdc++.6.
llvm-svn: 114146
the cleanup might not be dominated by the allocation code.
In this case, we have to store aside all the delete arguments
in case we need them later. There's room for optimization here
in cases where we end up not actually needing the cleanup in
different branches (or being able to pop it after the
initialization code).
Also make sure we only call this operator delete along the path
where we actually allocated something.
Fixes rdar://problem/8439196.
llvm-svn: 114145
-lstdc++. This is the best gross solution for a gross problem.
This issue is that historically, GCC has add -L options to its internally
library directories. This has allowed users and platforms to end up depending on
the layout of GCC's internal library directories.
We want to correct this mistake by eliminating that -L, but this means that
existing libraries which are in the GCC lib dir won't be found. We are going to
handle this by treating those -l names as "reserved", and requiring toolchains
to know how to add the right full path to the reserved library.
The immediately side effect of this is that users trying to use -L to find their
own -lstdc++ will need to start using -nostdlib (which is a good idea
anyway). Another side effect is that -stdlib=libc++ -lstdc++ will now do the
"right" thing, for curious definitions of right.
llvm-svn: 114144
prototype scope, temporarily set the context of the enumeration
declaration to the translation unit. We do the same thing for
parameters, until we have an actual function declaration on which to
hang them. Fixes <rdar://problem/8435682>.
There is more work to do in this area, since we have existing bugs
with tags being declared/defined in function parameter lists. This fix
is correct, and we'll end up extending it when we deal with those
existing bugs.
llvm-svn: 114135
with a non-default-stack-ABI-alignment (of 16).
- This fixes the ABI convenient, but breaks codegen since we now have
underaligned arguments. Marginal improvement overall though, and will be
fixed in next commit.
llvm-svn: 114113
missing the opening bracket '[', e.g.,
NSArray <CC>
at function scope. Previously, we would only give trivial completions
(const, volatile, etc.), because we're in a "declaration name"
scope. Now, we also provide completions for class methods of NSArray,
e.g.,
alloc
Note that we already had support for this after the first argument,
e.g.,
NSArray method:x <CC>
would get code completion for class methods of NSArray whose selector
starts with "method:". This was already present because we recover
as if NSArray method:x were a class message send missing the opening
bracket (which was committed in r114057).
llvm-svn: 114078
sends. These are far trickier than instance messages, because we
typically have something like
NSArray alloc]
where it appears to be a declaration of a variable named "alloc" up
until we see the ']' (or a ':'), and at that point we can't backtrace.
So, we use a combination of syntactic and semantic disambiguation to
treat this as a message send only when the type is an Objective-C type
and it has the syntax of a class message send (which would otherwise
be ill-formed).
llvm-svn: 114057
are expanded from macros (and if so, omit the warning). Previously we were just looking at the
location of the binary expression.
Fixes <rdar://problem/8435950>.
llvm-svn: 114044
narrow, almost useless case where we're inside a parenthesized
expression, e.g.,
(NSArray alloc])
The solution to the general case still eludes me.
llvm-svn: 114039
'[' is missing. Prior commits improving recovery also improved code
completion beyond the first selector, e.g., at or after the "to" in
calculator add:x to:y
but not after "calculator". We now provide the same completions for
calculator <CC>
that we would for
[calculator <CC>
if "calculator" is an expression whose type is something that can
receive Objective-C messages.
This code completion works for instance and super message sends, but not
class message sends.
llvm-svn: 113976
part of parser recovery. For example, given:
a method1:arg];
we detect after parsing the expression "a" that we have the start of a
message send expression. We pretend we've seen a '[' prior to the a,
then parse the remainder as a message send. We'll then give a
diagnostic+fix-it such as:
fixit-objc-message.m:17:3: error: missing '[' at start of message
send expression
a method1:arg];
^
[
The algorithm here is very simple, and always assumes that the open
bracket goes at the beginning of the message send. It also only works
for non-super instance message sends at this time.
llvm-svn: 113968
slot. The easiest way to do that was to bundle up the information
we care about for aggregate slots into a new structure which demands
that its creators at least consider the question.
I could probably be convinced that the ObjC 'needs GC' bit should
be rolled into this structure.
Implement generalized copy elision. The main obstacle here is that
IR-generation must be much more careful about making sure that exactly
llvm-svn: 113962
the index when the value evaluation isn't powerful enough. By creating ElementRegions with
UnknownVals as the index, this gives the false impression that they are the same element, when
they really aren't. This becomes really problematic when deriving symbols from these regions
(e.g., those representing the initial value of the index), since two different indices will
get the same symbol for their binding.
This fixes an issue with the idempotent operations checker that would cause two indices that
are clearly not the same to make it appear as if they always had the same value.
Fixes <rdar://problem/8431728>.
llvm-svn: 113920
expression, e.g., after the '(' that could also be a type cast. Here,
we provide types as code-completion results in C/Objective-C (C++
already had them), although we wouldn't in a normal expression context.
llvm-svn: 113904
library to use.
- This is currently useful for testing libc++; you can now use 'clang++
-stdlib=libc++ t.cpp' to compile using it if installed.
- In the future could also be used to select other standard library choices if
alternatives become available (for example, to use an alternate C library).
llvm-svn: 113891
"used", at the time that the default argument itself is used, also
mark destructors that will be called by this expression. This fixes a
regression that I introduced in r113700, which broke WebKit, and fixes
<rdar://problem/8427926>.
llvm-svn: 113883
that we're sure to keep it updated when new expression kinds
emerge. Also fixes a few little bugs in the classification of
expressions.
llvm-svn: 113864
placement 'operator delete', even if there are no placement args (i.e.
overload resolution selected an operator new with default arguments).
llvm-svn: 113861
The canonical FunctionTemplateDecl contains the specializations but we cannot use getCanonicalDecl on Template because it may still be initializing.
Write and read it from PCH.
Fixes http://llvm.org/PR8134
llvm-svn: 113744
sequences for two conversion functions when in fact we are in the text
of initialization by a user-defined conversion sequences. Fixes PR8034.
llvm-svn: 113724
error to a warning if we're in a case that would be allowed in
C++0x. This "fixes" PR8084 by making Clang accept more code than GCC
and (non-strict) EDG do.
Also, add the missing test case for the C++0x semantics, which should
have been in r113717.
llvm-svn: 113718
be a semantic requirement that a built-in overloaded operator is not
added to the overload set of there is already a user-defined
overloaded operator with the same parameter types. Fixes PR8087.
llvm-svn: 113713
declarations in potentially-evaluated subexpressions, about
recursion. Fixes the release-mode self-host failure I introduced in
r113700.
llvm-svn: 113708
used in the default function argument as "used". Instead, when we
actually use the default argument, make another pass over the
expression to mark any used declarations as "used" at that point. This
addresses two kinds of related problems:
1) We were marking some declarations "used" that shouldn't be,
because we were marking them too eagerly.
2) We were failing to mark some declarations as "used" when we
should, if the first time it was instantiated happened to be an
unevaluated context, we wouldn't mark them again at a later point.
I've also added a potentially-handy visitor class template
EvaluatedExprVisitor, which only visits the potentially-evaluated
subexpressions of an expression. I bet this would have been useful for
noexcept...
Fixes PR5810 and PR8127.
llvm-svn: 113700
preambles end up leaving the precompiled preambles around. This is by
design, since we do minimal cleanup during crash recovery. However,
it's unfortunate for testing, so introduce a hook that allows these
two tests to put the precompiled preamble somewhere where we can
delete them after testing.
llvm-svn: 113698
just abort creation of the precompiled preamble rather than doing
silly things. This is the second part of the fix for the weird
preamble-related failures on Windows. Big thanks to Francois Pichet
for the great detective work!
llvm-svn: 113697
Windows GetTempPath() function, and be sure to create the directory in
which the precompiled preamble will reside before creating the
temporary file itself.
llvm-svn: 113695
information when imported variable is used
more than once. Originally though to be a bug in importing
block varibles. Fixes radar 8417746.
llvm-svn: 113675
follows objective's semantics and is not overload'able
with an assignment operator. Fixes a crash and a missing
diagnostics. Radar 8379892.
llvm-svn: 113555
spelled (#pragma, _Pragma, __pragma). In -E mode, use that information
to add appropriate newlines when translating _Pragma and __pragma into
#pragma, like GCC does. Fixes <rdar://problem/8412013>.
llvm-svn: 113553
constructor, in source order. Also introduces a new reference kind for
class members, which is used here (for member initializers) and will
also be used for designated initializers and offsetof.
llvm-svn: 113545
explicit list for the C++ system include directories at the -cc1 level, as an
alternative to the horrible AddDefaultCPlusPlusIncludePaths().
llvm-svn: 113505
with comma-separated lists. We never actually used the comma
locations, nor did we store them in the AST, but we did manage to
waste time during template instantiation to produce fake locations.
llvm-svn: 113495
Another beating by boost in this test case: http://llvm.org/PR8117
A function specialization wasn't properly initialized if it wasn't canonical.
I wish there was a nice little test case but this was boost.
llvm-svn: 113481
this fixes all analyser test failures in my gcc34-based
environment
how the cast result could bind to the non-const ref is
somewhat mysterious and remains to be investigated; to
avoid similar miscompilations (by gcc34 only?)
llvm-svn: 113480
The end result is now we eagarly constant-fold symbols in the analyzer that are perfectly constrained
to be a constant value. This allows us to recover some path-sensitivity in some cases by lowering
the required level of reasoning power needed to evaluate some expressions.
The net win from this change is that the false positive in PR 8015 is fixed, and we also
find more idempotent operations bugs.
We do, however, regress with the BugReporterVisitors, which need to be modified to understand
this constant folding (and look past it). This causes some diagnostic regressions in plist-output.m
which will get addressed in a future patch. plist-output.m is now marked XFAIL, while
plist-output-alternate.m now tests that the plist output is working, but with the suboptimal
diagnostics. This second test file will eventually be removed.
llvm-svn: 113477
the function processing the format string can decided whether or not to accept a null format string (e.g., asl_log). Fixes <rdar://problem/8269537>.
llvm-svn: 113469
- Created private class CFGReachabilityAnalysis, which provides cached reachability lookups in the CFG
- Simplified PathWasCompletelyAnalyzed to use the new reachability class
- Added getLastRelevantNodes function for future use with path displaying in BugReporter
llvm-svn: 113465
to selectively walk successors/predecessors based on commonly used filters. For starters, add
a filter to ignore 'default:' cases for SwitchStmts when all enum values are covered by CaseStmts.
llvm-svn: 113449
covered by individual case statements. Flow-based analyses may wish to consult this information,
and recording this in the AST allows us to obviate reconstructing this information later when
we build the CFG.
llvm-svn: 113447
TreeTransform, since we were getting an empty source range where we
shouldn't. Sadly, the test case is Boost.Proto, and isn't worth
reducing.
llvm-svn: 113446
typeid expressions:
- make sure we have a proper source location for the closing ')'
- cache the declaration of std::type_info once we've found it
llvm-svn: 113441
function-style cast. Previously, we had a (redundant, incorrect)
semantic-checking path for non-class types, which allowed
value-initialization of a reference type and then crashed.
llvm-svn: 113415
PCH got a severe beating by the boost-using test case reported here: http://llvm.org/PR8099
Fix issues like:
-When PCH reading, make sure Decl's getASTContext() doesn't get called since a Decl in the parent hierarchy may be initializing.
-In ASTDeclReader::VisitFunctionDecl VisitRedeclarable should be called before using FunctionDecl's isCanonicalDecl()
-In ASTDeclReader::VisitRedeclarableTemplateDecl CommonOrPrev must be initialized before anything else.
llvm-svn: 113391
Fixes PR8110, and thus PR8109, PR8097, and parts of PR8101, PR8105 and PR8107. Only a few traits have tests for incomplete arrays, since I'm not yet clear what the result for them should be; Howards wants to file a DR to change the standard.
llvm-svn: 113326
block-literal initializer expression causes IRgen to crash.
This patch fixes by saving it in StaticLocalDecl map
already used for such purposes. (radar 8390455).
llvm-svn: 113307
Daniel Dunbar