First of all thank you very much for maintaining this awesome library!
problem
Our application (relying on xlsxwriter) fails to compile after updating to v0.4.0.
(I confirmed it compiles successfully upto the commit right before this update is getting merged)
Here's the message we got:
Compiling xlsxwriter v0.4.0
error[E0308]: mismatched types
--> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/xlsxwriter-0.4.0/src/worksheet/table.rs:273:23
|
273 | name: cstring_helper.add_opt(options.name.as_deref()) as *mut i8,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u8`, found `i8`
|
= note: expected raw pointer `*mut u8`
found raw pointer `*mut i8`
For more information about this error, try `rustc --explain E0308`.
The strange thing is that it did NOT happen to other environments - especially our CI is green, and the production app seems to be running just fine.
quick analysis
(sorry but I might be totally wrong - I'm very new to this language)
It looks like the above failed code is trying to cast c_char into i8, where as the official doc says that c_char could be interpreted as either i8 or u8 depending on the platform (which is also be seen around here).
Could it be the cause for this platform-depenedent issue maybe?
Anyway, it would be greatly appreciated if this can be fixed anytime soon!
First of all thank you very much for maintaining this awesome library!
problem
Our application (relying on xlsxwriter) fails to compile after updating to v0.4.0. (I confirmed it compiles successfully upto the commit right before this update is getting merged)
Here's the message we got:
The strange thing is that it did NOT happen to other environments - especially our CI is green, and the production app seems to be running just fine.
quick analysis
(sorry but I might be totally wrong - I'm very new to this language)
Here is the specific part the compiler is complaining on. https://github.com/informationsea/xlsxwriter-rs/blob/6cccc4ef1cef55107084c3b61fd3ebcdbf479285/libxlsxwriter/src/worksheet/table.rs#L273
It looks like the above failed code is trying to cast c_char into i8, where as the official doc says that c_char could be interpreted as either i8 or u8 depending on the platform (which is also be seen around here).
Could it be the cause for this platform-depenedent issue maybe?
Anyway, it would be greatly appreciated if this can be fixed anytime soon!