[Patch] Clang: allow scoped_lockable to acquire multiple locks

[Ed Schouten]

Hi Aaron,

First of all, thanks for your comments! I'll address the formatting
issues and the crash bug ASAP. Weird that it didn't do this here.

On 2 September 2014 14:56, Aaron Ballman <aaron at aaronballman.com> wrote:
> This adds all locks to the analyzer as exclusive locks, but the
> previous code would handled shared locks separately. Is that
> intentional?

So the intent behind this change is that regardless of the number of
locks that are picked up by the guard object, it is tracked as always
single acquisition of the lock guard object itself. The lock on the
guard object will reference all of the actual underlying locks that
are performed, that are either locked exclusively or shared.

In short, to my knowledge it is irrelevant whether the lock on the
guard object is shared or exclusive. The guard object gets locked upon
construction and unlocked upon destruction. This is why I just picked
exclusive.

Now that you mention it, this change will indeed break if there are no
underlying locks. The set of locks will be empty and our check against
empty() to determine whether we are a scoped guard object or not will
be incorrect.

You know what? Let me take a look at the existing FactEntry class and
see if we can introduce some polymorphism here. Ideally, we should
treat "lockable" and "scoped_lockable" objects completely separately.

-- 
Ed Schouten <ed at 80386.nl>