llvm-svn: 140068

llvm-svn: 140066

PreprocessingRecord's getPreprocessedEntitiesInRange.

Also remove all the stuff that were added in ASTUnit that are unnecessary now
that we do a binary search for preprocessed entities and deserialize only
what is necessary.

llvm-svn: 140063

return iterators for local, non-loaded, preprocessed entities.

llvm-svn: 140062

instead of getLocation() since we don't care about expanded macro arguments.

llvm-svn: 140061

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

source location of line:col of a specific FileID.

llvm-svn: 140059

which will do a binary search and return a pair of iterators
for preprocessed entities in the given source range.

Source ranges of preprocessed entities are stored twice currently in
the PCH/Module file but this will be fixed in a subsequent commit.

llvm-svn: 140058

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

llvm-svn: 140057

depend on internal knowledge of SourceLocation.

llvm-svn: 140056

llvm-svn: 140055

llvm-svn: 140054

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

llvm-svn: 140053

don't call ReadSLocEntryRecord() directly because the entry may have
already been loaded in which case calling ReadSLocEntryRecord()
directly would trigger an assertion in SourceManager.

llvm-svn: 140052

points at the inclusion/expansion point of the other, regard this
as coming before the other.

llvm-svn: 140051

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

llvm-svn: 140031

instead of internal linkage.

llvm-svn: 140030

llvm-svn: 140022

llvm-svn: 140017

llvm-svn: 140016

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

llvm-svn: 140015

Remove function which is unused as of r139996. Thanks to David Blaikie for bringing this to my attention.

llvm-svn: 140013

Do not use builtin includes if -fms-compatibility is specified. Some MSVC header files have the same name as clang's builtins, this creates clash.

llvm-svn: 140009

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

Rename LangOptions::Microsoft to LangOptions::MicrosoftExt to make it clear that this flag must be used only for Microsoft extensions and not emulation; to avoid confusion with the new LangOptions::MicrosoftMode flag. 

Many of the code now under LangOptions::MicrosoftExt will eventually be moved under the LangOptions::MicrosoftMode flag.

llvm-svn: 139987

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

As per discussion with Doug Gregor on the IRC channel, introduce a new compiler switch: -fms-compatility. 

Microsoft specific tweaking will now fall into 2 categories:

    - fms-extension: Microsoft specific extensions that should never change the meaning of an otherwise well formed code. Currently map to LangOptions::Microsoft. (To be clearer, I am planning to change the name to LangOptions::MicrosoftExt).

    - fms-compatibility: Really a MSVC emulation mode. Map to LangOptions::MicrosoftMode. Can change the meaning of an otherwise standard conformant program.

llvm-svn: 139978

llvm-svn: 139977

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