core-foundation: Remove 2 transmutes in macros.
These transmutes were going from one type of pointer to another,
and so can be done as casts instead.
Doing so also means that one unsafe block can be removed.
This was found via clippy.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/core-foundation-rs/229)
<!-- Reviewable:end -->
These transmutes were going from one type of pointer to another,
and so can be done as casts instead.
Doing so also means that one unsafe block can be removed.
This was found via clippy.
CFString refactor / cleanup
This pull request:
- removes two unnecessary casts (from `CFIndex` to `usize` and back again)
- extracts the to rust string conversion: instead of doing it on-the-fly in the `Display` implementation (and thus only supporting the indirect `ToString` way to get a rust string from a `CFString`, which _always_ allocates) this implements `From<&CFString> for Cow<str>` allowing everyone the possibility of avoiding an allocation if the `CFString` is already formatted in UTF-8.
Rebase of #76 (note to self: next time, re-open first, then push).
cc @jdm
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/core-foundation-rs/220)
<!-- Reviewable:end -->
Additional functions for `CGImage` and `CGDataProvider`
1. Adds a possibility to construct a CGImage from a given provider. I don't know if it's the most optimal way to implement it and if it is safe, but it would be nice to wrap this function somehow, that was the first attempt to do it.
2. Adds some rendring intent constants.
3. Adds a function which allows to create a data provider from a slice. This is highly unsafe, that's why I marked it with unsafe. And I'm not sure if it is the best way to do this. Perhaps the one can store something like `Option<slice>` in the data provider, but in this case the provider will get some lifetime parameter (and we have to update the foreign type definition). I'm not sure that having slice parameter and a lifetime would make it 100% safe though, because when we're passing a data provider ref to some FFI, they could theoretically retain a data provider (or the image which uses the data provider), expecting that the data inside the data provider lives long enough. Probably the only "really safe" way to manage the data provider data is the one which is currently available (via `Arc<Vec<u8>>`), but this limitation of having `Arc<Vec<u8>>` may be very ineffective in some sort of appliations, so for instance in my case I had to add the additional "constructor" to allow creation of unsafe data provider and I guarantee the safety in my code by some other means.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/core-foundation-rs/219)
<!-- Reviewable:end -->
BUG: Add test showing how downcasting to CFArray is unsound
This PR is not intended to me merged directly. It adds a test that causes undefined behavior without using `unsafe {}`. So it's more to show the problem and discuss a solution.
The problem here is that if you have a `CFArray<X>` you can cast it up to a `CFType` and then down to a `CFArray<Y>` for any `Y: TCFType`. It never checks that the elements in the array are of type `Y` or not. At this point `CFArray::iter` will happily give out `&Y` references, while in fact the pointers backing those objects are pointing to `XRef` instances. So doing anything with the `&Y` will likely cause invalid memory access.
How do we solve this?
Ping @jrmuizel
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/core-foundation-rs/158)
<!-- Reviewable:end -->
Consistently use std::os::raw::c_void instead of libc::c_void
The major versions of cocoa and core-graphics are bumped as I believe
they are the only crates that meaningfully expose c_void.
Fixes#212
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/core-foundation-rs/214)
<!-- Reviewable:end -->
bors-servo
