Commit Graph

11 Commits

Author SHA1 Message Date
Aaron Ballman 7deaeb2a05 Use functions with prototypes when appropriate; NFC
A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a prototype for the situations where the test is not specific to K&R C
declarations. e.g.,

  void func();

becomes

  void func(void);

This is the fourth batch of tests being updated (there are a significant
number of other tests left to be updated).
2022-02-07 15:29:36 -05:00
Douglas Yung be68c9222b [NFC] Add -std=c11 to attr-availability.c
This test will fail with any toolchains that don't default to C11.

Adding this switch to the clang invocation in the test fixes the issue.

Patch by Justice Adams!

Reviewed By: dyung

Differential Revision: https://reviews.llvm.org/D94829
2021-01-15 21:05:49 -08:00
Nigel Perks 27ea7d0a6e Fix inconsistent availability attribute message string literal check.
Function Parser::ParseAvailabilityAttribute checks that the message string of
an availability attribute is not a wide string literal. Test case
clang/test/Parser/attr-availability.c specifies that a string literal is
expected.

The code checked that the first token in a string concatenation is a string
literal, and then that the concatenated string consists of 1-byte characters.
On a target where wide character is 1 byte, a string concatenation "a" L"b"
passes both those checks, but L"b" alone is rejected. More generally, "a" u8"b"
passes the checks, but u8"b" alone is rejected.

So check isAscii() instead of character size.
2020-12-08 12:33:59 -05:00
David Majnemer 2e49830b3d Parse: Diagnose malformed 'message' arguments for 'availability' attr
The parsing code for 'availability' wasn't prepared for string literals
like "a" L"b" showing up.  Error if this occurs.

llvm-svn: 213350
2014-07-18 05:43:12 +00:00
Benjamin Kramer a9dfa9280e As Aaron pointed out it's simpler to reject wide string availability attr messages in the parser.
llvm-svn: 190706
2013-09-13 17:31:48 +00:00
Andy Gibbs a8df57a962 Made the "expected string literal" diagnostic more expressive
llvm-svn: 168267
2012-11-17 19:16:52 +00:00
Richard Trieu 553b2b2e5d Modify how the -verify flag works. Currently, the verification string and
diagnostic message are compared.  If either is a substring of the other, then
no error is given.  This gives rise to an unexpected case:

  // expect-error{{candidate function has different number of parameters}}

will match the following error messages from Clang:

  candidate function has different number of parameters (expected 1 but has 2)
  candidate function has different number of parameters

It will also match these other error messages:

  candidate function
  function has different number of parameters
  number of parameters

This patch will change so that the verification string must be a substring of
the diagnostic message before accepting.  Also, all the failing tests from this
change have been corrected.  Some stats from this cleanup:

87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)

llvm-svn: 146619
2011-12-15 00:38:15 +00:00
Fariborz Jahanian 88d510da9d Add ability to supply additional message to availability macros,
// rdar://10095131

llvm-svn: 146304
2011-12-10 00:28:41 +00:00
Douglas Gregor 7bf3fbe6e1 Add a __has_feature check for the 'availability' attribute
llvm-svn: 128337
2011-03-26 12:16:15 +00:00
Douglas Gregor 7ab142b55a Extend the new 'availability' attribute with support for an
'unavailable' argument, which specifies that the declaration to which
the attribute appertains is unavailable on that platform.

llvm-svn: 128329
2011-03-26 03:35:55 +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