|
|
DescriptionImplement BluetoothLowEnergyWrapperFake for Bluetooth test fixture
This CL implements BluetoothLowEnergyWrapperFake to make it support BluetoothTest.DiscoverLowEnergyDevice, BluetoothTest.DiscoverLowEnergyDeviceTwice and BluetoothTest.DiscoverMultipleLowEnergyDevices tests.
BUG=579202
Committed: https://crrev.com/d0355bb1d526163aa8d518291df2fd3424925f00
Cr-Commit-Position: refs/heads/master@{#374229}
Patch Set 1 #Patch Set 2 : #
Total comments: 27
Patch Set 3 : address comments #
Total comments: 8
Patch Set 4 : rebase && address comments #
Messages
Total messages: 39 (21 generated)
Description was changed from ========== implement fake ble BUG= ========== to ========== Implement BluetoothLowEnergyWrapperFake for Bluetooth test fixture This CL implements BluetoothLowEnergyWrapperFake to make it support BluetoothTest.DiscoverLowEnergyDevice, BluetoothTest.DiscoverLowEnergyDeviceTwice and BluetoothTest.DiscoverMultipleLowEnergyDevices tests. BUG=579202 ==========
The CQ bit was checked by gogerald@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1676073002/20001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1676073002/20001
The CQ bit was unchecked by gogerald@chromium.org
gogerald@chromium.org changed reviewers: + scheib@chromium.org
Hi Vincent, PTAL.
https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... File device/bluetooth/bluetooth_classic_win.h (right): https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_classic_win.h:39: Any reason for the blank line between previous methods and this one? https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... File device/bluetooth/bluetooth_low_energy_win_fake.cc (right): https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.cc:18: simulated_devices_.clear(); At constructor, shouldn't it already be empty()? https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.cc:77: std::size_t found = path.find('/'); Comment to reference above the expected format of the file path for a GATT service device. Explain that this is parsing it. Better yet, use helper methods to generate and to parse to make these code blocks easier to understand. https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.cc:89: if (!service_attribute_handle.empty()) { Comment explaining what's going on when no service_attribute_handle is found / or split out the code blocks into helper methods with useful names. Since both if/else blocks exist, keep the if logic as simple as possible by handling the true case first, then the false case: if (service_attribute_handle.empty()) { } else { } https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.cc:155: USHORT max_attribute_handle = *(it->second->rbegin()); it->second is reference a few times in this method -- and at the below it is assigned to. I suggest the initial attribute_handle_table_.find is replaced with: scoped_ptr<std::set<USHORT>> set_of_ushort = attribute_handle_table_[device_address] then: if (set_of_ushort) ... and assign with attribute_handle_table_[device_address] = make_scoped_ptr(new_set); https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.cc:186: int result = sscanf_s(uuid.c_str(), "%04x", &data[0]); The device::BluetoothUUID.value() isn't always 4 hex digits -- though perhaps in our tests so far we have only used 4 characters. I guess this code is OK until it breaks by us adding longer UUIDs. A comment to that effect would be good, though. https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... File device/bluetooth/bluetooth_low_energy_win_fake.h (right): https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.h:22: // The key of BLEDevicesMap is the string of BLE device address. "of the BLE" ^^^^ https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.h:26: // BLEGattDescriptorsMap is the string of attribute handle. "string of the attribute" ^^^^ https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.h:33: // The key of BLEAttributeHandleTable is the string of BLE device address. "of the BLE" ^^^^ https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.h:82: USHORT GenerateAnUniqueAttributeHandle(std::string device_address); GenerateAUniqueAttributeHandle or GenerateUniqueAttributeHandle https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.h:88: // The canonical uuid string format is device::BluetoothUUID.value(). Capital UUID. https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... File device/bluetooth/bluetooth_task_manager_win.cc (right): https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_task_manager_win.cc:446: int last_error = win::BluetoothClassicWrapper::GetInstance()->LastError(); BTW, looking at how often ::GetInstance is being called, consider renameing with ::Get() in a future refactor patch. https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/test/b... File device/bluetooth/test/bluetooth_test_win.cc (right): https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/test/b... device/bluetooth/test/bluetooth_test_win.cc:78: adapter_->StartDiscoverySessionWithFilter( Is it possible to avoid duplicate code, and not be brittle to changes to StartLowEnergyDiscoverySession by calling base class here, then RunPendingTasks()? BluetoothTest::StartLowEnergyDiscoverySession(); bluetooth_task_runner_->RunUntilIdle(); ui_task_runner_->RunUntilIdle();
Patchset #3 (id:40001) has been deleted
The CQ bit was checked by gogerald@chromium.org
The CQ bit was unchecked by gogerald@chromium.org
The CQ bit was checked by gogerald@chromium.org to run a CQ dry run
The CQ bit was checked by gogerald@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1676073002/60001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1676073002/60001
Patchset #3 (id:60001) has been deleted
The CQ bit was checked by gogerald@chromium.org to run a CQ dry run
https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... File device/bluetooth/bluetooth_classic_win.h (right): https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_classic_win.h:39: On 2016/02/07 02:24:07, scheib wrote: > Any reason for the blank line between previous methods and this one? Because the system implementation of GetLastError is not only for Bluetooth, but I think I can remove this blank line since 'LastError' interface is been used for Bluetooth only and the fake implementation only for Bluetooth. Moved to CL 1672843002 https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... File device/bluetooth/bluetooth_low_energy_win_fake.cc (right): https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.cc:18: simulated_devices_.clear(); On 2016/02/07 02:24:08, scheib wrote: > At constructor, shouldn't it already be empty()? Done. https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.cc:77: std::size_t found = path.find('/'); On 2016/02/07 02:24:08, scheib wrote: > Comment to reference above the expected format of the file path for a GATT > service device. Explain that this is parsing it. Better yet, use helper methods > to generate and to parse to make these code blocks easier to understand. Done. https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.cc:89: if (!service_attribute_handle.empty()) { On 2016/02/07 02:24:08, scheib wrote: > Comment explaining what's going on when no service_attribute_handle is found / > or split out the code blocks into helper methods with useful names. > > Since both if/else blocks exist, keep the if logic as simple as possible by > handling the true case first, then the false case: > if (service_attribute_handle.empty()) { > } else { > } Done. https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.cc:155: USHORT max_attribute_handle = *(it->second->rbegin()); On 2016/02/07 02:24:08, scheib wrote: > it->second is reference a few times in this method -- and at the below it is > assigned to. I suggest the initial attribute_handle_table_.find is replaced > with: > scoped_ptr<std::set<USHORT>> set_of_ushort = > attribute_handle_table_[device_address] > then: > if (set_of_ushort) > ... > and assign with > attribute_handle_table_[device_address] = make_scoped_ptr(new_set); It seems base::ScopedPtrHashMap does not implement [] operator. https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.cc:186: int result = sscanf_s(uuid.c_str(), "%04x", &data[0]); On 2016/02/07 02:24:08, scheib wrote: > The device::BluetoothUUID.value() isn't always 4 hex digits -- though perhaps in > our tests so far we have only used 4 characters. I guess this code is OK until > it breaks by us adding longer UUIDs. A comment to that effect would be good, > though. Yes. https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.cc:186: int result = sscanf_s(uuid.c_str(), "%04x", &data[0]); On 2016/02/07 02:24:08, scheib wrote: > The device::BluetoothUUID.value() isn't always 4 hex digits -- though perhaps in > our tests so far we have only used 4 characters. I guess this code is OK until > it breaks by us adding longer UUIDs. A comment to that effect would be good, > though. Done. https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... File device/bluetooth/bluetooth_low_energy_win_fake.h (right): https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.h:22: // The key of BLEDevicesMap is the string of BLE device address. On 2016/02/07 02:24:08, scheib wrote: > "of the BLE" > ^^^^ Done. https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.h:26: // BLEGattDescriptorsMap is the string of attribute handle. On 2016/02/07 02:24:08, scheib wrote: > "string of the attribute" > ^^^^ Done. https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.h:33: // The key of BLEAttributeHandleTable is the string of BLE device address. On 2016/02/07 02:24:08, scheib wrote: > "of the BLE" > ^^^^ Done. https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.h:82: USHORT GenerateAnUniqueAttributeHandle(std::string device_address); On 2016/02/07 02:24:08, scheib wrote: > GenerateAUniqueAttributeHandle > or > GenerateUniqueAttributeHandle Done. https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.h:88: // The canonical uuid string format is device::BluetoothUUID.value(). On 2016/02/07 02:24:08, scheib wrote: > Capital UUID. Done. https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... File device/bluetooth/bluetooth_task_manager_win.cc (right): https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/blueto... device/bluetooth/bluetooth_task_manager_win.cc:446: int last_error = win::BluetoothClassicWrapper::GetInstance()->LastError(); On 2016/02/07 02:24:08, scheib wrote: > BTW, looking at how often ::GetInstance is being called, consider renameing with > ::Get() in a future refactor patch. Acknowledged. https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/test/b... File device/bluetooth/test/bluetooth_test_win.cc (right): https://codereview.chromium.org/1676073002/diff/20001/device/bluetooth/test/b... device/bluetooth/test/bluetooth_test_win.cc:78: adapter_->StartDiscoverySessionWithFilter( On 2016/02/07 02:24:08, scheib wrote: > Is it possible to avoid duplicate code, and not be brittle to changes to > StartLowEnergyDiscoverySession by calling base class here, then > RunPendingTasks()? > > BluetoothTest::StartLowEnergyDiscoverySession(); > bluetooth_task_runner_->RunUntilIdle(); > ui_task_runner_->RunUntilIdle(); Done.
Dry run: Try jobs failed on following builders: android_arm64_dbg_recipe on tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...) android_chromium_gn_compile_dbg on tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_chro...) android_chromium_gn_compile_rel on tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_chro...) android_clang_dbg_recipe on tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...) android_compile_dbg on tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...) cast_shell_android on tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...) linux_chromium_compile_dbg_32_ng on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) ios_dbg_simulator_ninja on tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...) ios_rel_device_ninja on tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...) mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...) mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...) mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...) win8_chromium_ng on tryserver.chromium.win (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_ng/...) win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...) win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...) win_chromium_x64_rel_ng on tryserver.chromium.win (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1676073002/80001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1676073002/80001
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: chromium_presubmit on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
https://codereview.chromium.org/1676073002/diff/80001/device/bluetooth/blueto... File device/bluetooth/bluetooth_low_energy_win_fake.cc (right): https://codereview.chromium.org/1676073002/diff/80001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.cc:92: // Return correspond Gatt service for BLE Gatt service device. ...corresponding GATT service for BLE GATT... https://codereview.chromium.org/1676073002/diff/80001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.cc:148: USHORT max_attribute_handle = *(it->second->rbegin()); On 2016/02/08 19:23:51, gogerald1 wrote: > On 2016/02/07 02:24:08, scheib wrote: > > it->second is reference a few times in this method -- and at the below it is > > assigned to. I suggest the initial attribute_handle_table_.find is replaced > > with: > > scoped_ptr<std::set<USHORT>> set_of_ushort = > > attribute_handle_table_[device_address] > > then: > > if (set_of_ushort) > > ... > > and assign with > > attribute_handle_table_[device_address] = make_scoped_ptr(new_set); > > It seems base::ScopedPtrHashMap does not implement [] operator. Oh, then let's not use it, looking at it I see ScopedPtrHashMap is Deprecated. Use std::unordered_map instead. https://codereview.chromium.org/1676073002/diff/80001/device/bluetooth/blueto... File device/bluetooth/bluetooth_low_energy_win_fake.h (right): https://codereview.chromium.org/1676073002/diff/80001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.h:23: typedef base::ScopedPtrHashMap<std::string, scoped_ptr<BLEDevice>> ScopedPtrHashMap is Deprecated. Use std::unordered_map instead. https://codereview.chromium.org/1676073002/diff/80001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.h:94: // Extract device address from the device |path| generated above. generated by GenerateBLEGattServiceDevicePath.
The CQ bit was checked by gogerald@chromium.org to run a CQ dry run
The CQ bit was unchecked by gogerald@chromium.org
Patchset #4 (id:100001) has been deleted
The CQ bit was checked by gogerald@chromium.org to run a CQ dry run
https://codereview.chromium.org/1676073002/diff/80001/device/bluetooth/blueto... File device/bluetooth/bluetooth_low_energy_win_fake.cc (right): https://codereview.chromium.org/1676073002/diff/80001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.cc:92: // Return correspond Gatt service for BLE Gatt service device. On 2016/02/08 20:23:00, scheib wrote: > ...corresponding GATT service for BLE GATT... Done. https://codereview.chromium.org/1676073002/diff/80001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.cc:148: USHORT max_attribute_handle = *(it->second->rbegin()); On 2016/02/08 20:23:00, scheib wrote: > On 2016/02/08 19:23:51, gogerald1 wrote: > > On 2016/02/07 02:24:08, scheib wrote: > > > it->second is reference a few times in this method -- and at the below it is > > > assigned to. I suggest the initial attribute_handle_table_.find is replaced > > > with: > > > scoped_ptr<std::set<USHORT>> set_of_ushort = > > > attribute_handle_table_[device_address] > > > then: > > > if (set_of_ushort) > > > ... > > > and assign with > > > attribute_handle_table_[device_address] = make_scoped_ptr(new_set); > > > > It seems base::ScopedPtrHashMap does not implement [] operator. > > Oh, then let's not use it, looking at it I see ScopedPtrHashMap is Deprecated. > Use std::unordered_map instead. Done. Do not notice this deprecation. https://codereview.chromium.org/1676073002/diff/80001/device/bluetooth/blueto... File device/bluetooth/bluetooth_low_energy_win_fake.h (right): https://codereview.chromium.org/1676073002/diff/80001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.h:23: typedef base::ScopedPtrHashMap<std::string, scoped_ptr<BLEDevice>> On 2016/02/08 20:23:00, scheib wrote: > ScopedPtrHashMap is Deprecated. Use std::unordered_map instead. Done. https://codereview.chromium.org/1676073002/diff/80001/device/bluetooth/blueto... device/bluetooth/bluetooth_low_energy_win_fake.h:94: // Extract device address from the device |path| generated above. On 2016/02/08 20:23:00, scheib wrote: > generated by GenerateBLEGattServiceDevicePath. Done.
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1676073002/120001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1676073002/120001
LGTM
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by gogerald@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1676073002/120001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1676073002/120001
Message was sent while issue was closed.
Description was changed from ========== Implement BluetoothLowEnergyWrapperFake for Bluetooth test fixture This CL implements BluetoothLowEnergyWrapperFake to make it support BluetoothTest.DiscoverLowEnergyDevice, BluetoothTest.DiscoverLowEnergyDeviceTwice and BluetoothTest.DiscoverMultipleLowEnergyDevices tests. BUG=579202 ========== to ========== Implement BluetoothLowEnergyWrapperFake for Bluetooth test fixture This CL implements BluetoothLowEnergyWrapperFake to make it support BluetoothTest.DiscoverLowEnergyDevice, BluetoothTest.DiscoverLowEnergyDeviceTwice and BluetoothTest.DiscoverMultipleLowEnergyDevices tests. BUG=579202 ==========
Message was sent while issue was closed.
Committed patchset #4 (id:120001)
Message was sent while issue was closed.
Description was changed from ========== Implement BluetoothLowEnergyWrapperFake for Bluetooth test fixture This CL implements BluetoothLowEnergyWrapperFake to make it support BluetoothTest.DiscoverLowEnergyDevice, BluetoothTest.DiscoverLowEnergyDeviceTwice and BluetoothTest.DiscoverMultipleLowEnergyDevices tests. BUG=579202 ========== to ========== Implement BluetoothLowEnergyWrapperFake for Bluetooth test fixture This CL implements BluetoothLowEnergyWrapperFake to make it support BluetoothTest.DiscoverLowEnergyDevice, BluetoothTest.DiscoverLowEnergyDeviceTwice and BluetoothTest.DiscoverMultipleLowEnergyDevices tests. BUG=579202 Committed: https://crrev.com/d0355bb1d526163aa8d518291df2fd3424925f00 Cr-Commit-Position: refs/heads/master@{#374229} ==========
Message was sent while issue was closed.
Patchset 4 (id:??) landed as https://crrev.com/d0355bb1d526163aa8d518291df2fd3424925f00 Cr-Commit-Position: refs/heads/master@{#374229}
Message was sent while issue was closed.
thakis@chromium.org changed reviewers: + thakis@chromium.org
Message was sent while issue was closed.
FAILED: ninja -t msvc -e environment.x64 -- ../../third_party/llvm-build/Release+Asserts/bin/clang-cl.exe /nologo /showIncludes /FC @obj/device/device_unittests/bluetooth_test_win.obj.rsp /c ../../device/bluetooth/test/bluetooth_test_win.cc /Foobj/device/device_unittests/bluetooth_test_win.obj /Fdobj/device/device_unittests_cc.pdb In file included from ../../device/bluetooth/test/bluetooth_test_win.cc:5: In file included from ../..\device/bluetooth/test/bluetooth_test_win.h:14: ../..\device/bluetooth/bluetooth_low_energy_win_fake.h(35,1) : error: [chromium-style] Complex class/struct needs an explicit out-of-line constructor. struct BLEDevice { ^ ../..\device/bluetooth/bluetooth_low_energy_win_fake.h(35,1) : error: [chromium-style] Complex class/struct needs an explicit out-of-line destructor. ../..\device/bluetooth/bluetooth_low_energy_win_fake.h(40,1) : error: [chromium-style] Complex class/struct needs an explicit out-of-line constructor. struct BLEGattService { ^ ../..\device/bluetooth/bluetooth_low_energy_win_fake.h(40,1) : error: [chromium-style] Complex class/struct needs an explicit out-of-line destructor. ../..\device/bluetooth/bluetooth_low_energy_win_fake.h(46,1) : error: [chromium-style] Complex class/struct needs an explicit out-of-line constructor. struct BLEGattCharacteristic { ^ ../..\device/bluetooth/bluetooth_low_energy_win_fake.h(46,1) : error: [chromium-style] Complex class/struct needs an explicit out-of-line destructor. ../..\device/bluetooth/bluetooth_low_energy_win_fake.h(52,1) : error: [chromium-style] Complex class/struct needs an explicit out-of-line constructor. struct BLEGattDescriptor { ^ ../..\device/bluetooth/bluetooth_low_energy_win_fake.h(52,1) : error: [chromium-style] Complex class/struct needs an explicit out-of-line destructor. 8 errors generated. You seem to break win/clang quite a bit, consider using it locally :-)
Message was sent while issue was closed.
(oh, and i'll send you a cl) |