llvm-svn: 202953

  Failing Tests (5):
    Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.CaseInsensitive
    Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.MappedFiles
    Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.MultiComponentPath
    Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.TrailingSlashes
    Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.UseExternalName

llvm-svn: 202952

Summary:
The MSVC ABI appears to mangle the lexical scope into the names of
statics.  Specifically, a counter is incremented whenever a scope is
entered where things can be declared in such a way that an ambiguity can
arise.  For example, a class scope inside of a class scope doesn't do
anything interesting because the nested class cannot collide with
another nested class.

There are problems with this scheme:
- It is unreliable. The counter is only incremented when a previously
  never encountered scope is entered.  There are cases where this will
  cause ambiguity amongst declarations that have the same name where one
  was introduced in a deep scope while the other was introduced right
  after in the previous lexical scope.
- It is wasteful.  Statements like: {{{{{{{ static int foo = a; }}}}}}}
  will make the mangling of "foo" larger than it need be because the
  scope counter has been incremented many times.

Because of these problems, and practical implementation concerns.  We
choose not to implement this scheme if the local static or local type
isn't visible.  The mangling of these declarations will look very
similar but the numbering will make far more sense, this scheme is
lifted from the Itanium ABI implementation.

Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x

Reviewed By: rnk

CC: cfe-commits

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

llvm-svn: 202951

llvm-svn: 202950

This will make the transition to unique_ptr easier by allowing more
incremental changes.

llvm-svn: 202949

Adjust logic for 'objc_protocol_requires_explicit_implementation' for inherited protocols and protocols already conformed in the class hierarchy.

Per more discussion, 'objc_protocol_requires_explicit_implementation' is
refinement that it mainly adds that requirement that a protocol must be
explicitly satisfied at the moment the first class in the class hierarchy
conforms to it.  Any subclasses that also conform to that protocol,
either directly or via conforming to a protocol that inherits that protocol,
do not need to re-implement that protocol.

Doing this requires first doing a pass on the super class hierarchy,
gathering the set of protocols conformed to by the super classes,
and then culling those out when determining conformance.  This
two-pass algorithm could be generalized for all protocol checking,
and could possibly be a performance win in some cases.  For now
we restrict this change to protocols with this attribute to isolate
the change in logic (especially as the design continues to evolve).

This change needs to be adjusted for properties as well; this
only impacts methods right now.

llvm-svn: 202948

llvm-svn: 202947

llvm-svn: 202946

llvm-svn: 202945

llvm-svn: 202944

Patchpoints already did this. Doing it for stackmaps is a convenience
for the runtime in the event that it needs to scratch register to
patch or perform a runtime call thunk.

Unlike patchpoints, we just assume the AnyRegCC calling
convention. This is the only language and target independent calling
convention specific to stackmaps so makes sense.  Although the calling
convention is not currently used to select the scratch registers.

llvm-svn: 202943

llvm-svn: 202942

rdar://14309030

llvm-svn: 202941

llvm-svn: 202940

llvm-svn: 202939

llvm-svn: 202938

llvm-svn: 202937

Patch by Manuel Jacob.

llvm-svn: 202936

Found self-hosting clang-cl on windows. :)

llvm-svn: 202935

Implement LWG #2212: std::is_final. This requires compiler support, which modern versions of clang provide. Also mark LWG #2230 as complete - no code changes needed.

llvm-svn: 202934

with Greg's change to how we load modules in r202890.

llvm-svn: 202933

llvm-svn: 202932

Update synposis in <memory> to show move semantics for weak_ptr; add tests for already existing move semantics. Mark LWG issues #2315 (no changes needed), 2316 (move semantics for weak_ptr), 2252 (previous commit) and 2271 (previous commit) as complete.

llvm-svn: 202931

selection dag (PR19012)

In X86SelectionDagInfo::EmitTargetCodeForMemcpy we check with MachineFrameInfo
to make sure that ESI isn't used as a base pointer register before we choose to
emit rep movs (which clobbers esi).

The problem is that MachineFrameInfo wouldn't know about dynamic allocas or
inline asm that clobbers the stack pointer until SelectionDAGBuilder has
encountered them.

This patch fixes the problem by checking for such things when building the
FunctionLoweringInfo.

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

llvm-svn: 202930

The correct name of the type in LLVM assembly is "x86_mmx".  Also remove
the reST label "t_x86mmx" because it was unused anyway.

Patch by Manuel Jacob!

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

llvm-svn: 202929

Patch by Manuel Jacob!

llvm-svn: 202928

The distinction between "identified" and "literal" struct types is fully
documented in a later section.

Patch by Philip Reames!

llvm-svn: 202927

llvm-svn: 202926

llvm-svn: 202925

llvm-svn: 202924

itself and teach it to convert between the non-const and const variants.
De-templatetize its usage in APIs to just use the const variant which
always works for those use cases. Also, rename its implementation to
reflect that it is an iterator over *users* not over *uses*.

This is a step toward providing both iterator and range support for
walking the *uses* distinct from the *users*. In a subsequent patch this
will get renamed to make it clear that this is an adaptor over the
fundamental use iterator.

llvm-svn: 202923

llvm-svn: 202922

using a full uint16_t with the flag value... which happens to be
0 or 1. Update the class for bool values and rename functions slightly.

llvm-svn: 202921

llvm-svn: 202920

llvm-svn: 202919

llvm-svn: 202918

llvm-svn: 202917

I did not intend to cast a pointer to ulittle32_t there because the return
type is const void*.

llvm-svn: 202916

Looks like llvm-readobj is the only customer of this code, and apparently
there's no test to cover this function. I'll write it after finishing
plumbing from llvm-objdump to there.

llvm-svn: 202915

llvm-svn: 202914