Mojo Mutex: fix declspec and GNU attribute order

Mojo Mutex: fix declspec and GNU attribute order

Clang can't parse this:

   class __declspec(dllexport) __attribute__((lockable)) Mutex { };

the attribute and declspec have to come in the other order.

BUG=82385
R=rockot@chromium.org

Committed: https://chromium.googlesource.com/chromium/src/+/ad8ca12b69aa89fa781998764c19504967810237

[hans, 2015-08-24 22:47:51]

hans@chromium.org changed reviewers:
+ rockot@chromium.org

[hans, 2015-08-24 22:47:51]

Let's get this in to fix the build break, and then also commit it upstream.

Verified that mojo_system_unittests build locally.

[Ken Rockot(use gerrit already), 2015-08-24 22:50:46]

lgtm

[hans, 2015-08-24 22:51:13]

The CQ bit was checked by hans@chromium.org

[commit-bot: I haz the power, 2015-08-24 22:51:37]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1310423002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1310423002/1

[hans, 2015-08-24 23:17:31]

Committed patchset #1 (id:1) manually as
ad8ca12b69aa89fa781998764c19504967810237 (presubmit successful).

[Nico, 2015-08-24 23:45:00]

thakis@chromium.org changed reviewers:
+ thakis@chromium.org

[Nico, 2015-08-24 23:45:01]

Since cl understands this, should we teach clang to understand this order too?
Since this is very rarely a problem, I guess it's better to demand a consistent
order?

[hans, 2015-08-24 23:48:46]

On 2015/08/24 23:45:01, Nico wrote:
> Since cl understands this, should we teach clang to understand this order too?
> Since this is very rarely a problem, I guess it's better to demand a
consistent
> order?

cl won't get the thread-safety attribute (it's behind #ifdef __clang__), and it
wouldn't understand it as it's a GNU-style attribute.

It would good if Clang could parse these in any order (http://llvm.org/PR24559),
but I'm not sure how soon it can happen.