Commit Graph

9 Commits

Author SHA1 Message Date
Ted Kremenek b79ee57080 Implemented delayed processing of 'unavailable' checking, just like with 'deprecated'.
Fixes <rdar://problem/15584219> and <rdar://problem/12241361>.

This change looks large, but all it does is reuse and consolidate
the delayed diagnostic logic for deprecation warnings with unavailability
warnings.  By doing so, it showed various inconsistencies between the
diagnostics, which were close, but not consistent.  It also revealed
some missing "note:"'s in the deprecated diagnostics that were showing
up in the unavailable diagnostics, etc.

This change also changes the wording of the core deprecation diagnostics.
Instead of saying "function has been explicitly marked deprecated"
we now saw "'X' has been been explicitly marked deprecated".  It
turns out providing a bit more context is useful, and often we
got the actual term wrong or it was not very precise
 (e.g., "function" instead of "destructor").  By just saying the name
of the thing that is deprecated/deleted/unavailable we define
this issue away.  This diagnostic can likely be further wordsmithed
to be shorter.

llvm-svn: 197627
2013-12-18 23:30:06 +00:00
Eli Friedman 971bfa11c6 Unify the codepaths for emitting deprecation warnings. The test changes are just to account for us emitting notes more consistently.
llvm-svn: 161528
2012-08-08 21:52:41 +00:00
Fariborz Jahanian f021889036 -Wdeprecated warning to include reference (as a note)
to the declaration in this patch. // rdar://10893232

llvm-svn: 157537
2012-05-27 16:59:48 +00:00
Douglas Gregor 20b2ebd785 Implement a new 'availability' attribute, that allows one to specify
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
2011-03-23 00:50:03 +00:00
Ted Kremenek 1ddd6d2b6b Upgrade "'X' is unavailable" from a warning to an error. This matches GCC's behavior. Note that
GCC emits a warning instead of an error when using an unavailable Objective-C protocol, so now
Clang's behavior is more strict in this case, but more consistent.  We will need to see how much
this fires on real code and determine whether this case should be downgraded to a warning.

Fixes <rdar://problem/8213093>.

llvm-svn: 109033
2010-07-21 20:43:11 +00:00
Daniel Dunbar 8fbe78f6fc Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- This is designed to make it obvious that %clang_cc1 is a "test variable"
   which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
   can be useful to redefine what gets run as 'clang -cc1' (for example, to set
   a default target).

llvm-svn: 91446
2009-12-15 20:14:24 +00:00
Fariborz Jahanian 0399c1c9c0 Change tests to use clang -cc1...
llvm-svn: 91297
2009-12-14 17:36:25 +00:00
Steve Naroff 51d4f79ffa Fix <rdar://problem/6770276> Support Class<Proto> syntax.
llvm-svn: 76741
2009-07-22 16:07:01 +00:00
Chris Lattner 1c7b885f5f fix typo in test name.
llvm-svn: 68893
2009-04-12 08:37:16 +00:00