* src/dc_mimefactory.rs(MimeFactory): change type of `loaded` field
* src/dc_mimefactory.rs(Loaded): new enum, describing possible
values of `loaded` field of `MimeFactory` structure
* src/dc_mimefactory.rs(dc_mimefactory_loaded_t): remove unused type alias
* src/job.rs(add_smtp_job): adjust call site by removing multiple casts
* src/dc_mimefactory.rs(dc_mimefactory_render): ditto
The Message struct had a reference to the context which made a few
APIs a little easier. However it has surprising consequences a long
way down the line as shown in #335: it means any object which has such
a reference needs to keep open a lock if we want to do this refactor
of no longer having a "closed" Context struct on the Rust API (which
has many benefits which will simply that Context struct and is more
the Rust way - RAII etc).
By refactoring away the context reference on the rust API as done in
here however, we push this behaviour of how these references are
handled back to the C-API pointer behaviour: that is unsafe but just
works in a C-like way. The resulting complexity in the FFI layer is
also notably less than in the #335 alternative.
As a consequence all APIs which require the context, now explicitly
need to get the context passed in as an argument. It looks like this
is certainly no downside and maybe even beneficial for further API
refactors.
For this strategy to work out the same should be done to
dc_chatlist_t, dc_chat_t and dc_contact_t. But this working for
dc_msg_t give a reasonable confidence that this is a good approach.
Previously, logging macros (info! warn! error!) accepted integer
argument (data1), that was passed to callback function verbatim. In all
call sites this argument was 0.
With this change, that data1 argument is no longer part of macro
interface, 0 is always passed to callback in internals of these macros.
* Make dc_msg_get_summarytext_by_raw safe
* use dc_truncate method in all places
* Fix tests and add docs to dc_truncate()
* Make text argument an AsRef<&str> and rename type_0 to viewtype
* Fix too early return in dc_msg_get_summarytext_by_raw. Fixes https://github.com/deltachat/deltachat-core-rust/issues/313
* refactor(contact): rename and rusty memory allocations
* refactor(contact): use enum to indidcate origin
* refactor(contact): safe blocking and unblocking api
* refactor(contact): only safe and no more cstrings
Add a trait for str.strdup() to replace to_cstring() which avoid the
signature ambiguity with .to_string().
Also instruduce CString::yolo() as a shortcut to
CString::new().unwrap() and use it whenever the variable does can be
deallocated by going out of scope. This is less error prone.
Use some Path.to_c_string() functions where possible.
With this change, kind of message is represented by value of enum
`Viewtype' instead of raw libc::c_int, providing more type safety. This
enum replaces DC_MSG_* constants. The only way to create `Viewtype' from
libc::c_int is smart constructor.
With this change, functions `dc_get_chat_media' and `dc_get_next_media' became
less forgiving about invalid message type arguments. Previously, invalid
message types were implicitly interpreted as 0 (Viewtype::Unknown). Now,
function calls with invalid message type arguments are rejected (error code
returned) on FFI boundary.
Additionally, when `Viewtype' is read from database, it is checked to have
sensible value.
No tests assumed forgiving behaviour.
