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
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
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
36155dd274
Fixed newlines.
...
llvm-svn: 204413
2014-03-21 00:07:27 +00:00
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
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
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
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
John McCall