Those errors are difficult to diagnose without seeing the rest of the code. However, given that BluetoothAdapter is supposed to be a trait now, the second function does not look like it is using trait objects correctly. As for the first function, the error message appears to be describing a concrete problem that it should be possible to figure out independently.

In general in the new trait-based code, we should not be using the `get_inner_and_call` macro any more: https://github.com/servo/devices/blob/d6c62e0873b2ec9a68c97a3370667e8b9a879cf4/src/bluetooth.rs#L188-L256

It was written to effectively perform the same work as the new traits, so I would expect the resulting trait implementations to directly call the appropriate platform-specific code, rather than using a macro.

On 3/31/19 3:45 PM, Niveditha Shankar wrote:
Hello Josh

We are trying to fix the errors we got in adapter.rs. We fixed most of
them.
The errors that are left are due to the changes we made to the init
functions.

We are not sure about the following errors, could you help us with this?

error[E0407]: method `get_modalias` is not a member of trait
`BluetoothAdapter`
    --> src\adapter.rs:335:6
     |
335 | /      fn get_modalias(&self) -> Result<(String, u32, u32, u32),
Box<Error>> {
336 | |         get_inner_and_call!(self, BluetoothAdapter, get_modalias)
337 | |     }
     | |_____^ not a member of trait `BluetoothAdapter`

error[E0277]: the size for values of type `(dyn adapter::BluetoothAdapter +
'static)` cannot be known at compilation time
    --> src\adapter.rs:156:6
     |
156 | /      fn new() -> Result<BluetoothAdapter, Box<Error>> {
157 | |         let adapter = try!(BluetoothAdapterEmpty::init());
158 | |         Ok(BluetoothAdapter::Empty(Arc::new(adapter)))
159 | |     }
     | |_____^ doesn't have a size known at compile-time


-Niveditha Shankar


On Sat, Mar 30, 2019 at 1:09 PM Josh Bowman-Matthews <j...@joshmatthews.net>
wrote:

Yes - use a Cargo override to build Servo with your local modified
version of the devices crate. You can read more about overrides at

https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#overriding-dependencies
and
https://doc.rust-lang.org/cargo/reference/manifest.html#the-patch-section
and you can see where to add this at
https://github.com/servo/servo/blob/master/Cargo.toml#L17-L26 . Once
Servo builds with the modified crate, you can run the automated
bluetooth tests to verify that the behaviour is the same: `./mach
test-wpt tests/wpt/mozilla/tests/bluetooth`.

Cheers,
Josh

On 3/30/19 12:50 PM, Niveditha Shankar wrote:
Okay I think I get it. Thank you!

Is there anyway I can check if the changes I make to the devices crate is
right?

Our submission is on Monday and  we are going to continue working with
Webbluetooth for our final project too. So if our implementation of our
adapter.rs file is right, we can go ahead and do something similar for
the
rest of the enum values. It would be really helpful if there is a way to
check that.


Niveditha Shankar
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo


_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Reply via email to