This looks perfect, thanks! Your work on more flexible attributes comes in handy here. :-) I'll want a C++ test case as well, but I can add that later.
On Fri, Mar 21, 2014 at 6:15 AM, Aaron Ballman <[email protected]> wrote: > 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 <[email protected]> wrote: >> On Thu, Mar 20, 2014 at 6:48 PM, Delesley Hutchins <[email protected]> >> 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 -- DeLesley Hutchins | Software Engineer | [email protected] | 505-206-0315 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
