by default, rather than whether they may be built at all.

llvm-svn: 149037

around, in the process cleaning up the various gcc/msvc compiler
workarounds.

llvm-svn: 149036

llvm-svn: 149035

llvm-svn: 149034

llvm-svn: 149032

Refactor to share code for handling return statements between lambda expressions and block literals.  As it turns out, almost all the logic can be shared.

llvm-svn: 149031

-fixit-recompile
	applies fixits and recompiles the result
-fixit-to-temporary
	applies fixits to temporary files
-fix-only-warnings">,
    applies fixits for warnings only, not errors

Combining "-fixit-recompile -fixit-to-temporary" allows testing the result of fixits
without touching the original sources.

llvm-svn: 149027

when asking for a ConstantStruct with all undef elements.

llvm-svn: 149025

llvm-svn: 149016

llvm-svn: 149015

Now the lexer just produces a token and the parser is the one responsible for
activating it.
This fixes problem like the one pr11797 where the lexer and the parser were not
in sync. This also let us be more strict on where in the file we accept
these pragmas.

llvm-svn: 149014

llvm-svn: 149013

llvm-svn: 149012

both actually tests what it wants to, doesn't have bogus and broken
assertions in it, and is also formatted much more cleanly and
consistently. Probably still some more that can be improved here, but
its much better.

Original commit message:
----
Try to unbreak the FreeBSD toolchain's detection of 32-bit targets
inside a 64-bit freebsd machine with the 32-bit compatibility layer
installed. The FreeBSD image always has the /usr/lib32 directory, so
test for the more concrete existence of crt1.o. Also enhance the tests
for freebsd to clarify what these trees look like and exercise the new
code.

Thanks to all the FreeBSD folks for helping me understand what caused
the failure and how we might fix it. =] That helps a lot. Also, yay
build bots.

llvm-svn: 149011

llvm-svn: 149009

using CFArrayCreate & family.

Specifically, CFArrayCreate's input should be:
'A C array of the pointer-sized values to be in the new array.'

(radar://10717339)

llvm-svn: 149008

they show up as argument types of two block pointers.
// rdar://10734265

llvm-svn: 149007

llvm-svn: 149003

unused yet.

llvm-svn: 149001

Rework flushing of diagnostics to PathDiagnosticConsumer.  Now all the reports are batched up before being flushed
to the underlying consumer implementation.  This allows us to unique reports across analyses to multiple functions (which
shows up with inlining).

llvm-svn: 148997

Don't stack-allocate an IntegerLiteral which can be referred to after the current method returns.  PR11744, part 2.

llvm-svn: 148995

Original log:

Author: chandlerc <chandlerc@91177308-0d34-0410-b5e6-96231b3b80d8>
Date:   Wed Jan 25 21:32:31 2012 +0000

    Try to unbreak the FreeBSD toolchain's detection of 32-bit targets
    inside a 64-bit freebsd machine with the 32-bit compatibility layer
    installed. The FreeBSD image always has the /usr/lib32 directory, so
    test for the more concrete existence of crt1.o. Also enhance the tests
    for freebsd to clarify what these trees look like and exercise the new
    code.

    Thanks to all the FreeBSD folks for helping me understand what caused
    the failure and how we might fix it. =] That helps a lot. Also, yay
    build bots.

llvm-svn: 148993

Add some ABI tweaks for i386-pc-win32 triple so that we return structs in an MSVC-compatible way.  Patch by Joe Groff.

llvm-svn: 148992

Improve the error message slightly for files that aren't using the expected UTF-8 encoding.  Patch by Seth Cantrell.

llvm-svn: 148991

llvm-svn: 148989

llvm-svn: 148988

llvm-svn: 148987

llvm-svn: 148982

inside a 64-bit freebsd machine with the 32-bit compatibility layer
installed. The FreeBSD image always has the /usr/lib32 directory, so
test for the more concrete existence of crt1.o. Also enhance the tests
for freebsd to clarify what these trees look like and exercise the new
code.

Thanks to all the FreeBSD folks for helping me understand what caused
the failure and how we might fix it. =] That helps a lot. Also, yay
build bots.

llvm-svn: 148981

This suppresses typo correction for auto-generated call expressions such
as to 'begin' or 'end' within a C++0x for-range statement.

llvm-svn: 148979

Linux toolchain selection -- sorry folks. =] This should fix the Hexagon
toolchain.

However, I would point out that I see why my testing didn't catch this
-- we have no tests for Hexagon. ;]

llvm-svn: 148977

Pass a typo correction callback object from ParseCastExpr to
Sema::ActOnIdExpression to be a bit more selective about what kinds of
corrections will be allowed for unknown identifiers.

llvm-svn: 148973

llvm-svn: 148970

The new callback, in addition to limiting which keywords to include in
the pool of typo correction candidates, also filters out non-keyword
candidates that don't refer to (template) functions that accept the
number of arguments that are present for the call being recovered.

llvm-svn: 148962

get a function parameter pack (but don't due to weird substitutions),
complain. Fixes the last bit of PR11848.

llvm-svn: 148960

to suit the FreeBSD folks. Take them back to something closer to the old
behavior. We test whether the /usr/lib32 directory exists (within the
SysRoot), and use it if so, otherwise use /usr/lib.

FreeBSD folks, let me know if this causes any problems, or if you have
further tweaks.

llvm-svn: 148953

gross hack to provide it from my previous patch removing HostInfo. This
was enshrining (and hiding from my searches) the concept of storing and
diff-ing the host and target triples. We don't have the host triple
reliably available, so we need to merely inspect the target system. I've
changed the logic in selecting library search paths for NetBSD to match
what I provided for FreeBSD -- we include both search paths, but put the
32-bit-on-64-bit-host path first so it trumps.

NetBSD maintainers, you may want to tweak this, or feel free to ask me
to tweak it. I've left a FIXME here about the challeng I see in fixing
this properly.

llvm-svn: 148952

continue until cleanliness improves.

llvm-svn: 148951

did anything. The two big pieces of functionality it tried to provide
was to cache the ToolChain objects for each target, and to figure out
the exact target based on the flag set coming in to an invocation.
However, it had a lot of flaws even with those goals:
 - Neither of these have anything to do with the host, or its info.
 - The HostInfo class was setup as a full blown class *hierarchy* with
   a separate implementation for each "host" OS. This required
   dispatching just to create the objects in the first place.
 - The hierarchy claimed to represent the host, when in fact it was
   based on the target OS.
 - Each leaf in the hierarchy was responsible for implementing the flag
   processing and caching, resulting in a *lot* of copy-paste code and
   quite a few bugs.
 - The caching was consistently done based on architecture alone, even
   though *any* aspect of the targeted triple might change the behavior
   of the configured toolchain.
 - Flag processing was already being done in the Driver proper,
   separating the flag handling even more than it already is.

Instead of this, we can simply have the dispatch logic in the Driver
which previously created a HostInfo object create the ToolChain objects.
Adding caching in the Driver layer is a tiny amount of code. Finally,
pulling the flag processing into the Driver puts it where it belongs and
consolidates it in one location.

The result is that two functions, and maybe 100 lines of new code
replace over 10 classes and 800 lines of code. Woot.

This also paves the way to introduce more detailed ToolChain objects for
various OSes without threading through a new HostInfo type as well, and
the accompanying boiler plate. That, of course, was the yak I started to
shave that began this entire refactoring escapade. Wheee!

llvm-svn: 148950

freebsd test so that it's behavior isn't dependent on the filesystem of
the host running the tests. This should revive the build bots at least.
The tests and the trees still need a lot of love to make them as useful
and easy to maintain as linux-ld.c.

llvm-svn: 148949