support.

Caveat: Other than the existing segmented stacks support, no
claims are made of this working.

llvm-svn: 178744

Revert r177948.  We decided that we do not want ObjC property redeclarations to inherit "deprecated".

llvm-svn: 178743

keep the call at the current location.

llvm-svn: 178741

This mostly reverts 178733, but keeps the tests.

I don't claim to understand how hidden sub modules work or when we need to see
them (is that documented?), but this has the same semantics and avoids adding
hasExternalLinkageUncached which has the same foot gun potential as the old
hasExternalLinkage.

Last but not least, not computing linkage when it is not needed is more
efficient.

llvm-svn: 178739

llvm-svn: 178736

This test was exactly the opposite of what it should be. We should check if
there old decl has linkage (where it makes sense) and if the new decl has
the extern keyword.

llvm-svn: 178735

caching the linkage for a declaration before we set up its redeclaration chain,
when determining whether a declaration could be a redeclaration of something
from an unimported submodule. We actually want to look at the declaration as if
it were not a redeclaration here, so compute the linkage but don't cache it.

llvm-svn: 178733

of a property just in case the property's getter happens to be +1.
We won't synthesize a getter for such a property, but we will allow
the user to define a +1 method for it.
rdar://13115896

llvm-svn: 178731

ARC optimizer while they're held in local unsafe buffers.

Based on a patch by Jesse Rusak!

rdar://13573224

llvm-svn: 178721

llvm-svn: 178720

llvm-svn: 178716

Normal name lookup ignores any hidden declarations. When name lookup
for builtin declarations fails, we just synthesize a new
declaration at the point of use. With modules, this could lead to
multiple declarations of the same builtin, if one came from a (hidden)
submodule that was later made visible. Teach name lookup to always
find builtin names, so we don't create these redundant declarations in
the first place.

llvm-svn: 178711

don't serialize a lookup map for the translation unit outside C++ mode, so we
can't tell when lookup within the TU needs to look within modules. Only apply
the fix outside C++ mode, and only to the translation unit.

llvm-svn: 178706

Improvement of r178684 and r178685.

Jordan has pointed out that I should not rely on the value of the condition to know which expression branch
has been taken. It will not work in cases the branch condition is an unknown value (ex: we do not track the constraints for floats).
The better way of doing this would be to find out if the current node is the right or left successor of the node
that has the ternary operator as a terminator (which is how this is done in other places, like ConditionBRVisitor).

llvm-svn: 178701

Don't bother looking for parameter index of 'B' token if 'A' is not a parameter.

llvm-svn: 178699

declaration.  Patch by Stephen Lin!

llvm-svn: 178698

The lifetime of a temporary can be extended when it is immediately bound
to a local reference:

  const Value &MyVal = Value("temporary");

In this case, the temporary object's lifetime is extended for the entire
scope of the reference; at the end of the scope it is destroyed.

The analyzer was modeling this improperly in two ways:
- Since we don't model temporary constructors just yet, we create a fake
  temporary region when it comes time to "materialize" a temporary into
  a real object (lvalue). This wasn't taking base casts into account when
  the bindings being materialized was Unknown; now it always respects base
  casts except when the temporary region is itself a pointer.
- When actually destroying the region, the analyzer did not actually load
  from the reference variable -- it was basically destroying the reference
  instead of its referent. Now it does do the load.

This will be more useful whenever we finally start modeling temporaries,
or at least those that get bound to local reference variables.

<rdar://problem/13552274>

llvm-svn: 178697

As they are relevant on both Mac and iOS.

llvm-svn: 178687

This also allows us to ensure IDC/return null suppression gets triggered in such cases.

llvm-svn: 178686

llvm-svn: 178685

1) Look for the node where the condition expression is live when checking if
it is constrained to true or false.

2) Fix a bug in ProgramState::isNull, which was masking the problem. When
the expression is not a symbol (,which is the case when it is Unknown) return
unconstrained value, instead of value constrained to “false”!
(Thankfully other callers of isNull have not been effected by the bug.)

llvm-svn: 178684

Thanks Jordan!

llvm-svn: 178683

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

Looks like it broke http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb

Revert "Don't compute a patched/semantic storage class."

This reverts commit 8f187f62cb0487d31bc4afdfcd47e11fe9a51d05.

llvm-svn: 178681

rewriting typedef for a qualified object type
and also when two declarations happen to be on the
same line. // rdar://13562505

llvm-svn: 178680

Syntactically means the function macro parameter names do not need to use the same
identifiers in order for the definitions to be considered identical.

Syntactic equivalence is a microsoft extension for macro redefinitions and we'll also
use this kind of comparison to check for ambiguous macros coming from modules.

rdar://13562254

llvm-svn: 178671

llvm-svn: 178670

smarts so that it doesn't approve of keywords and/or type names when it
knows (based on its flags) that those kinds of corrections are not
wanted.

llvm-svn: 178668

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 combines several related changes:
a) Don't break before after the variable types in for loops with a
   single variable.
b) Better indent DeclStmts defining multiple variables.

Before:
bool aaaaaaaaaaaaaaaaaaaaaaaaa =
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaa),
     bbbbbbbbbbbbbbbbbbbbbbbbb =
         bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb(bbbbbbbbbbbbbbbb);
for (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
         aaaaaaaaaaa = aaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaa;
     aaaaaaaaaaa != aaaaaaaaaaaaaaaaaaa; ++aaaaaaaaaaa) {
}

After:
bool aaaaaaaaaaaaaaaaaaaaaaaaa =
         aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaa),
     bbbbbbbbbbbbbbbbbbbbbbbbb =
         bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb(bbbbbbbbbbbbbbbb);
for (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaa =
         aaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaa;
     aaaaaaaaaaa != aaaaaaaaaaaaaaaaaaa; ++aaaaaaaaaaa) {
}

llvm-svn: 178641

Summary:
It turns out that we don't need to store CommentsBeforeNextToken in the
line state, but rather flush them before we start parsing preprocessor
directives. This fixes wrong comment indentation in code blocks in macro calls
(the test is included).

Reviewers: klimek

Reviewed By: klimek

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D617

llvm-svn: 178638

llvm-svn: 178632

llvm-svn: 178631

No functional changes.

llvm-svn: 178626

[modules] If a submodule has re-definitions of the same macro, only the last definition will be used as the "exported" one.

Fixes rdar://13562262

llvm-svn: 178622

Thanks to Argyrios for the pointer.

llvm-svn: 178616

llvm-svn: 178613

expressions are integer.  It can also be ValueDecl expressions

Use the type information from the TemplateParameterList instead

Patch by Olivier Goffart!

llvm-svn: 178611

When support was added for declaration arguments, the case of variadic
declaration arguments was not supported.  This patch fixes that problem by
not crashing when certain ValueDecl's are null.

Patch by Olivier Goffart!

llvm-svn: 178610

Value depenedent expressions for default arguments cannot be evaluated.
Instead, use the desugared template type to get an argument expression that
can be used.  This is needed for both integer and declaration arguements.

Also, move this common code into a separate function.

Patch by Olivier Goffart!

llvm-svn: 178609