Commit Graph

16 Commits

Author SHA1 Message Date
Aaron Ballman a8c2f76cd2 Removing an accidentally duplicated line of test code to fix bots. 2020-01-21 16:03:22 -05:00
Etienne Pierre-Doray 5260bc2497 Allow arbitrary capability name in Thread Safety Analysis
Restricting the names of capabilities to only "role" or "mutex" makes
for awkward diagnostic text, such as with:
https://chromium-review.googlesource.com/c/chromium/src/+/1948098/19/base/sequence_checker_unittest.nc#33
2020-01-21 15:43:17 -05:00
Aaron Puchert 7ba1ab71ec Thread Safety Analysis: warnings for attributes without arguments
Summary:
When thread safety annotations are used without capability arguments,
they are assumed to apply to `this` instead. So we warn when either
`this` doesn't exist, or the class is not a capability type.

This is based on earlier work by Josh Gao that was committed in r310403,
but reverted in r310698 because it didn't properly work in template
classes. See also D36237.

The solution is not to go via the QualType of `this`, which is then a
template type, hence the attributes are not known because it could be
specialized. Instead we look directly at the class in which we are
contained.

Additionally I grouped two of the warnings together. There are two
issues here: the existence of `this`, which requires us to be a
non-static member function, and the appropriate annotation on the class
we are contained in. So we don't distinguish between not being in a
class and being static, because in both cases we don't have `this`.

Fixes PR38399.

Reviewers: aaron.ballman, delesley, jmgao, rtrieu

Reviewed By: delesley

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D51901

llvm-svn: 342605
2018-09-20 00:39:27 +00:00
Aaron Ballman adf66b6174 Determine the attribute subject for diagnostics based on declarative information in DeclNodes.td. This greatly reduces the number of enumerated values used for more complex diagnostics; these are now only required when the "attribute only applies to" diagnostic needs to be generated manually as part of semantic processing.
This also clarifies some terminology used by the diagnostic (methods -> Objective-C methods, fields -> non-static data members, etc).

Many of the tests needed to be updated in multiple places for the diagnostic wording tweaks. The first instance of the diagnostic for that attribute is fully specified and subsequent instances cut off the complete list (to make it easier if additional subjects are added in the future for the attribute).

llvm-svn: 319002
2017-11-26 20:01:12 +00:00
Josh Gao 55afa7504f Revert "Thread Safety Analysis: warn on nonsensical attributes."
This reverts commit rL310403, which caused spurious warnings in libc++,
because it didn't properly handle templated scoped lockable types.

llvm-svn: 310698
2017-08-11 07:54:35 +00:00
Josh Gao b40c177095 Thread Safety Analysis: warn on nonsensical attributes.
Add warnings in cases where an implicit `this` argument is expected to
attributes because either `this` doesn't exist because the attribute is
on a free function, or because `this` is on a type that doesn't have a
corresponding capability/lockable/scoped_lockable attribute.

Reviewers: delesley, aaron.ballman

Differential Revision: https://reviews.llvm.org/D36237

llvm-svn: 310403
2017-08-08 19:44:35 +00:00
Josh Gao ec1369ed6e Reland "Thread Safety Analysis: fix assert_capability."
Delete the test that was broken by rL309725, and add it back in a
follow up commit. Also, improve the tests a bit.

Reviewers: delesley, aaron.ballman

Differential Revision: https://reviews.llvm.org/D36237

llvm-svn: 310402
2017-08-08 19:44:34 +00:00
DeLesley Hutchins 2b504dce14 Thread Safety Analysis: allow capability attribute on unions.
llvm-svn: 248805
2015-09-29 16:24:18 +00:00
John McCall 2859258e2f Allow objc_bridge(id) to be used on typedefs of [cv] void*.
rdar://19678874

llvm-svn: 227774
2015-02-01 22:34:06 +00:00
Aaron Ballman 7605072e61 In preparation for being able to use simple Boolean logic expressions involving capabilities, the semantics for attributes now looks through the types of the constituent parts of a capability expression instead of at the aggregate expression type.
llvm-svn: 205629
2014-04-04 15:13:57 +00:00
Aaron Ballman 69e6e7c604 Capability attributes can now be declared on a typedef declaration as well as a structure declaration. This allows for C code to use Boolean expressions on a capability as part of another attribute. Eg) __attribute__((requires_capability(!SomeCapability)))
llvm-svn: 204657
2014-03-24 19:29:19 +00:00
Alexander Kornienko 36155dd274 Fixed newlines.
llvm-svn: 204413
2014-03-21 00:07:27 +00:00
Aaron Ballman 18d85aed39 Replacing the exclusive_lock_function, shared_lock_function and unlock_function attributes with the acquire_capability and release_capability attributes. The old spellings will continue to work, but the underlying semantic attributes have been replaced.
Downgraded the capability diagnostics from error to warning to match the desired behavior, and updated the existing test cases.

llvm-svn: 204350
2014-03-20 16:02:49 +00:00
Aaron Ballman 6c8100748f Capabilities are required to pass a name specifying what type of capability is being annotated. There are currently only two supported names: mutex and role. Adding functionality to check for the capability name and diagnose when it's unexpected.
Note that for backwards compatibility, an unnamed capability will default to being a "mutex." This allows the deprecated lockable attribute to continue to function.

llvm-svn: 203012
2014-03-05 21:47:13 +00:00
Aaron Ballman 9e9d184133 Adding role-based capability attributes that allow you to express role management: asserting a capability is held, acquiring a capability and releasing a capability. Also includes some skeleton documentation for these new attributes.
This functionality should be considered a WIP.

llvm-svn: 201890
2014-02-21 21:05:14 +00:00
Aaron Ballman efe348ec44 DeLesley Hutchins (who wrote the original thread-safety attribute functionality) and I have agreed to start migrating from lock-specific terminology to "capability"-specific terminology. This opens the door for future threading-related analysis passes so that a common nomenclature can be used.
The following attributes have been (silently) deprecated, with their replacements listed:

lockable => capability
exclusive_locks_required => requires_capability
shared_locks_required => requires_shared_capability
locks_excluded => requires_capability

There are no functional changes intended.

llvm-svn: 201585
2014-02-18 17:36:50 +00:00