initialization of wchar_t arrays with wide strings, and generalizes
wchar_size.c to work on all targets.

llvm-svn: 65586

Unfortunately this doesn't work yet because wchar_t is completely
broken in C.

llvm-svn: 65585

llvm-svn: 65582

nicely sugared type that shows how the user wrote the actual
specialization. This sugared type won't actually show up until we
start doing instantiations.

llvm-svn: 65577

know how to recover from an error, we can attach a hint to the
diagnostic that states how to modify the code, which can be one of:

  - Insert some new code (a text string) at a particular source
    location
  - Remove the code within a given range
  - Replace the code within a given range with some new code (a text
    string)

Right now, we use these hints to annotate diagnostic information. For
example, if one uses the '>>' in a template argument in C++98, as in
this code:

  template<int I> class B { };
  B<1000 >> 2> *b1;

we'll warn that the behavior will change in C++0x. The fix is to
insert parenthese, so we use code insertion annotations to illustrate
where the parentheses go:

test.cpp:10:10: warning: use of right-shift operator ('>>') in template
argument will require parentheses in C++0x
  B<1000 >> 2> *b1;
         ^
    (        )


Use of these annotations is partially implemented for HTML
diagnostics, but it's not (yet) producing valid HTML, which may be
related to PR2386, so it has been #if 0'd out.

In this future, we could consider hooking this mechanism up to the
rewriter to actually try to fix these problems during compilation (or,
after a compilation whose only errors have fixes). For now, however, I
suggest that we use these code modification hints whenever we can, so
that we get better diagnostics now and will have better coverage when
we find better ways to use this information.

This also fixes PR3410 by placing the complaint about missing tokens
just after the previous token (rather than at the location of the next
token).

llvm-svn: 65570

 - No functionality change.

llvm-svn: 65563

Fix <rdar://problem/6574319> clang issues error on 'readonly' property with a defaul setter attribute.

Needed to make isPropertyReadonly() non-const (for this fix to compile). I imagine there's a way to retain the const-ness, however I have more important fish to fry.

llvm-svn: 65562

This was a fairly recent regression.

llvm-svn: 65547

The code for looking up local/private method in Sema::ActOnInstanceMessage() was not handling categories properly. Sema::ActOnClassMessage() didn't have this bug.
Created a helper with the correct logic and changed both methods to use it.

llvm-svn: 65532

llvm-svn: 65529

anymore.  If we want to reuse bits and pieces to add strict checking for 
constant initializers, we can dig them out of SVN history; the existing 
code won't be useful as-is.

llvm-svn: 65502

variable declarations where applicable.  Also, a few fixes to 
TryToFixInvalidVariablyModifiedType for issues that this exposed.

llvm-svn: 65500

decls. Test and document the semantic location of class template
specialization definitions that occur within a scope enclosing the
scope of the class template.

llvm-svn: 65478

specializations. In particular:

  - Make sure class template specializations have a "template<>"
    header, and complain if they don't.
  - Make sure class template specializations are declared/defined
    within a valid context. (e.g., you can't declare a specialization
    std::vector<MyType> in the global namespace).

llvm-svn: 65476

  std::vector<int>::allocator_type

When we parse a template-id that names a type, it will become either a
template-id annotation (which is a parsed representation of a
template-id that has not yet been through semantic analysis) or a
typename annotation (where semantic analysis has resolved the
template-id to an actual type), depending on the context. We only
produce a type in contexts where we know that we only need type
information, e.g., in a type specifier. Otherwise, we create a
template-id annotation that can later be "upgraded" by transforming it
into a typename annotation when the parser needs a type. This occurs,
for example, when we've parsed "std::vector<int>" above and then see
the '::' after it. However, it means that when writing something like
this:

  template<> class Outer::Inner<int> { ... };

We have two tokens to represent Outer::Inner<int>: one token for the
nested name specifier Outer::, and one template-id annotation token
for Inner<int>, which will be passed to semantic analysis to define
the class template specialization.

Most of the churn in the template tests in this patch come from an
improvement in our error recovery from ill-formed template-ids.

llvm-svn: 65467

llvm-svn: 65461

only from a function definition (that does not have a prototype) are
only used to determine the compatible with other declarations of that
same function. In particular, when referencing the function we pretend
as if it does not have a prototype. Implement this behavior, which
fixes PR3626.

llvm-svn: 65460

Sema::CheckAssignmentConstraints; not really visible, but the right 
thing to do.

llvm-svn: 65428

llvm-svn: 65401

string size as an argument.

llvm-svn: 65400

llvm-svn: 65399

llvm-svn: 65398

llvm-svn: 65397

llvm-svn: 65396

llvm-svn: 65395

to SemaInit.cpp, no functionality change.

llvm-svn: 65394

The big difference here is that (like string literal) @encode has 
array type, not pointer type.

llvm-svn: 65391

llvm-svn: 65389

lookup to skip over names without linkage. This finishes
<rdar://problem/6127293>.

llvm-svn: 65386

external declarations to also support external variable
declarations. Unified the code for these two cases into two new
subroutines.

Note that we fail to diagnose cases like the one Neil pointed
out, where a visible non-external declaration hides an external
declaration by the same name. That will require some reshuffling of
name lookup.

llvm-svn: 65385

that declaration to global scope so that it can be found from other
scopes. This allows us to diagnose redeclaration errors for external
declarations across scopes. We also warn when name lookup finds such
an out-of-scope declaration. This is part of <rdar://problem/6127293>;
we'll also need to do the same thing for variables.

llvm-svn: 65373

  - When we are declaring a function in local scope, we can merge with
    a visible declaration from an outer scope if that declaration
    refers to an entity with linkage. This behavior now works in C++
    and properly ignores entities without linkage.
  - Diagnose the use of "static" on a function declaration in local
    scope.
  - Diagnose the declaration of a static function after a non-static
    declaration of the same function.
  - Propagate the storage specifier to a function declaration from a
    prior declaration (PR3425)
  - Don't name-mangle "main"

llvm-svn: 65360

assertion when the ivars and method list was reset into the existing
interface.  To fix this, mark decls as invalid when they are redefined,
and don't insert ivars/methods into invalid decls.

llvm-svn: 65340

- Generate error for protocol qualifiers on non-ObjC types.

llvm-svn: 65333

Remove support for "Class<P>". Will be making this an error.

llvm-svn: 65332

I don't think casting super makes any sense (since it won't effect method lookup).
Will discuss with other offline and decide what to do.

llvm-svn: 65317

Sema::ActOnInstanceMessage(): Tighen up the lookup rules for handling messages to 'Class'. Also improve "super" handling.

llvm-svn: 65300

llvm-svn: 65293

Contains the following (related to problems found while investigting <rdar://problem/6497631> Message lookup is sometimes different than gcc's).

- Implement instance/class overloading in ObjCContainerDecl (removing a FIXME). This involved hacking NamedDecl::declarationReplaces(), which took awhile to figure out (didn't realize replace was the default).
- Changed Sema::ActOnInstanceMessage() to remove redundant warnings when dealing with protocols. For now, I've omitted the "protocol" term in the diagnostic. It simplifies the code flow and wan't always 100% accurate (e.g. "Foo<Prot>" looks in the class interface, not just the protocol).
- Changed several test cases to jive with the above changes.

llvm-svn: 65292

helper isConstantInitializer) to check whether an initializer is 
constant.  This passes tests, but it's possible that it'll cause 
regressions with real-world code.

Future work:
1. The diagnostics obtained this way are lower quality at the moment; 
some work both here and in Evaluate is needed for accurate diagnostics.
2. We probably need some extra code when we're in -pedantic mode so we 
can strictly enforce the rules in C99 6.6p7.
3. Dead code cleanup (this should wait until after 2, because we might 
want to re-use some of the code).

llvm-svn: 65265