if the definition has a non-variadic prototype with compatible
parameters.  Therefore, the default rule for such calls must be to
use a non-variadic convention.  Achieve this by casting the callee to
the function type with which it is required to be compatible, unless
the target specifically opts out and insists that unprototyped calls
should use the variadic rules.  The only case of that I'm aware of is
the x86-64 convention, which passes arguments the same way in both
cases but also sets a small amount of extra information;  here we seek
to maintain compatibility with GCC, which does set this when calling
an unprototyped function.

Addresses PR10810 and PR10713.

llvm-svn: 140241

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

llvm-svn: 140240

[analyzer] Fix a bug where PathDiagnosticLocation did not generate a valid range and add asserts to check validity of locations early on. Ignore invalid ranges in PathDiagnosticPiece (they could be added by checker writers).

Addresses radar://10124836 and radar://radar10102244.

llvm-svn: 140218

llvm-svn: 140212

return a cursor for the inner macro.

llvm-svn: 140207

llvm-svn: 140189

erronously trigger the digraph correction fix-it.  Include a new test to catch
this in the future.

llvm-svn: 140175

llvm-svn: 140155

presence of an implicit move assignment operator.  I think the implicit
copy assignment operator case was also wrong, but just in a "displaying
the wrong diagnostic" way.

llvm-svn: 140139

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

check whether the requested location points inside the precompiled preamble,
in which case the returned source location will be a "loaded" one.

llvm-svn: 140060

inside a macro argument should be regarded as coming before
the location of the expanded tokens.

llvm-svn: 140053

This model uses the 'landingpad' instruction, which is pinned to the top of the
landing pad. (A landing pad is defined as the destination of the unwind branch
of an invoke instruction.) All of the information needed to generate the correct
exception handling metadata during code generation is encoded into the
landingpad instruction.

The new 'resume' instruction takes the place of the llvm.eh.resume intrinsic
call. It's lowered in much the same way as the intrinsic is.

llvm-svn: 140049

For instance:

template <class T> void E() {};
class F {};

void test() {
 ::E<::F>();
 E<::F>();
}

Gives the following error messages:

error: found '<::' after a template name which forms the
     digraph '<:' (aka '[') and a ':', did you mean '< ::'?
 ::E<::F>();
    ^~~
    < ::
error: expected expression
 E<::F>();
    ^
error: expected ']'
note: to match this '['
 E<::F>();

This patch adds the digraph fix-it check right before the name lookup,
moves the shared checking code to a new function, and adds new
tests to catch future regressions.

llvm-svn: 140039

Radar 10139522 - Part 1.

llvm-svn: 140038

We were failing to set source locations and ranges in isUnusedResultAWarning
for CXXOperatorCallExprs, leading to an "expression result unused" warning
with absolutely no context if the expression was inside a macro.

llvm-svn: 140036

instead of internal linkage.

llvm-svn: 140030

In constructors, don't generate implicit initializers for members of anonymous structs contained within anonymous unions.

llvm-svn: 140015

Move the "jump bypasses variable initialization" error -> warning downgrade from -fms-extensions to -fms-compatibility.

llvm-svn: 140008

In Microsoft mode(-fms-compatibility), prefer an integral conversion to a floating-to-integral conversion if the integral conversion is between types of the same size.

For example:
 void f(float);
 void f(int);
 int main {
    long a;
    f(a);
 }
Here, MSVC will call f(int) instead of generating a compile error as clang will do in standard mode.
This fixes a few errors when parsing MFC code with clang.

llvm-svn: 140007

has no effect since any such destructors must be trivial, and in C++11 such destructors must not
be called.

llvm-svn: 139997

mem-initializer is specified for them, unless an in-class initializer is specified.

llvm-svn: 139996

Fix PR10531. Attach an initializer to anonymous unions, since the default constructor might not be trivial (if there is an in-class initializer for some member) and might be deleted.

llvm-svn: 139991

Fixes PR10771.

llvm-svn: 139990

class of this method. // rdar://10109725

llvm-svn: 139989

is missing. // rdar//10127639

llvm-svn: 139988

the AST reader), merge that header file information with whatever
header file information we already have. Otherwise, we might forget
something we already knew (e.g., that the header was #import'd already).

llvm-svn: 139979

arbitrary amount of code. This forces us to stage the AST writer more
strictly, ensuring that we don't assign a declaration ID to a
declaration until after we're certain that no more modules will get
loaded.

llvm-svn: 139974

Also add a test case for the non Microsoft case because such test didn't exist.

llvm-svn: 139971

[analyzer] Refactor: make PathDiagnosticLocation responsible for validation of SourceLocations (commit 5 of ?):
 - Get rid of PathDiagnosticLocation(SourceRange r,..) constructor by providing a bunch of create methods.
 - The PathDiagnosticLocation(SourceLocation L,..), which is used by crate methods, will eventually become private.
 - Test difference is in the case when the report starts at the beginning of the function. We used to represent that point as a range of the very first token in the first statement. Now, it's just a single location representing the first character of the first statement.

llvm-svn: 139932

Without -ffreestanding, clang tries to seek /usr/include/stdlib.h in host filesystem, even on Windows hosts.

llvm-svn: 139899

llvm-svn: 139875

Tweak *mmintrin.h so that they don't make any bad assumptions about alignment (which probably has little effect in practice, but better to get it right).  Make the load in _mm_loadh_pi and _mm_loadl_pi a single LLVM IR instruction to make optimizing easier for CodeGen.

rdar://10054986

llvm-svn: 139874

#include or #import direcctives of framework headers into module
imports of the corresponding framework module.

llvm-svn: 139860

llvm-svn: 139838

instead of 'Class'.

llvm-svn: 139834

[analyzer] Refactor: make PathDiagnosticLocation responsible for validation of SourceLocations (commit 4 of ?):
 - The closing brace is always a single location, not a range.
 - The test case previously had a location key 57:1 followed by a range [57:1 - 57:1]. 

llvm-svn: 139832

When we load the first module, make sure that we wire up the ASTConsumer to the newly-created ASTReader. This makes sure that CodeGen sees the declarations it is interested in

llvm-svn: 139824