Jonathan Schwender

> I believe ideally in corrosion, we would simply not require cdylib/staticlib be specified in Cargo.toml This is currently not the case, but there is no technical reason preventing this...

> Adding cdylib to the Cargo.toml fixes the issue, but of course breaks the earlier fix! Could you clarify what is broken? The expected behavior is that `CRATE_TYPES` only imports...

Okay, let's see if I understood correctly: 1. You can't specify `cdylib` in the Cargo.toml, because the crate is also used as an `rlib` from a different crate, and compilation...

> Despite the fact that test2 presumably should only care about the rlib artifact, it appears to build all of gctex's targets I suspect that cargo doesn't really know what...

Added in #557

Related to https://github.com/rust-lang/rust-bindgen/issues/1656, since both allow creating an opaque type out of thin air.

It is probably worth noting, that bindgen makes the difference between "Forward declared types" (i.e. layout is unknown) and "opaque". In bindgen terms, opaque implies that the memory layout (size...

Opaque types shouldn't derive any of Copy, Clone or default. See also: https://github.com/rust-lang/rust-bindgen/issues/1656. ( I have some patches related to opaque types [on my fork of bindgen](https://github.com/rust-lang/rust-bindgen/compare/main...openharmony-rs:rust-bindgen:jschwender/doc_cfg), but didn't have...

FYI, you can use `rustfmt` (nightly) with the following configuration to normalize comments to the standard `///` style: ``` unstable_features = true normalize_comments = true normalize_doc_attributes = true ``` Edit:...

> Also unsure if adding/which tests would be applicable here... I think perhaps we should add a job (or perhaps one job per platform) to CI which compiles `servo` with...