Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?

OK, fair. On Fri, Dec 16, 2016, at 08:14 AM, Bobby Holley wrote: > Given that we've already done the deed and merged the crates, I think we > should hold off on resplitting them until the stylo integration is more > mature. We may find other ways to achieve additional type safety with > tight >

Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?

Given that we've already done the deed and merged the crates, I think we should hold off on resplitting them until the stylo integration is more mature. We may find other ways to achieve additional type safety with tight coupling between generate bindings and other style code (like the ElementData

Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?

I was actually intending to expand that set as necessary, a lot of the owned and arc types could use this trick too. A lot of this was held back on the Rust compiler losing inline drop flags (which happened recently). I'm okay with splitting it again, but would prefer to avoid as much as

Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?

Oh, I see what did you mean. ElementData and AtomicRefCell would be a problem. I don't see anything else, though. - Xidorn On Thu, Dec 15, 2016, at 05:29 PM, Manish Goregaokar wrote: > The sugar stuff is just helpers. The crossover happens in the bindings > file > itself, where gets replaced

Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?

Yes, this could be done. I would like to have more automated checks here however if we were to do this. At one point I had considered letting the generated bindings be super unsafe and then for each servo_*/gecko_* function have a safe wrapper that is generated (or handwritten?) that forwards to

Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?

On 15/12/16 02:01, Manish Goregaokar wrote: They used to be a different crate. I merged them so that we can do replacements with safer wrappers and have fewer coherence issues. Could the code generated by bindgen be separated from the wrappers? That way wrappers could be wherever impl

Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?

The sugar stuff is just helpers. The crossover happens in the bindings file itself, where gets replaced with , etc. On Dec 14, 2016 5:13 PM, "Xidorn Quan" wrote: > On Thu, Dec 15, 2016, at 12:01 PM, Manish Goregaokar wrote: > > They used to be a different crate. I merged them

Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?

They used to be a different crate. I merged them so that we can do replacements with safer wrappers and have fewer coherence issues. Perhaps we can make triggering local build time bindgen regen more explicit? On Dec 14, 2016 2:57 PM, "Xidorn Quan" wrote: > I'm thinking about

[dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?

I'm thinking about splitting those parts into a separate crate because currently servo/style component's build script is doing two different things: 1. generate property code, 2. do bindgen. And mixing these things may lead to many unnecessary rebuild. In the current build-time bindgen code, all