llvm-svn: 140478

Also make sure we set the error flag when correcting a typo.

llvm-svn: 140466

llvm-svn: 140462

cannot be converted.
This is in preparation for overload resolution of initializer lists.
Currently, you will always get this message when you try to pass an init
list to an overloaded function.

llvm-svn: 140461

the information on to Sema. There's still an incorrectness in the way template instantiation
works now, but that is due to a far larger underlying representational problem.
Also add a test case for various list initialization cases of scalars, which test this
commit as well as the previous one.

llvm-svn: 140460

Allow empty initializer lists for scalars, which mean value-initialization.
Constant evaluation for single-element and empty initializer lists for scalars.
Codegen for empty initializer lists for scalars.
Test case comes in next commit.

llvm-svn: 140459

builds a semantic (structured) initializer list, just reports on whether it can match
the given list to the target type.
Use this mode for doing init list checking in the initial step of initialization, which
will eventually allow us to do overload resolution based on the outcome.

llvm-svn: 140457

resolves to a constructor call in C++11) and failure kind
FK_ListInitializationFailed (early InitListChecker run failed).

llvm-svn: 140456

llvm-svn: 140455

llvm-svn: 140454

[microsoft] In Microsoft mode, if we are inside a template class member function and we can't resolve an identifier then assume the identifier is type dependent. The goal is to postpone name lookup to instantiation time to be able to search into type dependent base classes.

This fixes a few errors when parsing MFC code with clang.
BTW clang trunk is now about 5 patches away to be able the parse the default wizard-generated MFC project.

llvm-svn: 140452

must match property type declaration in its
primary class. // rdar://10142679

llvm-svn: 140438

followed by it implementation crashes when attempt
is made to access the synthesized ivar. 
// rdar://10177744

llvm-svn: 140432

llvm-svn: 140407

merging for overrides. One might want to make a method's availability
in a superclass different from that of its subclass. Fixes
<rdar://problem/10166223>.

llvm-svn: 140406

is cast to a boolean.  An exception has been made for string literals in
logical expressions to allow the common case of use in assert statements.

bool x;
x = "hi";  // Warn here
void foo(bool x);
foo("hi");  // Warn here
assert(0 && "error");
assert("error);  // Warn here

llvm-svn: 140405

the key function is inline, rather than the original
declaration. Perhaps FunctionDecl::isInlined() is poorly named. Fixes
<rdar://problem/9979458>. 

llvm-svn: 140400

llvm-svn: 140367

constructor template. Fixes PR10457.

llvm-svn: 140350

generation when we're dealing with an implicitly-defined copy or move
constructor. And, actually set the implicitly-defined bit for
implicitly-defined constructors and destructors. Should fix self-host.

llvm-svn: 140334

Use ASTTemplateArgumentListInfo instead.

llvm-svn: 140331

ever. Fixes PR10939.

llvm-svn: 140304

OpenCL 6.2.1 says: "Implicit conversions between built-in vector data types are
disallowed."  OpenCL 6.2.2 says: "Explicit casts between vector types are not
legal."  For example:

uint4 u = (uint4)(1);
int4 i = u; // invalid implicit conversion
int4 e = (int4)u; // invalid explicit conversion

Fixes PR10967. Submitted by: Anton Lokhmotov <Anton.lokhmotov@gmail.com>

llvm-svn: 140300

llvm-svn: 140293

llvm-svn: 140290

OpenCL is different from AltiVec in the way it supports vector literals.  OpenCL
is strict with regards to semantic checks.  For example, implicit conversions
and explicit casts between vectors of different types are disallowed.

Fixes PR10975. Submitted by: Anton Lokhmotov <Anton.lokhmotov@gmail.com>

llvm-svn: 140270

llvm-svn: 140268

Dyatkovskiy! Fixes PR10896.

llvm-svn: 140250

conversions (rather than just call-arguments).

llvm-svn: 140244

[microsoft] Move missing typename warning from -fms-extensions to -fms-compatibility. Also allow the missing typename warning at function scope.

llvm-svn: 140240

  assert(!"error message");

To:

  assert(0 && "error message");

which is more consistant across the code base.

llvm-svn: 140232

llvm-svn: 140212

llvm-svn: 140189

from unfriendly (== not at all modularized) directories. This is
temporary, and it only affects module construction until I'll figured
out how to deal with system headers.

llvm-svn: 140159

Per John's review comments for r140068.

llvm-svn: 140142

of false positive warnings that depend on noreturn destructors pruning
the CFGs, but only in C++0x mode!

This was really surprising as the debugger quickly reveals that the
attributes are parsed correctly (and using the same code) in both modes.
The warning fires in the same way in both modes. But between parsing and
building the destructor declaration with the noreturn attribute and the
warning, it magically disappears. The key? The 'noexcept' appears!

When we were rebuilding the destructor type with the computed implicit
noexcept we completely dropped the old type on the floor. This almost
makes sense (as the arguments and return type to a destructor aren't
exactly unpredictable), but lost any function type attributes as well.
The fix is simple, we build the new type off of the old one rather than
starting fresh.

Testing this is a bit awkward. I've done it by running the
noreturn-sensitive tests in both modes, which previous failed and now
passes, but if anyone has ideas about how to more specifically and
thoroughly test that the extended info on a destructor is preserved when
adding noexcept, I'm all ears.

llvm-svn: 140138

Add list initialization for complex numbers in C.  Essentially, this allows "_Complex float x = {1.0f, 2.0f};".  See changes to docs/LanguageExtensions.html for a longer description.

<rdar://problem/9397672>.

llvm-svn: 140090

llvm-svn: 140068

It already works (and is useful with) macro locs as well.

llvm-svn: 140057

llvm-svn: 140031