llvm-svn: 149258

llvm-svn: 149257

mangling of floating-point literals.  I just went ahead and
reimplemented toString() here;  if someone wants to generalize
the library routine to do this, or feels strongly that we should
be post-processing, please feel free.

llvm-svn: 149256

llvm-svn: 149253

llvm-svn: 149237

- Remove the printf0 special handling as we treat it as printf anyway.
- Perform basic checks (non-literal, empty) for all formats and not only printf/scanf.

llvm-svn: 149236

Remove custom handling for cmpsd/cmpss/cmppd/cmpps builtins. The builtins are now in IntrinsicsX86.td.

llvm-svn: 149235

Cleanup 3dnow builtin handling. Most of them were already handled by LLVM connecting intrinsics and builtins in IntrinsicsX86.td.

llvm-svn: 149233

llvm-svn: 149228

each of the targets. Use this for module requirements, so that we can
pin the availability of certain modules to certain target features,
e.g., provide a module for xmmintrin.h only when SSE support is
available.

Use these feature names to provide a nearly-complete module map for
Clang's built-in headers. Only mm_alloc.h and unwind.h are missing,
and those two are fairly specialized at the moment. Finishes
<rdar://problem/10710060>.

llvm-svn: 149227

recently.  This also conveniently gets clang ready for a change about to
land in mainline.

llvm-svn: 149225

target-specific module requirements.

llvm-svn: 149224

llvm-svn: 149214

llvm-svn: 149213

llvm-svn: 149210

llvm-svn: 149209

headers. The remaining headers require more sophisticated
requirements; they'll be handled separately. Part of
<rdar://problem/10710060>.

llvm-svn: 149206

llvm-svn: 149205

llvm-svn: 149204

results in libclang.

llvm-svn: 149200

  @import <complete with module names here>

or

  @import std.<complete with submodule names here>

Addresses <rdar://problem/10710117>.

llvm-svn: 149199

for getting the name of the module file, unifying the code for
searching for a module with a given name (into lookupModule()) and
separating out the mapping to a module file (into
getModuleFileName()). No functionality change.

llvm-svn: 149197

kill the retain from the return site.

This has the workaround nature.  It's badness all around.

llvm-svn: 149193

in the presence of straight-line cleanups.  This is a simple but
important case, particularly for ARC.

llvm-svn: 149190

like Darwin that don't support it.  We should also complain about
invalid -fvisibility=protected, but that information doesn't seem
to exist at the most appropriate time, so I've left a FIXME behind.

llvm-svn: 149186

consume one or more of their arguments. If not done, this will cause a leak
as method will not consume the argument when receiver is null.
// rdar://10444474

llvm-svn: 149184

There is really no reason to have these only available on x86. It's
just __builtin_c[tl]z for shorts.

Modernize the test while at it.

llvm-svn: 149183

llvm-svn: 149181

StaticAnalyzer: Move ObjC- and CXX-specific methods out of line so checkers that don't care about the language don't have to pull in all the headers.

llvm-svn: 149178

caught by Chad.

llvm-svn: 149173

the alignment (because it's not encoded in DWARF). In this case, make
an educated guess at the alignment.

llvm-svn: 149161

single attribute ("system") that allows us to mark a module as being a
"system" module. Each of the headers that makes up a system module is
considered to be a system header, so that we (for example) suppress
warnings there.

If a module is being inferred for a framework, and that framework
directory is within a system frameworks directory, infer it as a
system framework.

llvm-svn: 149143

llvm-svn: 149127

llvm-svn: 149125

llvm-svn: 149124

-Wno-everything remap all warnings to ignored.

We can now use "-Wno-everything -W<warning>" to ignore all warnings except
specific ones.

llvm-svn: 149121

the original action.

llvm-svn: 149120

the direct serialization of the linked-list structure. Instead, use a
scheme similar to how we handle redeclarations, with redeclaration
lists on the side. This addresses several issues:
  - In cases involving mixing and matching of many categories across
  many modules, the linked-list structure would not be consistent
  across different modules, and categories would get lost.
  - If a module is loaded after the class definition and its other
  categories have already been loaded, we wouldn't see any categories
  in the newly-loaded module.

llvm-svn: 149112

of a for-range variable.  Fixes PR11793.

llvm-svn: 149109

function definition can produce a constant expression. This also provides the
last few checks for [dcl.constexpr]p3 and [dcl.constexpr]p4.

llvm-svn: 149108