`gatt_service` Proc Macro can't handle &'static str values

[jscatena88]

Hello you all were able to help me earlier with #272 . I'm finally looking to pick that project back up and it seems that the gatt_service macro can't handle &'static str values. I get the following error:

error[E0599]: no associated item named `Value` found for struct `DeviceInfoService` in the current scope
   --> rp_firmware/src/bluetooth.rs:110:63
    |
25  | #[gatt_service(uuid = "0000180a-0000-1000-8000-00805f9b34fb")]
    | -------------------------------------------------------------- associated item `Value` not found for this struct
...
110 |             AdStructure::ServiceUuids128(&[DeviceInfoService::Value]),
    |                                                               ^^^^^ associated item not found in `DeviceInfoService`

error[E0080]: could not evaluate static initializer
  --> rp_firmware/src/bluetooth.rs:38:20
   |
38 |     serial_number: &'static str,
   |                    ^ values of the type `[u8; usize::MAX]` are too big for the target architecture

Some errors have detailed explanations: E0080, E0599.
For more information about an error, try `rustc --explain E0080`.

Poking around a bit it looks like the result of the AsGatt implmentation of &str setting MAX_SIZE = usize::MAX :

impl AsGatt for &'static str {
    const MIN_SIZE: usize = 0;
    const MAX_SIZE: usize = usize::MAX;

    fn as_gatt(&self) -> &[u8] {
        self.as_bytes()
    }
}

and the macro having the following instantiation of StaticCell:

 static #name_screaming: static_cell::StaticCell<[u8; <#ty as trouble_host::types::gatt_traits::AsGatt>::MAX_SIZE]> = static_cell::StaticCell::new();

It looks like this would also impact the impl for &[u8] since that sets MAX_SIZE the same way

[petekubiak]

Oops yeah that's a problem!
I wonder if there's a way we can evaluate the length in the proc macro, as this should be known at compile time.
Tomorrow is likely to be hectic for me so if I can't get to it then I'll definitely have a look on Tuesday.

[HaoboGu]

For &'static [u8], I use try_into().unwrap() + const fn:

const fn get_hid_info() -> &'static [u8] {
    &[0x01, 0x01, 0x00, 0x03]
}
struct HidService {
    #[characteristic(uuid = "2a4a", read, value = get_hid_info().try_into().expect("Failed to convert HID_INFO to [u8; 4]"))]
    pub(crate) hid_info: [u8; 4],
}

It would be better if the size could be processed in compile-time.

[jscatena88]

Using TryInto to convert a slice to a sized array is a great work around, thanks for the tip!

Hopefully there is some way to make this all "just work" in the proc-macro. I'm not super familiar with proc-macros to be able to comment on how to do it. But the len() function of a &str is const so you can get the length in a const context. An issue is that you can only have one impl of AsGatt for a given type (&'static str in this case), so you can only have one possible MIN and MAX for the whole type even if each instance is a different size. I think the only ways to have those be different from instance to instance would be to make wrapper types for each one or have a single wrapper type with a const generic N.

When we get const functions in traits you could imagine redefining AsGatt to use that:

pub trait AsGatt: Sized {
    const fn min_size(&self) -> usize;
    const fn max_size(&self) -> usize;
    fn as_gatt(&self) -> &[u8];
}

Do MIN_SIZE and MAX_SIZE need to be available in a const context? If not you could just use functions like above without the const

One other point of annoyance, that is a Rust language thing is that I can't seem to find a good way to get a const statically allocated sized array without having to specifically indicate the size. In the best case scenario you get to write something like:

const FOO_ARR: [u8;3] = *b"foo";

Which kind of stinks that you have to manually indicate that it is 3 bytes long, and update that if you change the text. Especially since the compiler knows what size it is:

   |
21 | const FOO_ARR: [u8;10] = *b"foo";
   |                    --    ^^^^^^^ expected an array with a size of 10, found one with a size of 3
   |                    |
   |                    help: consider specifying the actual array length: `3`

the language just doesn't allow for _ to be used for the N value:

   |
21 | const FOO_ARR: [u8;_] = *b"foo";
   |                    ^ not allowed in type signatures
   |
help: replace this with a fully-specified type
   |
21 - const FOO_ARR: [u8;_] = *b"foo";
21 + const FOO_ARR: [u8; 3] = *b"foo";
   |

[petekubiak]

One other point of annoyance, that is a Rust language thing is that I can't seem to find a good way to get a const statically allocated sized array without having to specifically indicate the size.

Yeah this continually bugs me too. I've not found a way around it :/

[petekubiak]

I've actually got around to having a proper look at and think about this now, and I've got some thoughts and questions.

First off, if you're creating a characteristic of type &'static str, is it intended to be immutable? As in, the characteristic is read-only?
Secondly, I think that a characteristic of type &'static str or &'static [u8] would always have to be read-only right?

If this is the case, I think the issue is that there currently isn't a way to generate true read-only characteristics with the macro. The attribute table in TrouBLE does have the functionality to hold read-only characteristics, but this is only used in the creation of the GAP service.

So I think the solution here is probably to implement a way to (probably explicitly) set a characteristic as read-only. Are you happy with this proposal?

[jscatena88]

Yep, in my case it's definitely with the goal of making an immutable characteristic. Something like "model number" or "firmware_version" where the value is known at compile time.

And nice, that looks similar to the suggestion @HaoboGu above. I'm definitely not blocked on this issue so feel free to prioritize it however makes sense. I just figured its not ideal have an AsGatt implementation that can't really be used

[petekubiak]

Yeah true. The other option would be to just add an error message to the macro to say that &str and &[u8] can't be used as a characteristic's type, but allowing their use to define a read-only type is a much nicer solution I think.