Indicate minimum version 2.1 for memchr dependency#562
Conversation
The 2.0 family of memchr doesn't build in this crate. This is hard to see using cargo minimal-versions because tokio depends on memchr 2.2, which raises the dependency using minimal-versions even when tokio is disabled. This is a known issue with cargo-minimal-versions: taiki-e/cargo-minimal-versions#6 So everything looks fine from the perspective of this crate, but consumers who use quick_xml without the optional features that enable the tokio dependency have a minimal version down to 2.0, which breaks. To reproduce in this crate, I commented out the tokio and async_tokio lines in Cargo.toml and ran cargo minimal-versions, which produces the errors, and emulates the conditions an external user might experience.
Codecov Report
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more @@ Coverage Diff @@
## master #562 +/- ##
=======================================
Coverage 63.25% 63.26%
=======================================
Files 33 33
Lines 16479 16479
=======================================
+ Hits 10424 10425 +1
+ Misses 6055 6054 -1
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Mingun
left a comment
There was a problem hiding this comment.
Could you provide instructions and the output of failing message? Because for me cargo minimal-versions check is working with memchr = "2.0" even when I comment tokio, tokio-derive dependencies and asinc-tokio feature.
|
Interesting that you're not reproducing. I suppose it's possible it's something weird about my environment. Here's my exact steps, with output: |
Co-authored-by: Mingun <[email protected]>
|
I also tried with the dev dependencies commented out as it seems that you did, but I still get the same memchr compile errors: |
|
As far as I can tell, memchr*_iter() were all added in this memchr commit: BurntSushi/memchr@3120980, which first was in memchr 2.1, so although it is very confusing to me how it is not reproducing on your end, I do think that 2.1 seems like the correct minimum version for this dependency. |
|
Hm, it seems for me cargo somehow taken the lib from the cache. Could you add a change log entry and then we can merge. |
Yes, done. |
|
Ok, at least I understand how I get the false positive result. |
|
Very strange. I didn't try What's strange to me is that based on the output here it looks like you were getting down to memchr 2.0, which shouldn't have compiled: Unless that changed once you got the issue you were mentioning at that link sorted out? |
|
Maybe this is the nightly regression in cargo? I use nightly I filled a bug in cargo for that. |
|
I think I can repro on nightly as well: |
|
It seems that VSCode with rust-analyzer is guilty (RA updates |
This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [quick-xml](https://github.com/tafia/quick-xml) | dependencies | minor | `0.27.1` -> `0.28.0` | --- ### Release Notes <details> <summary>tafia/quick-xml</summary> ### [`v0.28.0`](https://github.com/tafia/quick-xml/blob/HEAD/Changelog.md#​0280----2023-03-13) [Compare Source](tafia/quick-xml@v0.27.1...v0.28.0) ##### New Features - [#​541]: (De)serialize specially named `$text` enum variant in [externally tagged] enums to / from textual content - [#​556]: `to_writer` and `to_string` now accept `?Sized` types - [#​556]: Add new `to_writer_with_root` and `to_string_with_root` helper functions - [#​520]: Add methods `BytesText::inplace_trim_start` and `BytesText::inplace_trim_end` to trim leading and trailing spaces from text events - [#​565]: Allow deserialize special field names `$value` and `$text` into borrowed fields when use serde deserializer - [#​568]: Rename `Writter::inner` into `Writter::get_mut` - [#​568]: Add method `Writter::get_ref` - [#​569]: Rewrite the `Reader::read_event_into_async` as an async fn, making the future `Send` if possible. - [#​571]: Borrow element names (`<element>`) when deserialize with serde. This change allow to deserialize into `HashMap<&str, T>`, for example - [#​573]: Add basic support for async byte writers via tokio's `AsyncWrite`. ##### Bug Fixes - [#​537]: Restore ability to deserialize attributes that represents XML namespace mappings (`xmlns:xxx`) that was broken since [#​490] - [#​510]: Fix an error of deserialization of `Option<T>` fields where `T` is some sequence type (for example, `Vec` or tuple) - [#​540]: Fix a compilation error (probably a rustc bug) in some circumstances. `Serializer::new` and `Serializer::with_root` now accepts only references to `Write`r. - [#​520]: Merge consequent (delimited only by comments and processing instructions) texts and CDATA when deserialize using serde deserializer. `DeEvent::Text` and `DeEvent::CData` events was replaced by `DeEvent::Text` with merged content. The same behavior for the `Reader` does not implemented (yet?) and should be implemented manually - [#​562]: Correctly set minimum required version of memchr dependency to 2.1 - [#​565]: Correctly set minimum required version of tokio dependency to 1.10 - [#​565]: Fix compilation error when build with serde <1.0.139 [externally tagged]: https://serde.rs/enum-representations.html#externally-tagged [#​490]: tafia/quick-xml#490 [#​510]: tafia/quick-xml#510 [#​520]: tafia/quick-xml#520 [#​537]: tafia/quick-xml#537 [#​540]: tafia/quick-xml#540 [#​541]: tafia/quick-xml#541 [#​556]: tafia/quick-xml#556 [#​562]: tafia/quick-xml#562 [#​565]: tafia/quick-xml#565 [#​568]: tafia/quick-xml#568 [#​569]: tafia/quick-xml#569 [#​571]: tafia/quick-xml#571 [#​573]: tafia/quick-xml#573 </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNS42LjAiLCJ1cGRhdGVkSW5WZXIiOiIzNS42LjAifQ==--> Co-authored-by: cabr2-bot <[email protected]> Co-authored-by: crapStone <[email protected]> Reviewed-on: https://codeberg.org/Calciumdibromid/CaBr2/pulls/1818 Reviewed-by: crapStone <[email protected]> Co-authored-by: Calciumdibromid Bot <[email protected]> Co-committed-by: Calciumdibromid Bot <[email protected]>
The 2.0 family of memchr doesn't build in this crate. This is hard to see using cargo minimal-versions because tokio depends on memchr 2.2, which raises the dependency using minimal-versions even when tokio is disabled. This is a known issue with cargo-minimal-versions:
taiki-e/cargo-minimal-versions#6
So everything looks fine from the perspective of this crate, but consumers who use quick_xml without the optional features that enable the tokio dependency have a minimal version down to 2.0, which breaks.
To reproduce in this crate, I commented out the tokio and async_tokio lines in Cargo.toml and ran cargo minimal-versions, which produces the errors, and emulates the conditions an external user might experience.