Skip to content
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

Merged

Conversation

ijackson
Copy link
Contributor

Backport of #465 to 0.13.x branch. Fixes #464 there.

@matthiasbeyer
Copy link
Member

Please re-do the commits with the -x flag on git-cherry-pick (as noted here) so that the backported commits refer to the original ones.

@ijackson
Copy link
Contributor Author

ijackson commented Oct 23, 2023

Please re-do the commits with the -x flag on git-cherry-pick (as noted here) so that the backported commits refer to the original ones.

Ah sorry, didn't see that comment. FTR, I did:

for f in `git-rev-list --reverse --topo-order nested-array~4..nested-array`; do echo git cherry-pick -x $f; done | sh -xe

@matthiasbeyer
Copy link
Member

for f in `git-rev-list --reverse --topo-order nested-array~4..nested-array`; do echo git cherry-pick -x $f; done | sh -xe

The following would have been sufficient:

git cherry-pick -sx $(git merge-base master^1 master^2)..master^2
Explanation of the above command Explanation: The above means cherry-pick the changes:
  • from the merge base of the commit to the left of current master and the commit to the right of current master (the last commit of the previously merged PR)
  • to the commit to the right of current master (the last commit of the previously merged PR)

You can replace the git cherry-pick -sx with git log --oneline and you'll see that this is exactly the range you want to pick.

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 I'll do that and rebase this PR then. No need to worry for you!

@ijackson
Copy link
Contributor Author

I think we could fix this on the 0.13 branch by committing a suitable Cargo.lock. Would you like me to do that?

@ijackson
Copy link
Contributor Author

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 I'll do that and rebase this PR then. No need to worry for you!

Please let me have a go at fixing it with a Cargo.lock instead? I will try that tomorrow; it's getting rather late for me here now.

@matthiasbeyer
Copy link
Member

matthiasbeyer commented Oct 23, 2023

Please let me have a go at fixing it with a Cargo.lock instead? I will try that tomorrow; it's getting rather late for me here now.

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 log crate version (for example) but an compiler too old for that crate version.

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! 🦉

@ijackson
Copy link
Contributor Author

I have succeeded, by providing a Cargo.lock. I will tidy up my branch and make an MR of it.

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>
@ijackson
Copy link
Contributor Author

ijackson commented Nov 7, 2023

I've rebased this to pick up the CI fix from #496

@matthiasbeyer
Copy link
Member

I am on vacation until late tomorrow. I hope I can get back to this as soon as possible.

Copy link
Member

@matthiasbeyer matthiasbeyer left a 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 😆

@matthiasbeyer matthiasbeyer merged commit db754f5 into rust-cli:release-0.13.x Nov 9, 2023
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants