Indicate minimum version 2.1 for memchr dependency #562
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
dralley
reviewed
Feb 24, 2023
dralley
approved these changes
Feb 24, 2023
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
reviewed
Feb 24, 2023
|
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 <Alexander_Sergey@mail.ru>
|
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. |
Mingun
reviewed
Feb 24, 2023
|
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 |
crapStone
added a commit
to Calciumdibromid/CaBr2
that referenced
this pull request
Mar 16, 2023
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 <cabr2.help@gmail.com> Co-authored-by: crapStone <crapstone01@gmail.com> Reviewed-on: https://codeberg.org/Calciumdibromid/CaBr2/pulls/1818 Reviewed-by: crapStone <crapstone@noreply.codeberg.org> Co-authored-by: Calciumdibromid Bot <cabr2_bot@noreply.codeberg.org> Co-committed-by: Calciumdibromid Bot <cabr2_bot@noreply.codeberg.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.