on https://build.chromium.org/p/chromium.fyi/builders/ClangToTWin/builds/8593/steps/compile/logs/stdio too, so it's a regression

273689 good, 273708 bad. we need 273707 to fix a crash, but r273705 broke something and wasn't reverted until 273709, so this blocks the clang roll :-(

Looking

Culprit is Chromium r401911 which triggered a pre-existing bug in the compiler.

Same problem is visible on the non-ToT bot: https://build.chromium.org/p/chromium.fyi/builders/CrWinClang/builds/10185/steps/compile/logs/stdio

Huh, that's pretty unfortunate :-(

I guess next step is to make a small repro, and then with that in hand maybe some simple temporary workaround we could land chromium becomes apparent?

https://codereview.chromium.org/2085293002

https://cs.chromium.org/chromium/src/device/bluetooth/bluetooth_adapter.h?q=NotifyGattCharacteristicValueChanged&sq=package:chromium&dr=CSs&l=463 takes a BluetoothRemoteGattCharacteristic*, `this` is a BluetoothRemoteGattCharacteristicWin.

Maybe doing

  BluetoothRemoteGattCharacteristic* arg = this;

and then passing arg works around the problem?

Filed https://llvm.org/bugs/show_bug.cgi?id=28299 and sent workaround: https://codereview.chromium.org/2089313006

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/292962a4de3a928fbc25539ab557169b86e89e88

commit 292962a4de3a928fbc25539ab557169b86e89e88
Author: pcc <pcc@chromium.org>
Date: Sat Jun 25 01:49:50 2016

bluetooth: Avoid use of lambda to work around clang bug.

Clang has a bug [1] that is exposed by the use of a lambda in this unit
test. Until that is fixed, work around it by turning the lambda into a static
function. Should help unblock the next clang roll.

[1] https://llvm.org/bugs/show_bug.cgi?id=28299

BUG=623209
R=ortuno@chromium.org,thakis@chromium.org

Review-Url: https://codereview.chromium.org/2089313006
Cr-Commit-Position: refs/heads/master@{#402043}

[modify] https://crrev.com/292962a4de3a928fbc25539ab557169b86e89e88/device/bluetooth/bluetooth_remote_gatt_characteristic_unittest.cc

Doesn't block the roll, but let's keep this open so we'll remember to revert the workaround once clang-cl is able to do this.

Thanks, pcc!

I looked at this a while ago, and it's hard. Clang's lambda code assumes it can perfectly forward arguments, which is just not true with inalloca.

Looks like this is still a problem.

rnk: If the codegen part is hard to fix, could we at least emit a diagnostic when needing to forward an inalloca arg to a lambda instead of asserting?

 Issue 757042  has been merged into this issue.

 Issue 905310  has been merged into this issue.

I turned the assertion into a codegen-time diagnostic, but fixing the actual bug is still hard. I worked on it, but I timed out and have to move onto something else.