llvm-svn: 100925

serve as a source of source locations for the can't-yet-mangle diagnostic.

llvm-svn: 100924

member.  Use a better diagnostic for this case.  Also fix a bug with nested
anonymous structs/unions for -Wreorder;  this last was PR6575.

llvm-svn: 100923

when they're instantiated.  Merge the note into the -Wreorder warning;  it
doesn't really contribute much, and it was splitting a thought across diagnostics
anyway.  Don't crash in the parser when a constructor's initializers end in a
comma and there's no body;  the recovery here is still terrible, but anything's
better than a crash.

llvm-svn: 100922

llvm-svn: 100919

llvm-svn: 100918

Clang is installed. This is designed to match gcc, and is important when
installed in a non-standard location.
 - This is gross, but no worse than ever. It will die when we finally move to
   the compiler-rt based toolchain, any day now.

llvm-svn: 100915

it. PR6812.
 - This is another attempt at silencing annoying buildbot failures.

llvm-svn: 100914

llvm-svn: 100909

mangling an unknown expression kind.  Also conveniently tells the user what
kind of expression they should add to the mangler!

llvm-svn: 100907

just integer-literal expressions with special case implementations in the AST.

Fixes rdar://problem/7825453.

llvm-svn: 100905

full-fledged @interface, be sure that the declaration has the right
lexical context. <rdar://problem/7827709>

llvm-svn: 100903

specializations when the explicit instantiation was... explicitly
written, i.e., not the product of an explicit instantiation of an
enclosing class. Fixes this spurious warning when Clang builds LLVM:

/Volumes/Data/dgregor/Projects/llvm/lib/CodeGen/MachineDominators.cpp:22:1:
warning: explicit instantiation of 'addRoot' that occurs after an
explicit specialization will be ignored (C++0x extension) [-pedantic]

llvm-svn: 100900

llvm-svn: 100891

we don't have enough information to tell them how to use 'strncmp'.  Instead, change the
diagnostic to indicate they should use 'strncmp'.

llvm-svn: 100890

llvm-svn: 100882

Remove -faccess-control from -cc1; add -fno-access-control.
Make the driver pass -fno-access-control by default.
Update a bunch of tests to be correct under access control.

llvm-svn: 100880

fails to find a type.  There are no cases where it's valid for this to produce
an error.

llvm-svn: 100878

the implicit template instantiations we need to perform. Otherwise, we
end up erroneously diagnosing static functions as used if they were
only used within an implicit template instantiation. Fixes a bunch of
spurious failures when building Clang with Clang.

llvm-svn: 100872

type isn't dependent.  Fixes rdar://problem/7838962.

llvm-svn: 100871

attr constructor or destructor.  Patch by Jean-Daniel Dupas!

llvm-svn: 100870

precompiled headers and/or when reading the contents of the file into
memory. These checks seem to be causing spurious regression-test
failures on Windows.

llvm-svn: 100866

for objc.

llvm-svn: 100865

destination type for initialization, assignment, parameter-passing,
etc. The main issue fixed here is that we used rather confusing
wording for diagnostics such as

t.c:2:9: warning: initializing 'char const [2]' discards qualifiers,
      expected 'char *' [-pedantic]
  char *name = __func__;
        ^      ~~~~~~~~

We're not initializing a 'char const [2]', we're initializing a 'char
*' with an expression of type 'char const [2]'. Similar problems
existed for other diagnostics in this area, so I've normalized them all
with more precise descriptive text to say what we're
initializing/converting/assigning/etc. from and to. The warning for
the code above is now:

t.c:2:9: warning: initializing 'char *' from an expression of type
      'char const [2]' discards qualifiers [-pedantic]
  char *name = __func__;
        ^      ~~~~~~~~

Fixes <rdar://problem/7447179>.

llvm-svn: 100832

This is still not an ideal solution, but should disable the check for other
targets where the value of O_CREAT is different.

llvm-svn: 100818

looking into an alternate fix right now.

llvm-svn: 100816

warning. It's not harmful to have such pointless declarations, and GCC
does not diagnose this issue consistently.

llvm-svn: 100814

of c-style arguments. Completes radar 7445205.

llvm-svn: 100813

variable declarations.

llvm-svn: 100809

Fixes PR6752.

llvm-svn: 100806

automatic storage.  This matches the corresponding check for 'dispatch_once()'.

llvm-svn: 100803

unless they are used.  I discussed this with Daniel Dunbar, and we agreed that this
provides an inconsistent warnings experience for the user and that there were
genuine cases where we wouldn't want to do this optimization.

llvm-svn: 100800

<tr1/hashtable> header, where a friend class template
std::tr1::__detail::_Map_base is declared with the wrong template
parameters. GCC doesn't catch the problem, so Clang does a little
back-flip to avoid diagnosing just this one instance of the problem.

llvm-svn: 100790

parameters list for encoding.

llvm-svn: 100788

Declarator that depends on it.  This fixes several redundant errors and bad
recoveries.

llvm-svn: 100779

llvm-svn: 100778

llvm-svn: 100776

llvm-svn: 100775

__cxxabiv1::__fundamental_type_info in every translation
unit. Previously, we would perform name lookup for
__cxxabiv1::__fundamental_type_info at the end of IRGen for a each
translation unit, to determine whether it was present. If so, we we
produce type information for all of the fundamental types. However,
this name lookup causes PCH deserialization of a significant part of the
translation unit, which has a woeful impact on performance.

With this change, we now look at each record type after we've
generated its vtable to see if it is
__cxxabiv1::__fundamental_type_info. If so, we generate type info for
all of the fundamental types. This works because
__cxxabiv1::__fundamental_type_info should always have a key function
(typically the virtual destructor), that will be defined once in the
support library. The fundamental type information will end up there.

Fixes <rdar://problem/7840011>.

llvm-svn: 100772

llvm-svn: 100770