llvm-svn: 129614

which versions of an OS provide a certain facility. For example,

  void foo()
  __attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6)));

says that the function "foo" was introduced in 10.2, deprecated in
10.4, and completely obsoleted in 10.6. This attribute ties in with
the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that
we want to deploy back to Mac OS X 10.1). There are several concrete
behaviors that this attribute enables, as illustrated with the
function foo() above:

  - If we choose a deployment target >= Mac OS X 10.4, uses of "foo"
    will result in a deprecation warning, as if we had placed
    attribute((deprecated)) on it (but with a better diagnostic)
  - If we choose a deployment target >= Mac OS X 10.6, uses of "foo"
    will result in an "unavailable" warning (in C)/error (in C++), as
    if we had placed attribute((unavailable)) on it
  - If we choose a deployment target prior to 10.2, foo() is
    weak-imported (if it is a kind of entity that can be weak
    imported), as if we had placed the weak_import attribute on it.

Naturally, there can be multiple availability attributes on a
declaration, for different platforms; only the current platform
matters when checking availability attributes.

The only platforms this attribute currently works for are "ios" and
"macosx", since we already have -mxxxx-version-min flags for them and we
have experience there with macro tricks translating down to the
deprecated/unavailable/weak_import attributes. The end goal is to open
this up to other platforms, and even extension to other "platforms"
that are really libraries (say, through a #pragma clang
define_system), but that hasn't yet been designed and we may want to
shake out more issues with this narrower problem first.

Addresses <rdar://problem/6690412>.

As a drive-by bug-fix, if an entity is both deprecated and
unavailable, we only emit the "unavailable" diagnostic.

llvm-svn: 128127

I also sorted the tools/driver dependencies since their order no
longer matters.

llvm-svn: 125417

llvm-svn: 125275

its own header and giving it some more structure.  No 
functionality change.

llvm-svn: 120030

llvm-svn: 119741

See PR 8473.

llvm-svn: 117110

This reverts commit r113631

Conflicts:

	CMakeLists.txt
	lib/CodeGen/CMakeLists.txt

llvm-svn: 113817

of whatever we were using before...

llvm-svn: 113631

llvm-svn: 106220

llvm-svn: 106188

llvm-svn: 85015

branch/revision information. Use that information in the driver,
rather than one-off branch/revision computation. 

llvm-svn: 83321

fixes a layering violation in lib/Basic/Targets.cpp.

llvm-svn: 73318

headers. Future approaches to (de-)serializing ASTs will be based on
the PCH infrastructure.

llvm-svn: 69828

llvm-svn: 69819

#ifdef'd out the 5 conversion routines that we don't currently need.

Still need a bit more work in GetAddrOfConstantCFString(). Added a FIXME to indicate this.

Expect to remove the FIXME today...

llvm-svn: 68208

diagnostics. This builds on the patch that Sebastian committed and
then revert. Major differences are:

  - We don't remove or use the current ".def" files. Instead, for now,
    we just make sure that we're building the ".inc" files.
  - Fixed CMake makefiles to run TableGen and build the ".inc" files
    when needed. Tested with both the Xcode and Makefile generators
    provided by CMake, so it should be solid.
  - Fixed normal makefiles to handle out-of-source builds that involve
    the ".inc" files.

I'll send a separate patch to the list with Sebastian's changes that
eliminate the use of the .def files.

llvm-svn: 67058

must be under the `tools' subdirectory of the LLVM *source* tree.

llvm-svn: 58180