-
Notifications
You must be signed in to change notification settings - Fork 217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix nested arrays (by reworking array handling) - backport #486
Fix nested arrays (by reworking array handling) - backport #486
Conversation
Please re-do the commits with the |
9f2da44
to
e6d85cc
Compare
Ah sorry, didn't see that comment. FTR, I did:
|
The following would have been sufficient:
Explanation of the above commandExplanation: The above means cherry-pick the changes:
You can replace the But no worries! Log looks good now, let's see what CI tells us! It seems that we have to bump the MSRV for the next 0.13.x release ... I don't like that but I don't see a better way, tbh. |
I think we could fix this on the 0.13 branch by committing a suitable |
Please let me have a go at fixing it with a |
Yes, feel free to try. Although I am not sure about whether that would help, as downstream might still run into the issue that they have a new But I see where you're going. I'll stop my efforts for the MSRV update on the release branch (#487) now! Have a good night! 🦉 |
I have succeeded, by providing a |
Have all the various versions of sequences (arrays and various forms of tuple) all go via ser::SerializeSeq. This reduces some duplication. And, we're about to change the implementation. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk> (cherry picked from commit ed6a3c9) Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
We're going to want to do something more complicated. In particular, to handle nested arrays properly, we need to do some work at the start and end of each array. The `new` and (inherent) `end` methods of this newtype is where that work will be done. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk> (cherry picked from commit 147e6c7) Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Change the representation of our "current location". Previously it was a list of increasingly-long full paths, but excepting the putative final array index. Now we just record the individual elements. and assemble the whole path just before calling .set(). This saves a little memory on the whole since the entries in keys are now a bit shorter. It is much less confusing. (There are perhaps still further opportunities to use Rust's type system to better advantage to eliminuate opportunities for bugs.) Arrays that appear other than at the top level are now handled correctly. This includes nested arrays, and arrays containing structs, etc. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk> (cherry picked from commit 831102f) Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk> (cherry picked from commit aa63d2d) Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
e6d85cc
to
eb46fd6
Compare
I've rebased this to pick up the CI fix from #496 |
I am on vacation until late tomorrow. I hope I can get back to this as soon as possible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As all commits were picked from approved PRs, I don't see why I shouldn't approve this as well 😆
Backport of #465 to 0.13.x branch. Fixes #464 there.