r204350 - 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.

[Aaron Ballman]

Here is an initial implementation of that feature request -- is this
what you were thinking of?

~Aaron

On Thu, Mar 20, 2014 at 6:55 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
> On Thu, Mar 20, 2014 at 6:48 PM, Delesley Hutchins <delesley at google.com> wrote:
>> The analysis currently has a single unlock_function attribute, which
>> will unlock both exclusive and shared locks.  There's a feature
>> request to add shared_unlock_function and exclusive_unlock_function
>> attributes.  (These should issue a warning if they are used to unlock
>> the wrong kind of capability.) Any chance you could wrap those up into
>> the unlock_capability attribute?
>
> Right now, we have release_capability, release_shared_capability and
> release_generic_capability. I think the intention was that
> release_capability == exclusive_unlock_function,
> release_shared_capability == shared_unlock_function, and
> release_generic_capability == unlock_function. If you agree with that
> mapping, I think it should be possible to implement (I'll run the
> patch by you before committing though, just to be sure the semantics
> are what you're looking for).
>
> ~Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SharedUnlock.patch
Type: application/octet-stream
Size: 10254 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140321/44cb65c5/attachment.obj>